Liquid staking: what the receipt token actually represents
Staking locks an asset; liquid staking replaces the lock with a transferable claim, and the claim is a different instrument with its own failure modes.
Liquid staking is the practice of depositing an asset into a pool that stakes it on a proof-of-stake network and receiving in exchange a token that represents a claim on that stake. The deposited asset is still locked and still exposed to validator penalties; what has changed is that the depositor now holds something transferable. The receipt is not the underlying asset, and most of what goes wrong with liquid staking follows from treating it as though it were.
What the token is a claim on
Behind the token sits a pool of the native asset delegated to a set of node operators who run validators on the depositor's behalf. Rewards accrue to those validators and flow back to the pool, minus a commission taken by the operators and often by the protocol, which is the take rate. Penalties, including slashing for provable misbehavior and smaller charges for being offline, flow back the same way. The receipt holder owns a share of the net.
Two accounting designs are in common use, and they are not interchangeable. A rebasing token keeps the exchange rate at one and increases the holder's balance as rewards arrive; the balance in a wallet changes without any transaction. A value-accruing token keeps the balance fixed and raises the redemption rate instead, so one unit of the receipt is redeemable for a growing quantity R of the native asset. The second design is easier for other contracts to handle, because a balance that changes on its own breaks accounting in any protocol that recorded it once, which is why value-accruing wrappers exist even for rebasing designs. It is also the design in which the yield is invisible in the balance and shows up only in the rate.
Why the market price and the redemption value differ
The redemption rate is arithmetic: total staked assets plus accrued rewards, minus penalties, divided by receipts outstanding. The market price is whatever someone will pay, and the two are only tied together by the ability to exit. Where the network permits withdrawals from the staking contract, exits are subject to a queue with a length that varies with how many validators are leaving at once. That queue is the width of the band within which the market price can sit below redemption value without anyone being able to close the gap.
A discount is therefore not automatically evidence of a problem; it can be a straightforward reflection of an exit delay plus the price of the volatility that a delayed seller has to bear. It becomes something else when it persists in calm conditions, or when it appears alongside a change in what the pool holds. The important structural point is that the discount is a depeg risk that is entirely separate from the health of the underlying network. The chain can be finalizing blocks normally while the receipt trades below the assets behind it.
The risks the receipt inherits, and the ones it adds
- Penalties. Slashing is designed to be rare and to require provable equivocation or a correlated failure across many validators, but a correlated failure is exactly what a large operator set is capable of producing.
- Operator selection. Whoever chooses the node operators is making a credit decision on behalf of every depositor, and the criteria are governance decisions rather than contractual guarantees.
- Contract risk. The deposit, accounting and withdrawal logic is code, so smart contract risk applies to the whole pool at once rather than to individual stakes.
- The rate feed. The exchange rate has to be reported on chain by an oracle that observes the validator balances. Anything that consumes the receipt as collateral is depending on that report.
- Governance. Fee levels, the operator list and the upgrade path usually sit with a token vote, which makes admin key risk and upgradeability risk live questions rather than theoretical ones.
The additions are the point of the exercise. A receipt token can be posted as collateral in a lending protocol, deposited into a pool, or used as margin, which means one asset can now support several positions at once. That is genuinely useful and it is also the mechanism by which a discount on a receipt becomes a wave of liquidations in markets that have nothing to do with staking.
What liquid staking does to the network underneath
Staking is not only a personal position; it is the security budget of a chain. The staking ratio reports the share of supply committed, staked supply the absolute amount, and validator count the number of separate entities operating. None of these captures concentration on its own, which is what the Nakamoto coefficient is for: the number of entities that would have to cooperate to control the consensus process. A large pool that routes stake to many operators still concentrates the decision about who those operators are.
There is a further layer that is frequently overlooked. Validators run software, and if most of them run the same client implementation, a bug in that client is a correlated failure across the network. Node client diversity is a distinct question from validator concentration, and a pool can be well diversified on one measure and poorly diversified on the other. Liquid staking value locked shows how much of the staked base sits behind receipt tokens in the first place.
Reading a rate correctly
The rate on a receipt token is the network's issuance and fee reward, net of operator commission, spread over the pool. It moves inversely with participation, because most designs pay a total reward that is shared among however many validators are active, so a rising staking ratio compresses the per-unit rate by construction. Nominal staking yield and real staking yield differ by the issuance rate, and the second is the one that describes a change in the holder's share of the network.
The staking pages carry participation, rates and concentration measures together, the value locked pages show how much of the receipt supply has been redeployed into other protocols, and the risk section sets out the dependency chains involved. The next article follows the receipt one layer further, into restaking, where the same collateral is asked to secure more than one thing.