LST and LRT Tokenomics: Token Design for Liquid Staking and Restaking Protocols
Liquid staking and restaking protocols turn a staked position into a liquid token that earns while it moves. The tokenomics determines how yield is distributed, how slashing risk is absorbed, and whether the governance token captures real demand. The difference between LST and LRT is not just a letter. It is the difference between one security obligation and several at once.
What Is LST Tokenomics?
LST tokenomics is the design of token models for liquid staking protocols: how staking yield is distributed between depositors, node operators, and the treasury, how the token supply model affects DeFi composability, how slashing risk is absorbed without breaking the peg, and how any governance token captures real demand.
A liquid staking token represents a staked position in a proof-of-stake network, so the underlying asset keeps earning consensus rewards while the token itself can move through lending protocols, AMMs, and derivatives markets. The first design decision shapes everything downstream, and it is the rebasing-versus-exchange-rate fork. After that come the protocol fee architecture, the slashing reserve, and the governance token.
We design and audit LST token models as the full Tokenomics Data Room applied to a staking protocol. The revenue-first lens applies cleanly: the protocol fee architecture is the tokenomics, because the yield split determines what the treasury can fund and what the slashing reserve can absorb.
What Is LRT Tokenomics?
LRT tokenomics is the design of token models for liquid restaking protocols, covering how restaking yield is composed across multiple streams, how slashing risk is structured across several independent validation duties at once, and how the protocol's fee layers stack over the underlying staking yield.
A liquid restaking token takes a staked position, ETH or an LST, and pledges it to secure additional networks called actively validated services, then wraps that position into a liquid token. That single move stacks new yield on top of base staking, and it stacks new risk on top too.
The design question is not just how to distribute yield; it is how to distribute risk. An LST manages one security obligation. An LRT manages several at once, each with its own slashing conditions, so every dimension of the tokenomics scales with the number of services secured. We design and audit LRT models inside the same Data Room, with the multi-vector slashing problem treated as the defining risk.
The Foundational Choice: Rebasing versus Exchange-Rate
The fork matters because of composability. A token whose balance changes every day without a transaction breaks the math that lending protocols and AMMs depend on. That is why most DeFi-native designs use the exchange-rate model or ship an exchange-rate wrapper from day one.
| Property | Rebasing Token | Exchange-Rate Token |
|---|---|---|
| Holder balance | Grows automatically as rewards accrue | Stays fixed; token price appreciates |
| DeFi composability | Breaks collateral and AMM math; usually needs a wrapper | Composable with lending, AMMs, derivatives |
| User-visible yield | Visible as a rising balance | Visible as a rising redemption rate |
| Typical use today | Often wrapped before DeFi integration | Default for DeFi-native deployments |
Where the Yield Actually Comes From
For a liquid staking token, yield comes from consensus-layer rewards, value captured from transaction ordering, and execution-layer priority fees. For a liquid restaking token, the yield is a composite that stacks on top of that base.
Layer one is the same base staking reward. Layer two is the operator fee paid by each actively validated service the position secures. The restaking yield is the sum, after the protocol takes its own cut, and it depends entirely on how many services are live and what they pay.
That dependency is the trap. Restaking yield is partially prospective: early protocols face a bootstrapping problem where service fees are negligible until services launch and start paying. The blunt design principle is to never build tokenomics that depend on restaking yield materializing before the services are live.
THE STAKING RECEIPT
The Fee Stack, and Why Net Yield Is the Honest Number
A liquid staking token has a single fee layer. A liquid restaking token can have two or three. Each layer takes a cut before the holder sees anything, so a holder receives a smaller fraction of the total generated yield than a headline gross rate suggests.
This is where trust gets won or lost. A protocol that shows depositors the gross stack without disclosing what lands after all three layers is setting up a trust collapse the moment a depositor does the arithmetic themselves. The design principle is to publish effective net yield, not gross.
We also flag the fee-compression dynamic these markets inherit, where protocols cut their take to compete on advertised yield. That is why we design a treasury floor before any competition on yield begins.
Slashing Risk, Depeg Risk, and What We Design Against
Every LST and LRT design has a set of specific failure vectors. We model against each one explicitly, then stress-test through the adversarial pass.
Slashing reserve undersized
A reserve sized to a single slashing event is inadequate for restaking, where the same capital secures multiple services. Multi-vector exposure demands multi-vector sizing.
Correlated slashing
A shared validator client bug can trigger simultaneous penalties across every service a set of operators validates. Independence assumptions built for a single service undercount the real tail risk.
Prospective yield marketed as live
Restaking yield depends on AVS adoption. Marketing AVS fees that are not yet live as current yield is a trust-collapse waiting to happen.
Fee opacity eroding trust
A holder who discovers the effective net yield is far below the advertised gross rate did not get what they signed up for. The fee stack requires publication, not assumption.
Depeg from large or correlated slashing
A slashing loss too large for the reserve to absorb, or a redemption wave triggered by loss of confidence, breaks the peg. A peg break triggers redemption pressure that can cascade into insolvency.
Governance token without structural demand
A governance token that only votes on treasury allocation competes with the staking token on yield and has no demand beyond speculation. It needs a structural chokepoint to earn durable value.
What We Design for LST and LRT Protocols
A fee-stack design that publishes effective net yield, with a treasury floor set before any yield competition
A slashing reserve sized to real exposure: single-vector for staking and multi-vector for restaking, with the operator-bond or treasury-backstop model chosen deliberately
Depeg defenses: a verifiable backing relationship and liquidity deep enough to survive a redemption wave
A governance token designed around a structural chokepoint, run through the token-necessity test
Supply and distribution modeling for the protocol's own token
Liquidity and launch planning sized for redemption and peg-maintenance reality
An investor-grade whitepaper documenting the yield, the risk, and the reserves in one place
THE RESTAKING STACK
The LST and LRT Design Process: 6 Steps
- 01
Fix the token model
Rebasing or exchange-rate, decided against the DeFi integrations the protocol actually needs. Output: a token model chosen for composability, not for a rising-balance demo.
- 02
Map the real yield
Separate base staking yield from service fees, and mark which service fees are live versus prospective. Output: an honest yield composition, not a forecast sold as a rate.
- 03
Design the fee stack for net transparency
Specify every layer and commit to publishing effective net yield. Output: a fee architecture with a treasury floor.
- 04
Size the slashing reserve to real exposure
Single-vector for staking, multi-vector and correlation-aware for restaking. Output: a reserve sized to the promise, not to a label.
- 05
Build the depeg defenses
A verifiable backing relationship and launch liquidity deep enough to absorb redemption pressure. Output: a peg held by structure, not by hope.
- 06
Run the adversarial pass, then audit
Model correlated slashing, fee opacity, and a depeg cascade; document likelihood, impact, and residual risk; then hand it to a tokenomics audit. Output: an adversarial risk section and an audit-ready model.
Building a staking or restaking protocol? Book a discovery call and we will pressure-test your yield, fees, and slashing reserves.
Book a discovery callThe Governance Token: It Has to Control Something Real
The governance token of a staking or restaking protocol earns durable value only when it controls a structural chokepoint, not when it merely votes on where treasury funds go.
For a liquid staking protocol, the structural levers are validator onboarding criteria, fee parameter bounds, and upgrade authorization. For a liquid restaking protocol, the most important lever is the service whitelist: a governance token that decides which services operators may validate controls the supply of security to the restaking market, which is a chokepoint with real economic weight.
This is the governance-as-a-feature principle we apply across the whole practice. Governance is a capability a token carries, not a reason for the token to exist. We run the token-necessity test on the governance token the same way we run it on any token: if removing it would not break anything the market needs, it should not exist.
Who This Is For
Teams launching a liquid staking protocol
Who need the rebasing-versus-exchange-rate decision and the fee architecture right before integrations are built.
Teams building a liquid restaking protocol
Who need the multi-vector slashing problem and the service-whitelist governance designed with rigor.
Protocols competing on advertised yield
Who need a treasury floor and net-yield transparency that survive a fee-compression race.
Staking and restaking founders preparing for institutional capital
Who need slashing reserves sized right and a governance token that carries structural value before a diligence team looks under the hood.
How LST and LRT Tokenomics Fit the Data Room
LST and LRT tokenomics are not separate products. They are the full Tokenomics Data Room applied to staking and restaking protocols, where the balance between yield, fees, and slashing reserves sits at the center. The mechanism, the supply side, the launch plan, the audit, and the whitepaper are designed by the same team to keep that balance from breaking. These protocols share the asset-backed peg-maintenance discipline we apply to real-world asset tokenomics. See the complete package on our services overview.
Related Services and Verticals
Common questions
References
- Ethereum Foundation, Proof-of-Stake Rewards and Penalties. ethereum.org PoS docs
- EIP-4626: Tokenized Vault Standard, Ethereum Improvement Proposals. eips.ethereum.org/EIPS/eip-4626
- Kannan, S. et al., EigenLayer: The Restaking Collective (2023 white paper).
- EIP-1559: Fee market change for ETH 1.0 chain, Ethereum Improvement Proposals. eips.ethereum.org/EIPS/eip-1559
Written by Tony Drummond, Tokenomics Strategist. 80+ token projects advised. $100MM+ raised across client engagements.
Ready to design yield and slashing reserves that hold up under institutional scrutiny?
Book a discovery call. We’ll assess your project, your goals, and whether we’re the right fit. No pressure, no commitment.
Book a strategy callYield and slashing-reserve design for staking and restaking. 80+ projects advised.