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
To understand how Liquid Restaking Token protocols are built, it’s essential to grasp the architecture of EigenLayer, the pioneering restaking framework on Ethereum. EigenLayer functions as a set of smart contracts that allow users to deposit either native ETH or Liquid Staking Tokens (LSTs) and opt-in to secure external modules (AVSs). In doing so, EigenLayer effectively “re-hypothecates” staked ETH, extending Ethereum’s security to other applications. When designing an LRT protocol on top of EigenLayer, one typically interfaces with EigenLayer’s contracts to manage deposits, withdrawals, and delegation of stake to operators. The LRT protocol itself usually issues a token (the LRT) to represent users’ positions, and handles the tracking of rewards and risks.
Let’s break down the core components and workflows of EigenLayer, as any LRT implementation must work within this system. The key smart contracts/modules in EigenLayer’s core are often named in code as StrategyManager, EigenPod (and EigenPodManager), DelegationManager, and WithdrawalRouter, among others. At a high level:
Core Components
Roles, Assets and Share Accounting
The documentation distinguishes stakers, anyone who deposits native ETH through an EigenPod or ERC-20 tokens through the StrategyManager, from operators, who run off-chain software for AVSs and accept delegated stake. A single wallet can be both. Every deposit is converted into shares under the chosen strategy; those shares, not raw token balances, are what the DelegationManager moves, slashes or withdraws.
For LRT builders this means the ERC-20 that represents user positions must mirror the share ledger, not the nominal token amount. If an operator is slashed, the AllocationManager instructs the DelegationManager to burn a slice of that operator’s shares; the LRT contract must propagate the same proportional reduction to its total supply or exchange-rate, otherwise it becomes under-collateralised.
Deposit and Delegation Flow
A user supplying, say, stETH to an LRT front-end hands tokens to the StrategyManager, which mints new strategy shares. Until the user delegates, those shares remain idle; delegation is a single call that assigns all of the wallet’s shares (across every strategy) to a chosen operator. The LRT may automate this step, typically pointing all deposits to a whitelisted operator set that the protocol itself controls, yet the underlying restriction still applies. Native-ETH restakers follow a two-phase path: they deploy an EigenPod, activate a Beacon validator, and only after the pod verifies withdrawal credentials does the DelegationManager credit shares, at which point the LRT can mint its token against the validator’s balance.
Withdrawal Path and Cool-down
ELIP-002 fixes the withdrawal delay as the guard-rail that gives the system time to detect equivocation or downtime before stake leaves. An LRT redeem function therefore performs:
- Undelegate shares, starting the queue timer.
- After the delay, call
completeQueuedWithdrawal, optionally “as shares” if the user wants to switch operators without exiting, or “as tokens” to receive the underlying ERC-20. - Burn the LRT.
For native ETH the pod must also exit the validator before a final transfer. Every hop goes through the DelegationManager, so gas-bounded queues and per-epoch limits govern throughput; an LRT should surface those details in its UI to avoid surprising users.
Rewards Accrual
Rather than streaming rewards continuously, EigenLayer batches them. Each AVS (or its middleware) submits period data, an off-chain updater aggregates stake-weighted totals, and the RewardsCoordinator stores only a Merkle root. The LRT contract can either pull and synchronously forward claims to holders or, more efficiently, let holders call claim on the coordinator themselves and then deposit the received tokens back into the LRT pool. Because claims are in arbitrary ERC-20s, many LRT designs swap everything to ETH before reinvesting, keeping the token single-asset backed.
The rewards merkle tree is structured in the diagram below:
Slashing, Operator-Set Allocations and Risk Segmentation
The AllocationManager’s operator-set model introduces a new design vector for LRT protocols: how much of their pooled stake to expose to each AVS. A conservative LRT might cap allocation at, say, 25 % per AVS, limiting blast radius. An aggressive product could allocate 100 % for maximum yield. Either way, allocation is per-strategy percentage, and operators must explicitly call the manager to update it. If an operator never registers the allocation, their delegated stake is not considered slashable, which in turn means no extra yield so an LRT must audit its operator to ensure allocations match its advertised strategy.
Integrating the Permission Layer
Because only specific addresses may post reward roots or execute administrative slashing, many AVSs will delegate those rights to off-chain bots via the PermissionController. LRT developers should verify that the controller settings of their target AVSs cannot arbitrarily seize or pause funds. Likewise, if the LRT runs its own operator infrastructure, it should delegate narrowly scoped permissions rather than using a monolithic admin key.
Putting It All Together for an LRT
Implementing an LRT under v1.3.0 therefore reduces to five obligations:
- Accept deposits and mint an ERC-20 that represents DelegationManager share-balance, not token balance.
- Delegate newly minted shares to an operator (or operator set) whose AllocationManager commitments align with the LRT’s advertised risk/return.
- Listen for RewardsCoordinator periods; harvest or surface claims so that rewards increase each token’s claim on underlying assets.
- Mirror any DelegationManager burn events whether user-initiated withdrawals or AllocationManager-initiated slashes into the LRT’s accounting.
- Implement the full undelegate-queue-withdraw flow transparently, handling the special validator-exit path for EigenPod deposits.
A well-designed LRT contract treats EigenLayer as the single source of truth: it never assumes balances, never bypasses the cooldown, and it reconciles share supply on every state change. With those invariants in place, an LRT can safely abstract the formidable complexity of EigenLayer 1.3.0 into a single ERC-20 interface, leaving developers and auditors free to focus on higher-level economics rather than low-level plumbing.
Conclusion
Implementing an LRT protocol requires a robust architecture that manages deposits, delegation, and withdrawal of restaked assets while maintaining security. EigenLayer’s design provides a blueprint: separate modules for each concern, careful handling of Ethereum beacon chain interactions, and a delegation system to connect stakers with service operators. We see how EigenLayer enables open innovation by letting third parties build liquid restaking tokens on top of itt. In Part 3, we will shift our focus to the vulnerabilities and risks in LRT systems. As with any complex DeFi protocol, there are numerous things that “can go wrong,” from smart contract bugs to economic exploits understanding these is key for developers and auditors working with LRTs.
