Euler Finance Hack 2023 Distribution of Funds Proposal "Multi-Stage"

Redemption of Euler Funds
1

Euler Finance Hack 2023 Distribution of Funds Proposal “Multi-Stage”

This proposal lets each user choose to either claim their tokens during a early distribution phase (if possible), or wait until the relaunch of the protocol. It furthermore requires the protocol/DAO to cover all missing funds.

Stage 1: Analysis & DAO Vote

Step 1.1

Publish list #1 of accounts, showing all deposits and borrows of underlying tokens of a single account, snapshot from time of freeze, include also accounts from staking contract

Publish list #2 of accounts, based on list #1 with the following changes

  • wstETH and stETH deposits and borrows get converted to ETH, at the exchange rate at time of freeze (no staking rewards paid out after time of hack) (avoid slippage for the DAO/protocol due to large swaps)
  • USCD deposits and borrows get converted to DAI, at an exchange rate of 1.0
  • self-collaterized (deposit and borrow in same underlying) positions cancelled out
  • account for the “lucky user” by adding 86ETH (amount needs to be validated) of borrows to their account.

Publish list # 3 of tokens showing total supply, borrows, and net difference of each token

Publish list # 4 of tokens with all existing funds marked for euler users, which include funds recovered from hacker, insurance payout, the euler market contract.

Publish list # 5 of tokens required to be covered by the DAO treasury (includes WBTC). This is the difference between list #3 and #4.

Step 1.2

Waiting time of 3 days, open for comments to find potential errors in lists, restart waiting time after each change to a list.

Step 1.3

DAO vote to finalize lists.

Stage 2: Funds

DAO aquires funds from list #5.

Stage 3: “Early Distribution”

Distribution via merkle tree contract, specified and developed by euler labs team. List #2 will be used as basis.

Step 3.1

Accounts with open borrows have the possibility to voluntarily repay their borrows by directly sending to the treasury. Update list #2 accordingly. First window is open for 3 days until snapshot.

Step 3.2

The following requirements have to be met for an account to be included in the merkle tree:

  • Account has only deposits, and no open borrows. We will refer to those accounts as “Merkle Tree Permitted” (MTP) accounts.

The following requirements have to be met for an token to be included in the merkle tree:

  • Calculate the total sum of required funds for each token from only MTP accounts. Include the token for early distribution via merkly tree only, if funds for all MTP accounts can be covered by available funds. This tries to avoid a situation where MTP accounts can e.g. claim a total of 1000 TOKENX, but only 500 TOKENX are available, as not enough borrows have been returned, yet.

Step 3.3 Repeat process every 1-2 weeks until protocol is relaunched. Update list #2 accordingly after users have claimed tokens, or users have send back their borrowed tokens to the treasury.

Note, that the tokens permitted for the merkle tree can therefore change over time, i.e. some tokens are included in a next update after enough borrows are returned, or some tokens need to be removed again if the required amount increases due to new MTP accounts.

Non-EOA accounts (parallel to process above)

Non-EOA accounts which cannot claim from the contract can contact the euler team for a separate proof process, and manual distribution of funds.

(optional, to be determined)
DAO vote before each merkle tree update. DAO vote before each manual distribution of funds to non-EOA accounts.

Stage 4: “Protocol Relaunch Distribution”

Users who cannot or do not want to claim their tokens on the early distribution process, will get eToken/dToken balances set on the protocol relaunch. Users should expect this to take a long time, but will therefore have the possibility to get original tokens back. We are rewarding those users willing to wait by returning their original token balances denominated in wstETH, stETH, USDC.

It is expected that slippage is now much smaller, as most users have already claimed in ETH/DAI - the DAO covers slippage, and staking rewards since time of hack - users who wait will get their actual original amounts including staking rewards. The risk for protocol is much smaller now, since only the remaing accounts need to be manally set in the contracts now.

Step 4.1 Development and audit, including process for eToken/dToken balances.

Step 4.2 Snapshot / Stop of early distribution.

Step 4.3 DAO aquires funds for wstETH, stETH, USDC.

Step 4.4 Relaunch protocol. Set eToken/dToken balances of accounts who have not claimed during early distribution.

4 Likes
2

I like this idea. It gives the option to receive one’s original tokens, for those willing to wait longer and accept smart contract risk. It also is the best option for making depositors whole and to reboot the Euler protocol with it’s reputation restored.

1 Like
3

I appreciate the thought put into a new idea, but I do not support it.

Account has only deposits, and no open borrows. We will refer to those accounts as “Merkle Tree Permitted” (MTP) accounts.

Consider my case. I have open borrows but deposited almost everything I own in Euler. So, I do not have the means to pay back my debts outside of the funds I put into Euler, even though I have an excellent health factor before the hack and even today. So this proposal excludes me from merkle tree distribution even though I think I should be able to do participate. I do not mind what moment the snapshot of my borrowed assets is taken. I just want my money in my hands again. I do not want to wait for a protocol reboot which could take months for audits and the team said is off the table for the near future.

I like the Euler team’s proposal better, because at least everyone is treated the same. We can debate when a snapshot is taken or how the payouts are calculated, but in this proposal those who have the means to pay back benefit while those who cannot are doomed to wait.

Also, you know this will create TOTAL chaos when people accidentally send large amounts of money to the treasury address thinking that will repay their debt. Contracts can’t handle ERC20 token transfers so the team will have to manually calculate and verify who sent what when. A simpler, quickly auditable approach that doesn’t have special cases is far better in my opinion.

(If anything I interpreted wrong, I apologize, then maybe there is room for more clarity in the draft)

2 Likes
4

This proposal does not really address the core divide that we have all be arguing about for days, which is ‘What prices should be used for borrow liquidations?’ Most of us dislike the original proposal because it uses the moment of the freeze to snapshot asset prices to liquidate borrows, which is bad for longs but good for shorts. Rather than dig into it in detail though, your proposal just switches the liquidation prices for current market prices (by way of repayment), which is good for longs and bad for shorts.

How does your solution address the shorts who feel cheated because they are being forced to accept losses from short positions that they were deprived of the ability to manage for weeks? I would imagine that the Euler team is afraid of lawsuits from those aggrieved shorts, which is likely why they wrote the initial plan like they did. Unclear to me though, is why they are not similarly afraid of lawsuits from aggrieved longs being forced to liquidate their positions at an arbitrary point in the past with no timely notification of such action.

I believe that if the Euler team is truly intending to avoid any lawsuits over this, they are going to have to address the grievances of both longs and shorts in the recovery process. Doing so will likely require the use of treasury funds.

1 Like