LRT Tokenomics: Designing the Stacked-Yield, Stacked-Risk Token

An LRT stacks yield, which means it stacks risk

The pitch for a liquid restaking token is clean. You stake ETH or a liquid staking token, then restake the same capital to secure additional protocols, and you stay liquid the whole time. Base staking yield plus restaking rewards on one position. The part that gets less attention in the marketing is that the risk stacks the same way.

Base staking carries slashing. Each service the capital restakes to adds its own slashing conditions. The LRT holder is exposed to all of them simultaneously, on the same underlying ETH. The cleanest way to see the structure is to decompose the revenue into its three sources, base staking yield, AVS or service rewards, and DeFi side-yield, because the same structure that compounds reward also compounds the loss surface and creates feedback loops between them.

This is why we treat an LRT as a stacked-risk instrument before we treat it as a yield product. The reward loop is the visible half of the design. The slashing surface underneath it is the half that decides whether the token survives a bad week. A reward loop that does not price the combined slashing exposure is the single most common flaw we see in LRT designs, and it is invisible until the first correlated event. Our LST/LRT tokenomics practice starts from that exposure, not from the APY.

Revenue-first design applies here as much as anywhere. The yield is not the product. The economic security the restaked capital provides to real services is the product. If the underlying services are not creating value worth securing, the yield is just a number that depends on risk the holder has not measured. That same logic drives our broader token allocation thinking, where supply only matters relative to the demand it is meant to serve.

The central flaw

The reward stacks. So does the risk. A design that prices the headline yield but not the combined slashing surface is engineered for the good days.

The protocol layer constrains everything above it

The restaking layer an LRT plugs into sets the rules the token inherits. It defines which services can be secured, how slashing works, how operators are delegated to, and how stake is allocated. The major base layers each make different choices on these questions, and those choices flow up into the LRT's risk profile and its classification.

On EigenLayer, restakers delegate to operators, operators opt in to actively validated services, and each service defines its own slashing conditions. Native restaking and liquid staking token restaking both feed the same security pool, and the EIGEN token carries an intersubjective slashing role for faults that cannot be proven purely onchain. Slashing went live in April 2025, which means the slashing surface is no longer theoretical for designs built on it.

We design from the protocol layer up because you cannot define a safe reward loop without first mapping the slashing surface it has to cover. An LRT that restakes broadly across many services on a permissionless base layer inherits a wider, harder-to-bound loss surface than one that restakes to a curated set. Neither is better in the abstract. One trades flexibility for a tighter risk boundary; the other trades a tighter boundary for reach.

This is also where the entity and oracle questions start. The LRT protocol wraps the base layer's contracts, the DelegationManager and strategy contracts on EigenLayer, and the exchange-rate oracle that prices the LRT against its backing sits on top of that. An oracle that updates slowly or trusts a single source becomes a depeg vector the moment restaked positions move faster than the price feed.

Operator selection is the other variable the protocol layer hands to the LRT. Restakers do not secure services directly; they delegate to operators who run the infrastructure and opt in to specific services on their behalf. A concentrated operator set, or operators that opt in to risky services for higher rewards, raises the slashing exposure the LRT holder carries without the holder ever seeing the decision. We treat the operator delegation policy as a tokenomics parameter, not an ops detail, because it sets the floor on the token's risk.

The base layers are not interchangeable

The major restaking layers differ in collateral scope, slashing design, and how opinionated they are about what gets secured. The differences are not cosmetic. The LRT inherits the base layer's risk model wholesale, so the choice of base layer is one of the first design decisions, not a deployment detail decided later.

EigenLayer is the largest by a wide margin, with on-chain data placing it around a peak of roughly 20 billion dollars in restaked value in 2025 and a dominant share of the category. Its scope is ETH-centric and its services are curated relative to the alternatives. Symbiotic takes the opposite stance: permissionless, multi-asset collateral, with slashing and parameters set by each network. Karak supports a broad multi-asset collateral set, including LSTs and stablecoins, and positions itself as extensible.

Our risk analysis of the category frames the tradeoff cleanly. A permissionless, multi-asset base layer maximizes flexibility and reach but widens the collateral and slashing surface the LRT has to underwrite. A curated base layer bounds the risk more tightly at the cost of what an operator can secure. For an LRT, the question is not which layer wins; it is which slashing surface the token can actually price and defend. We work that judgment through in a tokenomics consulting engagement before any mechanism is committed.

Token utility has to be more than the yield

The most common weakness in an LRT is a token whose only reason to exist is the yield it carries. If the LRT is not used as collateral in DeFi, not accepted across protocols, and not doing a job beyond accruing rewards, then its demand is entirely a function of the yield, and the yield is entirely a function of risk the holder may not have priced. Strip the yield and there is no reason to hold it.

This maps directly onto our two-axis token taxonomy. On the legal axis, an LRT typically sits closest to an asset or commodity framing, one-to-one against staked backing, redeemable, no managed return, but a poorly designed reward distribution can drag it toward a security analysis. On the economic axis, the token-necessity test asks whether the token does a real job. "It accrues a yield" is not a job; it is a wrapper around someone else's job.

We apply a concrete utility test: name who uses the LRT, for what, paying what, on which day. If the only answer is "they hold it for the APY," the utility is not real yet. Genuine LRT utility looks like deep acceptance as DeFi collateral with conservative loan-to-value parameters, integration as a base trading pair, or a designed role inside a protocol that creates demand independent of the reward stream.

The distinction matters because demand that rests only on yield is the most fragile kind. The moment restaking rewards compress, or a slashing event repriced the risk, yield-only demand evaporates and the redemption queue does the rest. Designed utility is what keeps a holder in the token when the headline APY is no longer the reason to be there.

