Open
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
yvesbou
requested changes
Sep 3, 2025
Co-authored-by: Yves Boutellier <63062257+yvesbou@users.noreply.github.com>
Co-authored-by: Yves Boutellier <63062257+yvesbou@users.noreply.github.com>
Co-authored-by: Yves Boutellier <63062257+yvesbou@users.noreply.github.com>
yvesbou
requested changes
Sep 12, 2025
|
|
||
| All contracts in the protocol can be upgraded by a [4-out-of-7 multisig](#security-council) with a delay of 3 days. This includes the `eETH` and `WeETH` tokens and the contracts handling validator withdrawals. Through an upgrade, the multisig could reattribute the ownership of all funds in the protocol, which would lead to the _loss of user funds_ and _loss of unclaimed yield_. As the signers are not announced, it does not qualify for the role of security council. | ||
|
|
||
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [3-out-of-5 multisig](#security-council) has a limited 10 minutes window to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin`contract. |
Collaborator
There was a problem hiding this comment.
Suggested change
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [3-out-of-5 multisig](#security-council) has a limited 10 minutes window to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin`contract. | |
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [3-out-of-5 multisig](#security-council) has a limited window of 10 minutes to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin` contract. |
Collaborator
There was a problem hiding this comment.
after which a Depositor EOA can execute the corresponding actions through the
EtherFiAdmincontract.
what are the corresponding actions exactly?
Member
Author
There was a problem hiding this comment.
the actions on the EtherFiAdmin, it includes approving registered validators, handling exits and withdrawals, rebasing the token ,etc. The EOA can only trigger the transaction through etherfi admin, but any action performed is deducted directly from the oracle report, not from the EOA
|
|
||
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [3-out-of-5 multisig](#security-council) has a limited 10 minutes window to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin`contract. | ||
|
|
||
| New validators are created in two phases when enough `ETH` has been depositted. First, any 1-of-6 signers of the [ValidatorSpawner multisig](#security-council) can create validators and deposit 1 `ETH` to them using user deposited `ETH` in the `LiquidityPool`. The oracle then confirms the validity of the withdrawal credential and triggers the deposit of the remaining `ETH` (> 31 `ETH` per validator). The initial deposit is at risk of frontrunning and collusion between the signer and _Node Operator_, this is why deposits have to be confirmed by the oracle. In case of an attack, this would allow the signer and _Node Operator_ to steal the 1 `ETH` depositted for each validator. However, this is of limitted impact given that this concerns a minority of protocol funds. |
Collaborator
There was a problem hiding this comment.
I think this section rather belongs to the Protocol analysis section
Collaborator
There was a problem hiding this comment.
"New validators are created in two phases when enough ETH has been depositted. First, any 1-of-6 si..."
|
|
||
| New validators are created in two phases when enough `ETH` has been depositted. First, any 1-of-6 signers of the [ValidatorSpawner multisig](#security-council) can create validators and deposit 1 `ETH` to them using user deposited `ETH` in the `LiquidityPool`. The oracle then confirms the validity of the withdrawal credential and triggers the deposit of the remaining `ETH` (> 31 `ETH` per validator). The initial deposit is at risk of frontrunning and collusion between the signer and _Node Operator_, this is why deposits have to be confirmed by the oracle. In case of an attack, this would allow the signer and _Node Operator_ to steal the 1 `ETH` depositted for each validator. However, this is of limitted impact given that this concerns a minority of protocol funds. | ||
|
|
||
| Restaking rewards are distributed either through the [KING Protocol](https://kingprotocol.org/) or EtherFi's own distributor contracts. Both solutions requires a multisig to post a merkle root onchain. The KING Protocol's root can be updated at any time by their [multisig](#security-council), which could be used to revoke distributed rewards and lead to the _loss of unclaimed yield_. |
Collaborator
There was a problem hiding this comment.
I think the relationship between EtherFi and KING protocol needs to be outlined in the Summary at the very beginning if it's dropped like this
yvesbou
reviewed
Sep 12, 2025
| - The _Operator_ delegate their entire stake to the _AVSs_ they operate for. In practice, this leads to their stake being "duplicated" for each _AVS_. | ||
| - The _AVSs_ cannot slash the _Operators_. As such, misbehaviour from the _AVSs_ or _Operators_ cannot lead to the _loss of user funds_. However, _loss of unclaimed yield_ remains possible as the _AVSs_ are trusted to distribute the rewards fairly and could refuse to do so. | ||
|
|
||
| This version of the protocol could be deprecated in the future. The contract addresses of each operator is listed in the [Eigenlayer Operators table](#eigenlayer-operators). |
Collaborator
There was a problem hiding this comment.
Suggested change
| This version of the protocol could be deprecated in the future. The contract addresses of each operator is listed in the [Eigenlayer Operators table](#eigenlayer-operators). | |
| Operator allocations to AVSs are subject to slashing in the future. The contract addresses of each operator is listed in the [Eigenlayer Operators table](#eigenlayer-operators). |
Member
Author
There was a problem hiding this comment.
But there is no guarantee that they will force etherfi to use upgraded version right? Or is it that for all protocols currently on Eigenlayer there is no slashing?
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
|
|
||
| All contracts in the protocol can be upgraded by a [4-out-of-7 multisig](#security-council) with a delay of 3 days. This includes the `eETH` and `WeETH` tokens and the contracts handling validator withdrawals. Through an upgrade, the multisig could reattribute the ownership of all funds in the protocol, which would lead to the _loss of user funds_ and _loss of unclaimed yield_. As the signers are not announced, it does not qualify for the role of security council. | ||
|
|
||
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [3-out-of-5 multisig](#security-council) has a limited 10 minutes window to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin`contract. |
Collaborator
There was a problem hiding this comment.
Suggested change
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [3-out-of-5 multisig](#security-council) has a limited 10 minutes window to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin`contract. | |
| An [oracle](#stakers-and-operators) with 2-out-of-3 signers reports onchain on the state of the beacon chain and the performance of the EtherFi validators. This information is critical to the functioning of the protocol and if manipulated could be used to mint excessive `eETH` and dilute users, or wrongfully rebase the token, leading to _loss of user funds_ and/or the _loss of unclaimed yield_. Once the oracle members submit a report, a [EtherFi Undeclared Multisig #1](#security-council) (3-out-of-5 multisig) has a limited 10 minutes window to cancel it, after which a [Depositor EOA](#security-council) can execute the corresponding actions through the `EtherFiAdmin`contract. |
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
|
|
||
| The staked `ETH` associated with `eETH` is restaked onchain using the Eigenlayer protocol. EtherFi delegates their staked `ETH` to _Eigenlayer Operators_, those operators can choose which _Eigenlayer AVS_ they will operate for. EtherFi currently uses an implementation that could not lead to the _loss of user funds_ or _loss of unclaimed yield_ because there is no slashing of funds, as discussed in the [dependencies](#dependencies) section. | ||
|
|
||
| We analysed the Eigenlayer protocol to be of Stage 0 in a [dedicated report](/protocols/eigenlayer/ethereum#dependencies). However, the Eigenlayer protocol would be classified as Stage 1 if the criteria _Accessibility_ was ignored. Since EtherFi interacts programmatically with Eigenlayer, _Accessibility_ does not affect its centralization risks as a dependency. The Stage 1 equivalent dependency impacts EtherFi's own score and limits it to a _Medium_ centralization risk for the _Autonomy_ dimension. |
Collaborator
There was a problem hiding this comment.
Suggested change
| We analysed the Eigenlayer protocol to be of Stage 0 in a [dedicated report](/protocols/eigenlayer/ethereum#dependencies). However, the Eigenlayer protocol would be classified as Stage 1 if the criteria _Accessibility_ was ignored. Since EtherFi interacts programmatically with Eigenlayer, _Accessibility_ does not affect its centralization risks as a dependency. The Stage 1 equivalent dependency impacts EtherFi's own score and limits it to a _Medium_ centralization risk for the _Autonomy_ dimension. |
yvesbou
requested changes
Sep 12, 2025
|
|
||
| The staked `ETH` associated with `eETH` is restaked onchain using the Eigenlayer protocol. EtherFi delegates their staked `ETH` to _Eigenlayer Operators_, those operators can choose which _Eigenlayer AVS_ they will operate for. EtherFi currently uses an implementation that could not lead to the _loss of user funds_ or _loss of unclaimed yield_ because there is no slashing of funds, as discussed in the [dependencies](#dependencies) section. | ||
|
|
||
| We analysed the Eigenlayer protocol to be of Stage 0 in a [dedicated report](/protocols/eigenlayer/ethereum#dependencies). However, the Eigenlayer protocol would be classified as Stage 1 if the criteria _Accessibility_ was ignored. Since EtherFi interacts programmatically with Eigenlayer, _Accessibility_ does not affect its centralization risks as a dependency. The Stage 1 equivalent dependency impacts EtherFi's own score and limits it to a _Medium_ centralization risk for the _Autonomy_ dimension. |
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
|
|
||
| Each EtherFi's Ethereum validator has its withdrawal address set to a dedicated `EigenPod` contract. The `EigenPod` contracts are upgradeable by an [Eigenlayer multisig] which meets the security council requirements. Upgrading this contract could allow the multisig to trigger withdrawals and redirect the funds to an arbitrary address, leading to the _loss of user funds_. | ||
|
|
||
| We analysed the Eigenlayer protocol to be of Stage 0 in a [dedicated report](/protocols/eigenlayer/ethereum#dependencies). This impacts EtherFi's own score and limits it to a _Medium_ centralization risk for the _Autonomy_ dimension. |
Collaborator
There was a problem hiding this comment.
Suggested change
| We analysed the Eigenlayer protocol to be of Stage 0 in a [dedicated report](/protocols/eigenlayer/ethereum#dependencies). This impacts EtherFi's own score and limits it to a _Medium_ centralization risk for the _Autonomy_ dimension. |
yvesbou
reviewed
Sep 12, 2025
yvesbou
reviewed
Sep 12, 2025
|
|
||
| [To date](https://community.chaoslabs.xyz/etherfi/risk/avs), the staked `ETH` is restaked through 12 _EigenLayer Node Operators_ across 17 _EigenLayer AVSs_. The funds are not equally distributed among _Operators_ and _AVSs_; the _Operator_ and _AVS_ with the highest concentrations have 17.5% and 9.9% respectively." | ||
|
|
||
| Each EtherFi's Ethereum validator has its withdrawal address set to a dedicated `EigenPod` contract. The `EigenPod` contracts are upgradeable by an [Eigenlayer multisig] which meets the security council requirements. Upgrading this contract could allow the multisig to trigger withdrawals and redirect the funds to an arbitrary address, leading to the _loss of user funds_. |
Collaborator
There was a problem hiding this comment.
Suggested change
| Each EtherFi's Ethereum validator has its withdrawal address set to a dedicated `EigenPod` contract. The `EigenPod` contracts are upgradeable by an [Eigenlayer multisig] which meets the security council requirements. Upgrading this contract could allow the multisig to trigger withdrawals and redirect the funds to an arbitrary address, leading to the _loss of user funds_. | |
| EtherFi is impacted by the Stage 1 centralization risk, because of the upgradeability risk within Eigenlayer, since each EtherFi's Ethereum validator has its withdrawal address set to a dedicated Eigenlayer controlled `EigenPod` contract. The `EigenPod` contracts are upgradeable by an Eigenlayer multisig which meets the security council requirements. Upgrading this contract could allow the multisig to trigger withdrawals and redirect the funds to an arbitrary address, leading to the _loss of user funds_. |
Collaborator
There was a problem hiding this comment.
not sure if we should keep this, but if so, I would add some context
yvesbou
requested changes
Sep 12, 2025
|
|
||
| [To date](https://community.chaoslabs.xyz/etherfi/risk/avs), the staked `ETH` is restaked through 12 _EigenLayer Node Operators_ across 17 _EigenLayer AVSs_. The funds are not equally distributed among _Operators_ and _AVSs_; the _Operator_ and _AVS_ with the highest concentrations have 17.5% and 9.9% respectively." | ||
|
|
||
| Each EtherFi's Ethereum validator has its withdrawal address set to a dedicated `EigenPod` contract. The `EigenPod` contracts are upgradeable by an [Eigenlayer multisig] which meets the security council requirements. Upgrading this contract could allow the multisig to trigger withdrawals and redirect the funds to an arbitrary address, leading to the _loss of user funds_. |
Collaborator
There was a problem hiding this comment.
not sure if we should keep this, but if so, I would add some context
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.