Native vs. Liquid Restaking: A Builder's Framework

introduction

RESTAKING ARCHITECTURE DECISION

Introduction

A technical framework for builders choosing between native restaking and liquid restaking tokens when integrating EigenLayer security.

The decision to integrate with EigenLayer begins with a fundamental architectural choice: should a protocol, application, or service accept native restaked ETH or Liquid Restaking Tokens (LRTs)? This choice dictates the entire downstream security model, smart contract risk surface, and user experience. Native restaking involves direct interaction with EigenLayer's core contracts for depositing beacon chain ETH, while LRTs present a composable ERC-20 receipt representing a claim on a basket of restaked positions managed by a third-party protocol.

The trade-off space is defined by a tension between security purity and composability. Native restaking offers the most direct claim on EigenLayer's cryptoeconomic security, avoiding intermediary smart contract risk and the potential for liquidity crises during mass withdrawals. However, it introduces significant UX friction through unbonding delays and a lack of fungibility. LRTs solve this by providing instant liquidity and DeFi composability, but they introduce a new layer of trust assumptions, including the LRT protocol's governance, its operator selection logic, and the risk of de-pegging from the underlying restaked asset.

For builders, this is not merely a yield optimization question; it is a core infrastructure dependency. A lending protocol accepting an LRT as collateral inherits the slashing and withdrawal queue risks of every underlying AVS and operator the LRT protocol has delegated to. A bridge AVS that requires operators to stake a native asset must design its slashing logic to attribute faults to specific validators, a process complicated by the liquid wrapper. This framework provides a structured comparison of custody models, smart contract risk, yield mechanics, and upgradeability to guide an informed integration decision. Chainscore Labs can provide a formal security and operational trade-off assessment for teams evaluating this critical path.

NATIVE VS. LIQUID RESTAKING

Quick Facts

A comparative scan of custody, risk, yield, and upgradeability factors for builders choosing between native restaking and LRT integration.

Area	Native Restaking	Liquid Restaking (LRT)	Action
Custody Model	Assets locked in EigenPod or beacon chain; user retains full custody.	Assets deposited into an LRT protocol's smart contracts; user holds a derivative token.	Assess institutional custody requirements and single-counterparty risk tolerance.
Smart Contract Risk	Minimal additional contract surface beyond core EigenLayer contracts.	Expands risk to LRT protocol contracts, potential oracles, and withdrawal managers.	Review LRT contract upgradeability, governance, and audit history before integration.
Yield Optimization	AVS rewards accrue directly; no intermediate fee layer.	LRT protocols can auto-compound and optimize AVS selection for higher yield.	Model net yield after deducting LRT protocol fees and compare against direct restaking returns.
Liquidity and Composability	Staked position is illiquid; subject to unbonding delays.	LRT is a fungible ERC-20 token, usable as collateral in DeFi protocols.	Evaluate DeFi integration depth and liquidity for the specific LRT before accepting as collateral.
Upgradeability	Tied to EigenLayer core contract upgrades and beacon chain hard forks.	Subject to both EigenLayer upgrades and independent LRT protocol upgrade actions.	Map the multisig or governance control for LRT upgrades and establish a monitoring process.
Slashing Impact	Direct loss of staked principal.	Loss is socialized across LRT holders; token de-pegging risk is an additional failure mode.	Simulate slashing scenarios to model LRT de-pegging depth and recovery mechanisms.
Withdrawal UX	Complex queue-based exit with fixed waiting periods.	Typically faster exits via LRT liquidity pools, subject to slippage.	Design wallet flows that clearly communicate unbonding delays vs. instant-swap slippage costs.
Institutional Reporting	Direct tracking of principal, rewards, and slashing events.	Requires tracking cost basis of a derivative token and multiple reward streams.	Build or integrate an accounting system that handles LRT reward basis and taxable events.

technical-context

RESTAKING ARCHITECTURE COMPARISON

