​​[0IP-19] Reset attacker Accounts and enable oToken Transfer Mechanism

Proposal:

• Resetting of all known attacker oTokens as well as erasing the protocol's reserve shares earned through the exploit’s liquidation process
• Re-enable oToken transfers ONLY (minting, borrowing, liquidations to be kept paused until further proposals are voted on)
• The 734,998.437 USDC of protocol reserves which were nominally earned by 0VIX as part of the exploit’s liquidation proceeds will also be forfeited back to users as discussed in the post-mortem

Motivation:

In light of the recent exploit it is crucial to provide users with greater flexibility over their affected funds, while keeping all operations fair across all affected users. Allowing oToken transfers (while keeping all other protocol operations paused until one of the options for resuming the protocol are decided and voted on) paves the way for exploring secondary market options which can provide an alternative avenue for users that require obtaining urgent liquidity. Following the post-mortem and AavegotchiDAO community call on May 14th, critical information regarding the recovery process has been transparently shared. This includes:

1. Current underlying liquidity leftover post-exploit on each 0VIX market
2. The total vGHST amounts received by GotchiVault
3. The total GHST amounts the protocol is likely to recapture as a result of the AavegotchiDAO governance process
4. Timeline for the restitution of funds sent to AavegotchiDAO by GotchiVault.

What this vote is not deciding on is which precise reimbursement scheme the community will vote on regarding the recapitalization of affected markets using recuperated vGHST and GHST funds. This will be discussed and voted on in a subsequent proposal.

The shared information is deemed sufficient for an open market pricing of user oTokens to commence on an entirely opt-in basis, with minimal risk of information asymmetry for all parties involved.

Definition:

An 0VIX oToken refers to a token that represents a user's balance on the 0VIX protocol. Such tokens are traditionally referred to as receipt tokens thus act as utility tokens not to be confused with any tokens granting a redemption right against an identified issuer. When a user deposits a cryptocurrency into the 0VIX protocol, they receive a corresponding oToken in return. For example, if a user deposits USDC, they will receive oUSDC. If they deposit DAI, they will receive oDAI, and so on.

The interest determined by the 0VIX protocol is earned by users on their deposited assets and is automatically added to their oToken balance. This means that the number of oTokens held by a user increases over time as the interest over deposited tokens accrues. If no interest is being accrued on the protocol, the number of oTokens corresponds merely to the share of the underlying liquidity provided by each user in each market.

Link to the documentation of oTokens: https://docs.0vix.com/core-protocol/otoken

Under normal operations, users can redeem their oTokens to retrieve their originally deposited cryptocurrency plus any accrued interest. Technically speaking, to execute this redemption, users burn their oTokens on 0VIX to receive the underlying cryptocurrency in return. Similarly, when users deposit cryptocurrency on the protocol, oTokens are automatically minted and given to the depositing user. If redeeming and minting are paused, oTokens can neither be created nor destroyed for underlying liquidity.

Example:

If 1000 oUSDC are owned collectively by all users, and one specific user owns 100 oUSDC, that user can technically reclaim 10% of the total supplied USDC (calculated as available underlying liquidity + active borrows - protocol reserves) locked in the protocol as long as sufficient liquidity exists.

The current state of existent oTokens on the protocol, along with the existing underlying liquidity, and the implied oToken value are shown in the table below. Implied values shown in the table below do not consider any future adjustments resulting from recuperated exploit funds.

Note: oToken contract addresses can be found here: https://docs.0vix.com/developers/contract-addresses/mainnet

Details:

Due to the overwhelming positive response to Retrø#0867’s proposal in the community about creating a liquidity market for oTokens (the original post on Discord can be seen here), it has been decided to put this up to an official vote to the community in the form of one proposal, together with the burning of attacker accounts.

Before allowing any operations involving user oTokens it is of fundamental importance that any oTokens belonging to the attacker be resetted such that the actor is impeded from extracting any more liquidity. The addresses whose tokens shall be resetted are 0x407 and 0x49c as discussed in the exploit post-mortem. Protocol's reserves that were increased by 734,998.437 USDC, nominally worth $735k, as a part of the exploit’s liquidation proceeds will also be annulled as discussed in the post-mortem.

Burning the attacker’s oTokens and annulling the protocol reserves resulting from the exploit would significantly increase the exchange rate between oTokens and underlying assets as the amount of underlying assets (split between assets in available liquidity and borrowed assets) would stay the same while the total oToken supply would decrease. This would lead to a false increase in user portfolios (oToken balance x increased exchange rate), as the increase would be in the form of bad debt owned by the attacker.

oToken exchange rate = (underlying liquidity + outstanding loans - protocol reserves) / total oToken supply

Therefore, it is important to also reduce the attacker's borrowed balance (i.e. bad debt) in vGHST, USDT and USDC markets to keep the exchange rate between oTokens and underlying assets the same as it is currently. This will preserve users’ net portfolio sizes, thus making the UI reflective of the true state of the protocol. A decrease in the attacker’s borrow balance on vGHST and USDT markets would match the value of burned attacker’s oTokens. Similarly, the decrease in attacker’s borrowed balance in the USDC market would reflect the annulled value of protocol reserves. Exchange rates across all markets would then stay the same and users’ net portfolio positions would be fully preserved.