There is a governance trap worth naming here too. Several LRT protocols pair the LRT with a separate native token that carries governance over AVS whitelisting and protocol parameters. That can be sound design, but only when the governance token does a real job and stays independent of the LRT's peg. A governance-only token with no usage demand underneath it is the most common failure pattern in our practice, and it does not become safer because it sits next to a restaking product. The two-token separation rule applies: the native token's demand must never contaminate the LRT's backing.

The utility test

An LRT whose only job is holding a yield fails the token-necessity test. Real utility means the token does a job a stablecoin cannot do.

The paired LST: where restaking starts, and where depeg lives

A liquid staking token sits one layer beneath the LRT. An LST, stETH, rETH, cbETH, represents staked ETH kept liquid, earning base staking yield without restaking. An LRT takes an LST or staked position and restakes it, adding restaking rewards and restaking slashing on top. The LRT inherits the LST's base yield and base slashing before it adds anything of its own, which is why we design the two as one cluster.

Look at the shared components, minting, redemption, oracle design, and slashing exposure, and the practical lesson is plain: the LRT cannot be safe if the LST underneath it is not. Yield stacking is the mechanism: the LST's base yield is the first floor, restaking rewards are the second, and DeFi side-yield is the third. Each floor adds reward and adds a paired risk.

Depeg is the failure mode both tokens share. An LST trades below par when the redemption queue is long or validator exit takes time, so holders who need liquidity sell into the market below the underlying. An LRT adds restaking illiquidity on top, because the restaked position may not unwind quickly. Renzo's ezETH saw this in April 2024, when an airdrop-driven liquidity shock pushed the token sharply off its peg before it recovered, a reminder that the peg is a market outcome the mechanism defends, not a constant.

The design answer is the same arbitrage discipline used for any asset-backed token. A redemption path and an arbitrage band let arbitrageurs create when the token trades above backing-plus-fee and redeem when it trades below backing-minus-fee. We do not predict the peg. We design the mechanism that defends it, and we model what happens when redemption is slow and restaking is illiquid at the same time.

Correlated slashing is the stress scenario that matters most

The risk in an LRT is not one service slashing. It is several at once, on the same capital. When the same underlying ETH secures multiple protocols, a single bad event, an oracle failure, a coordinated exploit, a market dislocation that hits several services together, can trigger slashing across more than one of them. The interconnected-risk picture is exactly this: correlated slashing and the contagion it creates between positions that looked independent.

The losses do not add politely. They compound, and they compound at the worst moment, when liquidity is thinnest and holders most want out. Stacked leverage carries three systemic tail risks that travel together: cascading liquidation when the LRT is used as leveraged collateral, slashing amplification across stacked positions, and LRT liquidity evaporation as everyone reaches for the exit simultaneously. Each one makes the others worse.

This is why we stress-test the correlated-slashing case specifically rather than modeling each protocol's risk in isolation. An LRT can look perfectly sound when its restaked services are evaluated one at a time and still be fragile to the one scenario where they fail together. Our economic simulation discipline runs this as a combined worst-case path, not an afterthought, because the median outcome is never what breaks a token. The tail does.

Mature LRT teams have started treating this seriously. The right risk work centers on yield-composition uncertainty and the specific channels through which restaking risk reaches the token, not on the headline APY. That is the right instinct. The reward loop and the redemption mechanics both have to survive the correlated case, or the token is engineered for the good days only.

• Cascading liquidation: an LRT used as leveraged collateral forces liquidations that feed back into the price
• Slashing amplification: one slashing event triggers losses across multiple stacked restaked positions
• Liquidity evaporation: redemption queues and thin LRT markets collide exactly when holders want out
• Oracle lag: a slow exchange-rate feed lets the market price diverge from backing during the event

How we design an LRT, and what the Data Room produces

We have designed tokenomics for 80-plus projects through 100 million dollars-plus in combined raises, including first-party work on protocols such as NOSANA, Roark, and EcoYield. The pattern that separates LRT designs that survive from the ones that do not is whether the reward loop was designed against the slashing surface or bolted on after the APY was decided.

The mechanism design document is the technical backbone. For an LRT, it specifies the protocol-layer integration and the inherited slashing surface, the supply invariant that circulating LRT supply must never exceed verified backing, the proof-of-reserves and oracle design that enforce it, the fee and reward-distribution model, and an adversarial risk pass that documents likelihood, impact, mitigation, and residual risk for each threat. The correlated-slashing scenario is named explicitly, not buried.

The economic simulation is where the reward loop is pressure-tested. Roughly a thousand independent multi-year paths, each with its own randomized price trajectory, growth path, and user composition, run against stress scenarios including a combined worst case. Simulation has in real engagements revealed reward and fee rates that were structurally underwater and forced a redesign before any capital was at risk. For an LRT, the equivalent finding is a reward loop that cannot cover the stacked slashing exposure under a correlated event.

The classification work runs in parallel. We design the LRT structure toward the lightest defensible position, no revenue distribution to holders, genuine utility, a redemption mechanism, a market-set price, and document the reasoning so the legal team can run the security analysis with the architecture already pointing the right way. The tokenomics whitepaper then synthesizes all of it into one investor-ready document where every claim is backed by an upstream analysis, all assembled inside a single Data Room.

None of this guarantees an outcome. Slashing live on the base layer since April 2025 means the risk is real money now, not a parameter on a slide, and a correlated event can still hurt holders of a well-designed token. What good LRT tokenomics buys you is a reward loop that was priced against the actual slashing surface, a redemption mechanism that was modeled under stress, and a classification posture you can defend. The token is infrastructure. The economic security it provides to real services is the engine. Design the two against each other, or the yield is just a countdown timer.