Technical Mechanism

A structural breakdown of how native and liquid restaking models differ in custody, delegation, and risk exposure within the EigenLayer ecosystem.

The core distinction between native and liquid restaking lies in the custody and programmability of the staked asset. Native restaking involves an Ethereum validator redirecting its beacon chain withdrawal credentials to an EigenPod, a smart contract that acts as a proof-of-stake bridge. The validator's 32 ETH stake remains locked in the beacon chain deposit contract, but the EigenPod verifies the validator's effective balance and allows the owner to opt into AVS validation. This model introduces no new tokenized representation; the security commitment is made directly by the validator's existing infrastructure, and rewards or slashing penalties are settled against the beacon chain balance via EigenLayer's proof system.

Liquid restaking decouples the staked asset from the validator's beacon chain position. A user deposits a liquid staking token (LST) like stETH or rETH into an EigenLayer strategy contract, receiving a liquid restaking token (LRT) in return. This LRT is a fungible, yield-bearing receipt that represents a claim on a basket of underlying LSTs and the AVS rewards they accrue. The LRT protocol, not the end-user, manages the delegation of the underlying assets to EigenLayer operators. This creates a layered trust model where the user is exposed to the smart contract risk of the LRT protocol, the underlying LST, and EigenLayer's slashing conditions, while gaining a liquid, composable token that can be used in DeFi without waiting for beacon chain unbonding periods.

For builders, the choice between these models is a decision about where to place technical and trust assumptions. Integrating native restaking requires building against EigenPod proofs, understanding beacon chain state, and managing withdrawal credential binding—a path suited for institutional stakers and exchanges that run their own validators. Integrating LRTs requires evaluating the specific LRT's contract architecture, withdrawal queue mechanics, and oracle dependencies for exchange rate calculation. A lending protocol accepting an LRT as collateral must model not just the LST's market risk, but also the LRT's potential for de-pegging during mass withdrawals or slashing events, making the integration surface significantly more complex than a standard ERC-20.

WHO MUST DECIDE BETWEEN NATIVE AND LIQUID RESTAKING

Affected Actors

DeFi Protocol Developers

Lending protocols, stablecoin issuers, and yield aggregators must evaluate LRTs as collateral against native restaked positions. Key considerations include:

Oracle risk: LRTs introduce an additional exchange rate feed dependency that native restaking avoids.
Withdrawal queue depth: During market stress, LRT exit liquidity can freeze while native unbonding follows predictable escrow delays.
Composability hazards: LRTs may rehypothecate across multiple AVSs, creating hidden correlation risk that native positions do not carry.

Protocol risk teams should model worst-case LRT de-pegging scenarios and compare them against the known unbonding period of native restaking. Chainscore can perform an LRT collateral acceptance review that stress-tests oracle assumptions, liquidity profiles, and composability exposure.

implementation-impact

BUILDER'S DECISION FRAMEWORK

Implementation Impact Areas

The choice between native and liquid restaking creates distinct integration paths with different custody models, smart contract risks, and operational requirements. These impact areas define what builders must address.

Custody and Key Management Architecture

Native restaking requires direct control of validator keys and EigenPod contracts, demanding institutional-grade key management with hot/cold separation and disaster recovery planning. Liquid restaking delegates custody to LRT protocols, shifting operational burden but introducing smart contract dependency. Builders must evaluate whether their existing HSM, MPC, or multisig infrastructure supports EigenPod operations or if LRT integration better matches their custody model. Chainscore can review key management architecture for native restaking deployments.

Smart Contract Risk Surface

Native restaking minimizes smart contract exposure by interacting primarily with EigenLayer core contracts and EigenPods, which have a smaller attack surface. LRT integration adds multiple layers of contract risk: the LRT token itself, its underlying strategy contracts, withdrawal queue logic, and any DeFi protocol composability. Each additional contract introduces upgradeability, governance, and oracle dependency risks. Builders integrating LRTs as collateral should conduct a full dependency graph analysis. Chainscore can perform an LRT integration risk assessment for collateral acceptance.

