Blockchain security isn't optional.
Protect your smart contracts and DeFi protocols with Three Sigma, a trusted security partner in blockchain audits, smart contract vulnerability assessments, and Web3 security.
Get a Quote Today
Introduction
In Part 2, we discussed how LRT protocols are constructed on top of EigenLayer. With that foundation, it becomes clear that LRT systems introduce significant complexity, and wherever there is complexity in smart contracts and financial design, there are potential vulnerabilities. In fact, experience has shown that liquid (re)staking protocols are rife with unique pitfalls. In this part, we will delve into common vulnerabilities and risks in LRT protocols. These include smart contract bugs that audits have uncovered in early LRT implementations, as well as economic and systemic risks inherent to the concept of liquid restaking. All information is drawn from documented audits and research, no hypothetical scare stories, only real issues that developers and auditors must keep in mind.
One thing to understand is that LRT protocols combine challenges from multiple domains: they inherit risks from DeFi (like reentrancy and flash loan attacks) and risks from staking (slashing conditions, withdrawal delays), plus new risks arising from their multi-layered nature. With innovation comes exploitable risk, without careful implementation, features like restaking can open the door to reentrancy attacks, DoS conditions, incorrect accounting, and more. Below, we categorize and summarize the most prevalent issues:
Smart Contract Vulnerabilities
Incorrect Reward Accounting
LRT protocols aggregate rewards from multiple sources. If the accounting for who deserves what is wrong (for instance, rounding errors or precision issues when converting shares to tokens), it can be exploited. Decimal precision handling is important, an error here might let users withdraw more than they should or leave “dust” that adds up over time. Using consistent fixed-point math and thorough unit tests for edge cases (like very small or very large stake amounts) can prevent this.
Cooldown/Withdrawal Queue Manipulation
LRT systems rely on cooldowns (like EigenLayer’s 1-week exit queue) to function safely. But those can be manipulated. One scenario is griefing attacks, a malicious actor could repeatedly join and exit in small increments to bloat the withdrawal queue or force many small withdrawals, trying to exhaust gas or keep others’ funds locked longer. Another is exploiting timing, e.g., withdrawing just before a slashing event to avoid penalties, or conversely, attempting to withdraw and re-enter to dodge being slashed. If withdrawal cooldowns aren’t handled correctly, users might evade penalties or mess with system state. LRT developers must ensure that any “lockup” or cooldown logic is foolproof, you likely need to lock a user’s stake through the entire period it’s supposed to be at risk. And when designing exit queues, consider limiting queue size per user or processing in a way that one user can’t stall everyone else.
Merkle Proof and Oracle Issues
EigenLayer introduces dependency on off-chain data, notably, beacon chain proofs for validator exits or withdrawals are verified via Merkle proofs. If an LRT protocol supplies these (or uses an oracle service to supply them), there’s a potential for spoofing. Predictable Merkle tree structures can be targets if any component (height, leaf, root) can be tampered with.
Reentrancy Attacks
Complex interactions between contracts make reentrancy a top concern. An attacker might exploit a callback in the middle of a withdrawal or delegation process to manipulate balances. Developers should update state before external calls, use nonReentrant guards, and follow the checks-effects-interactions pattern to avoid this. Because LRT protocols often hold significant value, a reentrancy bug can be catastrophic (draining funds or registering false stake).
Unbounded Loops (DoS via Gas Limits)
Functions that iterate over dynamic arrays of stakes, delegations, or withdrawals can run into gas limits or be used for denial-of-service. For example, if a user has restaked into many strategies or frequently rebalances, a withdrawal function that loops through all their positions could fail. Auditors have warned to avoid unbounded loops e.g., limit the number of tokens or delegations processed per call, or use queue structures that can be processed in chunks. Failing to do so could let an attacker block withdrawals or other critical actions by bloating lists.
Economic and Systemic Risks for LRTs
Leverage and Recursive Strategies
A notable emergent risk is recursive borrowing or “looping” with LRTs. For example, a user could restake ETH to get an LRT, then use that LRT as collateral in a lending platform to borrow more ETH (or stablecoins), which they then buy more ETH and restake again, repeating the cycle. This builds a leveraged position on staked ETH. While it boosts yield when prices are stable or rising, it amplifies losses if the underlying ETH or LRT price falls even slightly. A small dip can trigger liquidations in such loops, potentially causing a cascade as many users unwinding at once could crash the LRT price further. This dynamic is akin to traditional financial leverage, it can magnify volatility. LRT protocols themselves might not directly control this (it often happens in external lending markets), but it’s a risk to be aware of in the ecosystem. If your LRT becomes popular, expect others to try leveraging it, and consider collaborating with lending platforms to set safe parameters (like conservative collateral factors).
Liquidity Crises and Redemption Risk
As mentioned, some early LRT implementations lacked a direct unstaking mechanism. Users had no choice but to sell the LRT in the market if they wanted to exit. If those markets are “thin” (low liquidity) and many users rush to exit (say due to a rumor or incident), the LRT price can plummet below the value of the underlying ETH. This de-pegging not only hurts holders but can also reduce trust in the protocol. Even with a withdrawal function in place, it typically has a delay (e.g. one week on EigenLayer), during that time, panicked users may still sell at a discount rather than wait. It’s crucial for LRT projects to build liquidity or redemption outlets for users. That could mean incentivizing liquidity pools, integrating with exchange platforms, or at least being transparent about how one can exit. The lack of liquidity is a systemic risk that can spiral: if one LRT faces a run and price collapse, and other protocols held it as collateral or in their treasury, it can spread trouble across DeFi (a smaller-scale analogy to bank runs). Designers should also consider emergency shutdown scenarios, e.g., if an AVS fails, how to unwind positions in an orderly way.
Validator and Operator Centralization
By pooling stake and delegating to operators, restaking protocols risk concentrating a lot of power in a few operators if not careful. If, say, one operator or a small set of them attract the majority of delegations (perhaps due to offering slightly higher rewards or being seen as “safer”), they become highly influential. This centralization pressure can undermine the security of the ecosystem. A malicious or coerced dominant operator could potentially violate multiple AVSs at once. Or if that operator has downtime, many services suffer simultaneously. Mitigations include setting delegation limits per operator, encouraging decentralization (maybe via social consensus or UI nudges for users to pick smaller operators), and ensuring there’s no single point whose failure breaks everything. Over time, if restaking leads to only a few big validator conglomerates, it starts to resemble traditional systems in terms of concentration risk.
Cascading Failures Across Layers
Restaking connects previously independent systems, which can lead to contagion effects. Consider if a major AVS (for example, a popular cross-chain bridge) that a lot of restakers opted into gets hacked or fails, the operators might get slashed (when slashing is live), which means all those restakers lose a chunk of their stake. That could prompt those users to withdraw everything, affecting other AVSs as well by reducing security. In a liquid staking world, one protocol’s failure generally doesn’t slash your stake on another. But in a restaking world, one failure can have ripple effects through the shared stake pool. This interdependence means the systemic risk is higher. We saw a preview of this during EigenLayer’s initial growth: at one point, EigenLayer’s total value locked was extremely high (tens of thousands of ETH), effectively meaning many projects’ security was co-mingled. A failure in one could have dented confidence in all. The recommendation here is strong risk isolation and modularity, AVS developers and the restaking protocol should design so that a failure triggers only the necessary slashing and doesn’t inadvertently bankrupt honest participants or unrelated services. Also, the restaking protocol might maintain an insurance fund or coverage plan for certain catastrophic events to help stabilize things.
Governance and Opaque Risk
LRT projects introduce governance questions, e.g., who decides adding a new AVS or token support, updating parameters, etc. If governance is token-based (perhaps using an LRT or a native token), that itself can be attacked (governance takeovers via token accumulation). Furthermore, the EigenLayer team has cautioned against an “arms race of opaque risk-taking”. This implies that if one LRT project quietly engages in very risky strategies to offer a higher yield, others might feel pressure to also take on more risk to compete, and users won’t easily understand the hidden dangers. Transparency is key: users should know if an LRT is, for example, leveraging 3x or putting funds into an experimental AVS. Complex risk engineering should be made clear through documentation and perhaps even ratings or warnings. Governance mechanisms could enforce disclosures or safety checks (like not allowing infinite leverage or requiring audits for AVSs before they get whitelisted).
Regulatory and Compliance Risk
As LRTs grow, they may attract regulatory scrutiny, especially since they blur lines between staking (considered a form of yielding in crypto) and financial derivatives. Already, EigenLayer restricted U.S. users from its token airdrop, hinting at cautious regulatory compliance. Exchanges listing LRTs will consider local laws. Projects should be mindful of KYC/AML concerns if, for instance, institutional players want to use restaking. While not a vulnerability per se, compliance issues can pose a risk to longevity, e.g., a protocol might have to geo-fence certain areas or limit features, which could affect user behavior and system dynamics.
Conclusion
Liquid restaking protocols present a rich set of potential pitfalls a mix of traditional smart contract vulnerabilities (reentrancy, access control, arithmetic issues) and novel challenges arising from multi-layer staking and financial complexity. We’ve highlighted the importance of careful implementation and vigilance: developers must rigorously audit and test their contracts, and both developers and users should stay educated on the evolving risk landscape. The takeaway is not that LRTs are “too dangerous,” but that they require strong risk management at every level. With prudent design, many of these vulnerabilities can be mitigated (and indeed, the community is actively learning from early incidents). In Part 4, the final part of our series, we will look ahead to future trends and tokenomics in the LRT ecosystem. How will LRT projects evolve through 2025 and beyond? What innovations or changes can we expect in how these tokens are used and governed?
