🐜Example Vulnerability 2
Last updated
Last updated
Code4rena Bug Bounty Payout
Vulnerability Overview: In Ethereum 2.0's Proof of Stake (PoS) model, validators who fail to meet the network's expectations can be penalized through a process known as slashing. Slashing substantially reduces a validator's staked Ethereum (ETH). The vulnerability here arises in the context of liquid staking, where the peg of a synthetic asset (e.g., frxETH) to the original staked asset (ETH) is jeopardized due to slashing events. If the validator's balance falls below the minimum required 32 ETH staking balance, it poses further risks.
Why It's Problematic:
Asset Peg Disruption: Liquid staking works by representing staked assets with synthetic or derivative tokens, like frxETH in this case. These tokens are expected to maintain a peg to the original asset (ETH). A slashing event can devalue the staked ETH, causing the pegged frxETH's value to misrepresent the underlying asset's actual worth. This discrepancy undermines trust in the liquid staking system and may impact token liquidity.
Maintaining Minimum Balance: Ethereum 2.0 mandates a minimum staking balance of 32 ETH for validators. If slashing causes the balance to drop below this threshold, it disrupts the staking process. This scenario raises questions: Who will replenish the balance? If the balance isn't restored, what happens to the staked amount?
Financial Implications for Stakers: If the peg is not maintained, those holding the synthetic assets might experience financial losses. Moreover, if the system does not define clear procedures for handling cases where validators fall below the required balance, users' staked assets might be at risk.
Recommended Mitigation Steps:
Peg Maintenance Mechanism: Implement a system to ensure that frxETH (or any synthetic representation of staked ETH) remains pegged to its true value. One way to achieve this is by burning the equivalent amount of frxETH if the underlying ETH gets slashed.
Addressing Minimum Balance Issues: The protocol should clearly define the procedures for situations where a node's balance drops below 32 ETH. It should clarify whether the responsibility of replenishing falls on the protocol, node operators, or another entity. If replenishing isn't viable, the protocol must have a process to safely withdraw the remaining ETH and distribute it appropriately.
In essence, while liquid staking offers the advantage of liquidity, it is essential to address vulnerabilities tied to Ethereum 2.0's staking model to ensure user confidence and asset security.
Example from the wild