Withdrawal and Unbonding Flow Design

Native restaking enforces a fixed 7-day Ethereum-level unbonding period plus EigenLayer's escrow delay, requiring builders to design user communication strategies for delayed withdrawals and handle partial vs. full withdrawal mechanics. LRT protocols may offer faster liquidity through secondary markets or internal redemption pools, but these introduce exchange rate risk and potential de-pegging during high-demand periods. Wallet and exchange teams must implement clear transaction previews showing estimated completion times. Chainscore can review unbonding flow implementations for user safety and edge-case handling.

Yield Accounting and Reward Distribution

Native restaking generates rewards from multiple AVSs in diverse tokens, requiring builders to implement complex cost-basis tracking, fair market value calculations, and multi-token distribution logic. LRTs abstract this complexity by compounding rewards into a single rebasing or value-accruing token, simplifying accounting but obscuring the underlying reward sources. Institutional stakers and custodians must decide whether they need granular reward attribution for compliance reporting or can accept LRT-level abstraction. Chainscore can advise on accounting integration patterns for restaking yield.

Slashing Risk Monitoring and Response

Native restaking exposes operators to slashing from every AVS they opt into, requiring real-time monitoring of slashing events across all registered services and automated defensive actions. LRT protocols distribute slashing risk across all depositors, but the opacity of underlying operator selection and AVS opt-in decisions makes risk assessment difficult. Builders integrating LRTs need event listeners that can detect slashing events and trigger position unwinding or contract pauses. Chainscore can assist in designing a real-time risk monitoring and response system.

Upgradeability and Governance Dependency

Native restaking depends primarily on EigenLayer core contract governance, which uses a Security Council and timelock for upgrades. LRT protocols add their own governance layers, multisigs, and upgradeable proxy patterns that can alter withdrawal conditions, fee structures, or strategy allocations. Builders must map the full governance dependency tree and assess whether any single actor can freeze withdrawals or redirect funds. This is especially critical for protocols using LRTs as collateral in lending markets. Chainscore can assess governance dependency and upgradeability risk for LRT integrations.

NATIVE VS. LIQUID RESTAKING: KEY RISK DIFFERENTIATORS

Risk Matrix

A comparative risk assessment for builders evaluating the operational, smart contract, and economic security trade-offs between integrating native restaking and liquid restaking tokens (LRTs).