After implementing these changes, markets would look like this:

USD values are calculated based on the asset prices on 12/05/23.

Only oToken transfers will be enabled. All other 0VIX protocol operations shall remain on pause until further voting takes place (in connection to any reimbursement steps). Following a positive outcome of this proposal, operations such as mint, redeem, borrow will continue to remain on pause. Given that interest rates on the protocol are currently zero, the total number of oTokens is guaranteed to remain constant (aside from the attacker’s oToken reset), implying that enabling of oToken transfers will not have any effect on the final withdrawable amounts of users who choose to not operate with their oTokens. In other words, all consequences pertaining to a positive outcome of this proposal are entirely opt-in.

Allowing oToken transfers allows the creation of secondary market opportunities for user oTokens. These in turn can provide liquidity to highly distressed users should counterparties offer to purchase their oTokens. As an example, if oToken transfers are enabled anyone will be free to provide liquidity to AMMs such as Uniswap to enable swaps between oTokens and their underlying assets. Affected users will then be able to simply go to app.uniswap.org and swap their oTokens for underlying liquidity should they desire to.

The effective swap price of each oToken is entirely controlled by market sentiment and interest. Users may or may not find the oToken swap price attractive. Only supply/demand dynamics will decide what people are willing to offer and accept on trades. Once AMMs for swapping go live, trading will necessarily be entirely at each user’s own risk.

As the 0VIX smart contracts don’t allow transferring more oTokens than are minimally required to keep one’s account overcollateralized, users will be limited on how many oTokens they may be able to swap. If a user position nominally holds $100 worth of oTokens with liquidation threshold of 85% and owes $50 worth of loans, a user will not be allowed to swap more than $100-($50/0.85) = $41.18 worth of their nominal oToken value.

By swapping/transferring one’s oToken balance, the user will not own those oTokens anymore and, as such, will be forfeiting any future withdrawable funds. Given that swapping is entirely an opt-in process, users uncomfortable with the prospect of forfeiting future shares of recuperated funds can simply not perform any swaps. Analogously, actors uncomfortable with the uncertainty surrounding what the final value of each oToken will be can simply refrain from providing liquidity to any secondary markets/DEX.

0VIX protocol can not be held responsible in any way for what users do with their oTokens on secondary markets by virtue of their transfer functionality. They are, unambiguously, tokens of their own accord.

To summarize this proposal recommends:

1. Adjust the attacker's position to reflect the actual protocol state. This involves resetting attacker oToken balances to 0 and resetting their borrow balance to accurately reflect the bad debt incurred.
2. Re-enable oToken transfers ONLY (minting, borrowing, liquidations to be kept paused until further proposals are voted on)
3. The USDC 734,998.437 of protocol reserves which were nominally earned by 0VIX as part of the exploit’s liquidation proceeds will also be forfeited back to users as discussed in the post-mortem.

FAQ

Q: If I sell my oTokens will I still be eligible to claim the same amount of reimbursements from the protocol?

A: No, reimbursements will only be withdrawable using oToken balances. If you sell your oTokens (fully or in part) you will not own enough oTokens to redeem the full amount you would expect to get if you didn’t sell any oTokens at all.

Q: Why are pre-mined VIX tokens used as a sign of voting power?

A: It is overall common for a DeFi protocol to honor the governance token holders instead of raw value of the supply. Pre-mined VIX tokens represent the amount of funds supplied over time.

Q: Is preVIX the final token of the 0VIX Protocol?

A: No, as stated in the charter, the pre-mined VIX tokens are used to help restart the protocol and provide users with a means to vote for the protocol's restart. The preVIX balances will be used to calculate the voting power. It is not feasible to create another form of voting mechanism separate from the pre-mined balances due to complex legal and operational implications. Additionally, there is an urgency to restart the protocol as soon as possible. The votes also decide certain aspects of the protocol that are relevant to all users, such as the forfeiting of the USDC 734,998 protocol reserves (see 3rd recommendation above).

Q: Why not use exploited fund balances for voting purposes?

A: Using exploited fund balances for voting purposes would require everyone agreeing on how to measure the loss per account, which is non trivial and itself requires a vote. The community is currently preparing a proposal for this. There are various perspectives that need to be considered on this matter, such as the oToken balance not accurately reflecting the amount of loss. For example, two holders with the same amount of oTokens may have different losses if one borrowed up to the collateral factor and the other didn't borrow anything. Additionally, it would need to be decided if holders of oTokens on unaffected markets should have less impact, and whether it is fair for long-term supporters to have the same vote weight as short-term supporters, among other considerations. . Moreover the community would then have to agree on a governance token that will be used for voting and audit and deploy smart contracts, developing the script which would airdrop this governance token according to the distribution plan and more. As stated above, this all would not take into account other aspects of the votes, including the forfeiting of protocol reserves, that have an impact beyond the attack.

Q: Do I have to vote?

A: No, whilst the protocol encourages everyone to participate in the votes and discussions, voting is absolutely voluntary.

Voting period:

2 days