Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.
What the receipt token actually represents
Solo staking on Ethereum requires 32 ETH locked with a specific validator, run on hardware the staker controls or trusts. A staking pool exists to remove that minimum and that operational burden: a user deposits any amount, the pool runs the validators on the depositor's behalf, and mints a token back to the depositor's wallet. Ethereum's staking documentation, retrieved 16 September 2026, is explicit about what that token is: a claim, stating the protocol 'mints a receipt token (LST) to your wallet' while the underlying ETH 'stays staked on the consensus layer'. The token is not the ether; it is the pool's acknowledgement of a claim on ether the pool controls.
Two ways to show a growing claim
The documentation describes two token designs. A rebasing token, of which Lido's stETH is the example given, keeps roughly one token equal to one ETH by increasing the holder's token balance as rewards accrue. Lido's contract documentation explains the mechanism behind this: the protocol tracks each holder's 'shares' of a total pool, and balance is computed as a holder's share of the total pooled ether, recalculated when an oracle reports the validators' consensus-layer balance, typically daily. An exchange-rate token instead keeps the holder's token count fixed while each token becomes redeemable for a growing amount of ETH. Either way, the reward is net of the protocol's fee, and the accounting, not a transfer, is what moves value to the holder.
The same mechanism carries losses and a market gap
What accrues can also shrink. Lido's documentation states that a rebase 'can be positive or negative, depending on the validators' performance', and Ethereum's staking page confirms that slashing losses are 'typically socialized across all token holders according to the protocol's rules'. A token holder bears validator misconduct or downtime proportionally, without having chosen the specific validator responsible. Separately, because the token trades on secondary markets, its price is a market opinion about the claim, not the claim itself; the documentation notes this price 'can fall below the value of the ETH backing it' during stress, even when the underlying accounting is unaffected. A claim and its market price are two different facts, and a stressed market can separate them further than a calm one ever reveals.
Questions to carry forward
- Is the receipt token's balance derived from onchain, oracle-reported accounting, or from a claim the issuer has not yet demonstrated is backed?
- Has the token's secondary-market price diverged from its underlying redemption value, and under what conditions did that happen before?
- How concentrated are the pool's node operators, and what would a fault affecting several of them at once do to the rebase?
A liquid staking token converts an illiquid, minimum-locked position into a tradeable one, at the cost of substituting the user's own validator judgement for the pool's contracts, operators and reporting. That substitution is the product; it is worth naming as such rather than treating the token as interchangeable with ether.
Sources & reading trail
Explains that depositing into a pool mints a receipt token (LST), describes rebasing versus exchange-rate designs, and states that slashing losses are typically socialized.
Source published: Not established · Retrieved: 16 September 2026
Describes stETH's shares-based accounting and the oracle-driven rebase that changes balances, positively or negatively, without transfer events.
Source published: Not established · Retrieved: 16 September 2026
Describes the underlying validator deposit and duties that a staking pool's node operators perform on depositors' behalf.
Source published: Not established · Retrieved: 16 September 2026
Historical sources establish the record; the questions and interpretation are Block Due Diligence’s editorial analysis. This retrospective draft does not imply the site published on the event date.