Risk Area	Native Restaking Concern	LRT Concern	Affected Actors	Mitigation Strategy
Smart Contract Surface	Direct interaction with core EigenLayer contracts; risk is limited to battle-tested, audited protocol code.	Exposure to additional LRT protocol contracts (e.g., vaults, delegation strategies, reward distributors) which may be less mature or upgradeable.	DeFi protocols, wallets, institutional stakers	Audit the specific LRT's smart contracts and access control. Prefer LRTs with immutable core contracts and a bug bounty program.
Custody and Control	The restaker retains full custody of their ETH in the beacon chain. The primary risk is slashing by an AVS.	The restaker cedes custody of ETH to the LRT protocol, introducing counterparty risk from the LRT's operators, governance, and security model.	Exchanges, custodians, individual restakers	Evaluate the LRT's governance structure, multisig signers, and withdrawal credential management. For institutional custody, native restaking is often the lower-risk baseline.
Liquidity and Composability	Restaked ETH is locked and illiquid. It cannot be used as collateral in DeFi, creating opportunity cost.	LRTs are fungible ERC-20 tokens designed for DeFi composability, but can depeg from the underlying ETH value, especially during market stress or slashing events.	Lending protocols, DEXs, stablecoin issuers	For LRTs, implement robust oracle price feeds, monitor on-chain liquidity depth, and set conservative collateral ratios to account for potential depegging.
Slashing Risk Propagation	Slashing is isolated to the AVSs an operator has opted into. A restaker delegating to a penalized operator loses a portion of their principal.	A slashing event on an underlying operator can cause an immediate LRT depeg and trigger cascading liquidations across all DeFi protocols using that LRT as collateral.	Risk managers, DeFi protocol operators, LRT holders	Monitor operator opt-in status and slashing history. For DeFi protocols, build circuit breakers that can pause LRT deposits or adjust risk parameters upon a large slashing event.
Yield Optimization	Rewards are limited to the specific AVSs the chosen operator serves. Yield is passive and non-optimized.	LRT protocols can algorithmically optimize delegation across the highest-yielding operators and AVSs, but this introduces complex, opaque strategy risk.	Yield aggregators, institutional stakers	Understand the LRT's delegation strategy logic. Verify it is implemented on-chain and not reliant on off-chain, unverifiable computation.
Withdrawal Experience	Withdrawals are subject to EigenLayer's long unbonding period (e.g., 7 days), creating a predictable but illiquid exit queue.	LRTs offer instant liquidity via DEXs, but large withdrawals may face significant slippage. The LRT's own withdrawal queue from EigenLayer adds a hidden, second-layer liquidity risk.	Wallets, exchanges, large liquidity providers	Model the LRT's total value locked (TVL) against available DEX liquidity. For large positions, compare the cost of DEX slippage against the time cost of the native unbonding queue.
Upgradeability Risk	Core EigenLayer contracts are upgradeable by a multisig, a systemic risk for all restakers.	LRT contracts add another layer of upgradeability risk. A malicious or compromised LRT admin could alter delegation strategies, fee models, or even steal underlying deposits.	Security auditors, governance delegates, integrators	Map the upgradeability permissions for both EigenLayer and the LRT. Prefer LRTs with a timelock on upgrades and a clear, decentralized governance process.
Operator Selection	The restaker must perform due diligence on individual operators, assessing their performance, slashing history, and security posture.	The LRT protocol handles operator selection, abstracting this complexity but creating a principal-agent problem where the protocol may not align with the restaker's risk tolerance.	Institutional stakers, risk-averse individuals	Review the LRT's operator selection criteria and allowlist. If the criteria are opaque or controlled by a small team, the delegation risk is high.

RESTAKING MODEL SELECTION

Builder's Decision Checklist

A structured checklist for protocol architects and engineering leads evaluating whether to build on native restaking or integrate Liquid Restaking Tokens (LRTs). Each item identifies a critical decision point, explains its operational significance, and defines the signal that confirms readiness.

What to check: Does your application require direct control over the timing and destination of ETH withdrawals, or can it accept a tokenized IOU?

Why it matters: Native restaking gives the depositor direct control over the unbonding process and withdrawal finality. LRTs abstract this away, introducing a dependency on the LRT protocol's withdrawal queue, liquidity, and governance. If your application needs to guarantee timely exits (e.g., for a lending protocol facing liquidations), the LRT's redemption latency and potential for withdrawal pauses become a critical risk.

Readiness signal: You have modeled the worst-case withdrawal duration for both native restaking (EigenLayer's escrow period) and the target LRT (queue depth + governance timelock) and confirmed it aligns with your protocol's liveness requirements.

resource-links

CANONICAL REFERENCES

Source Resources

Use these sources to verify EigenLayer mechanics, contract interfaces, delegation flows, and LRT-specific assumptions before choosing native restaking or liquid restaking token integration.

EigenLayer Documentation

Start with the official EigenLayer docs when mapping the native restaking path: supported asset types, delegation flows, withdrawal behavior, operator relationships, AVS concepts, and protocol terminology. Builders should treat this as the baseline for user flows and system assumptions, then verify whether any feature is live, gated, or subject to phased rollout. For a native restaking integration, use the docs to define transaction sequencing, signer responsibilities, withdrawal expectations, and operator-selection UX before writing application logic.

EXPLORE

EigenLayer Core Contracts Repository

Use the EigenLayer contracts repository to inspect interfaces, ABIs, upgrade patterns, tests, and integration-relevant contract behavior. This is critical when comparing native restaking against LRT exposure: native integrations depend directly on EigenLayer contract semantics, while LRT integrations inherit both EigenLayer risk and the issuer’s wrapper, accounting, oracle, and withdrawal logic. Engineering teams should pin reviewed commits, verify deployed addresses against official sources, and test edge cases such as queued withdrawals, delegation changes, and reward-accounting updates.

EXPLORE

EigenLayer App for Production Flow Validation

The EigenLayer app is useful for observing the production user journey around restaking, delegation, operator selection, and withdrawal actions. Wallets, custodians, and DeFi front ends should not copy UI behavior blindly, but they can use it to validate terminology, sequencing, warnings, and user expectations. Compare app behavior with contract calls and documentation before implementing your own transaction builder. For institutional or embedded products, also test how account abstraction, MPC signing, batching, and transaction simulation interact with EigenLayer flows.

EXPLORE

EigenLayer Forum and Governance Signals

Monitor EigenLayer governance discussions, upgrade notices, and parameter-change debates before committing to either native restaking or LRT-based exposure. Native integrations may be affected by changes to delegation, withdrawals, rewards, operator requirements, or AVS participation rules. LRT integrations can be affected indirectly when issuers update strategy, operator allocation, supported AVSs, fee policy, or withdrawal routing in response to EigenLayer changes. Risk teams should maintain a governance watchlist and map each proposal or announcement to affected contracts, products, and user disclosures.

EXPLORE

LRT Issuer Documentation, Audits, and On-Chain Controls

For liquid restaking token integrations, review each issuer separately rather than treating all LRTs as interchangeable. Confirm the token contract, upgrade admin, withdrawal queue design, supported restaked assets, operator-selection policy, reward distribution method, oracle or exchange-rate mechanism, pause controls, and audit history. Lending markets and structured products should model issuer-specific depeg, liquidity, governance, and smart contract risks. If the issuer’s documentation does not clearly explain custody, redemption, and failure handling, require additional review before accepting the LRT as collateral or routing user deposits through it.

Secondary Liquidity and Exposure Monitoring

Use market and DeFi telemetry only as supporting evidence, not as the canonical source for protocol behavior. Dashboards can help compare EigenLayer TVL, LRT liquidity depth, pool concentration, redemption pressure, and secondary-market pricing, which matter for DeFi collateral and treasury integrations. However, telemetry should be reconciled against issuer contracts, official documentation, and your own indexer before it drives automated risk actions. For LRT integrations, monitor both token liquidity and underlying restaking exposure so the product can react to withdrawal congestion or issuer-specific stress.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

NATIVE VS. LIQUID RESTAKING DECISION FAQ

Frequently Asked Questions

Practical answers for builders evaluating custody, risk, and yield trade-offs between native restaking and liquid restaking token integrations.

Native restaking interacts directly with EigenLayer's core contracts, minimizing the smart contract surface area. The trust assumptions are limited to the battle-tested EigenLayer protocol itself.

Liquid Restaking Tokens (LRTs) introduce an additional layer of smart contract risk from the LRT protocol. This includes the token contract, any staking delegation strategies, and potential oracle or reward distribution logic. A vulnerability in the LRT's contracts can lead to a loss of funds independent of EigenLayer's security.

Operational Check:

Audit the LRT's full contract architecture, not just the token wrapper.
Verify upgradeability controls and multisig signers for the LRT protocol.
Assess whether the LRT protocol has a bug bounty program and incident response plan.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Native vs. Liquid Restaking: A Builder's Decision Framework

Introduction

Quick Facts

Technical Mechanism

Affected Actors

DeFi Protocol Developers