Liquid Staking and LSTs, Explained: How Receipt Tokens Unlock Pledged Assets

Liquid staking tokens solve the fundamental illiquidity of proof-of-stake networks by issuing a tradable receipt for locked assets. When users deposit cryptocurrency into a liquid staking protocol, the protocol stakes the assets on their behalf and issues a derivative token representing the initial deposit plus accrued rewards. This mechanism allows participants to deploy their capital in decentralized finance applications while simultaneously securing the underlying blockchain.

The Illiquidity Problem

Native proof-of-stake systems require users to lock their capital to participate in network validation. In Ethereum Staking, running an independent validator requires technical infrastructure and a minimum deposit of 32 $ETH. While deposited, these assets cannot be sold, transferred, or used as collateral.

This architecture forces a capital allocation choice: users must decide between securing the network for a baseline yield or retaining liquidity to trade and interact with decentralized applications. Liquid staking emerged as a structural solution to this constraint, abstracting the technical requirements of node operation and removing the minimum deposit threshold.

How Liquid Staking Works

Liquid staking protocols act as intermediaries between users and network validators. Users deposit their assets into a smart contract managed by the protocol. The protocol aggregates these deposits and delegates them to a set of professional node operators who run the validator infrastructure.

In return for the deposit, the protocol mints a Liquid Staking Token (LST) and sends it to the user. This token represents a pro-rata claim on the underlying staked assets and the rewards generated by the validators. Because the LST exists as a standard token on the blockchain, users can trade it on decentralized exchanges, use it as collateral in lending protocols, or deploy it in other financial contracts, effectively unlocking the liquidity of their staked position.

Rebasing vs. Value-Accruing Tokens

Liquid staking protocols distribute rewards using two primary accounting models: rebasing and value-accruing.

A rebasing token automatically adjusts the user's token balance daily to reflect accrued staking rewards. If a user holds 100 stETH and the protocol generates a 5% annualized return, the user's wallet balance will gradually increase to 105 stETH over the course of a year, assuming the yield remains constant. The token is designed to trade at a 1:1 ratio with the underlying asset, though market dynamics can cause deviations.

A value-accruing token (or reward-bearing token) maintains a static balance while the token's internal exchange rate relative to the underlying asset increases over time. If a user deposits 100 ETH for 100 value-accruing LSTs at an exchange rate of 1.0, and the protocol generates a 5% return, the user's token balance remains 100. However, the redemption value of each LST increases to 1.05 ETH.

Different models have different implications for tax reporting and compatibility with decentralized finance protocols. Authorities such as the IRS and HMRC treat these mechanisms differently, and specific tax obligations vary by jurisdiction.

The Role of Node Operators

The security and performance of a liquid staking protocol depend entirely on its node operators. Protocols use varied methodologies to select and manage these operators. Some rely on a permissioned set of institutional validators, occasionally resulting in specialized infrastructure setups like the KR1 Partners with P2P.org initiative to manage dedicated validator vaults. Other protocols aim for permissionless operator sets, requiring operators to post collateral to align incentives and protect against slashing penalties.

When validators fail to maintain uptime or act maliciously, the network penalizes them by confiscating a portion of their staked assets—a process called slashing. Liquid staking protocols distribute these losses across all LST holders, meaning the risk is shared collectively.

Restaking: The Next Layer

Restaking protocols extend the utility of LSTs by allowing users to pledge their already-staked assets to secure additional decentralized networks and services, such as data availability layers or oracle networks. Users deposit their LSTs into a restaking smart contract, generating a Liquid Restaking Token (LRT).

This introduces compounded risk. The assets are now subject to the slashing conditions of both the base layer blockchain and the additional networks secured by the restaking protocol. While this architecture maximizes capital efficiency, it creates complex dependencies where vulnerabilities in secondary networks could impact the underlying assets.

Common Misconceptions

• LSTs are pegged 1:1: Liquid staking protocols do not enforce a hard peg in the secondary market. The price of an LST is determined by liquidity, market demand, and the redemption queue. During periods of market stress, LSTs can trade at a significant discount to their underlying assets.
• Yield is risk-free: Staking rewards are compensation for securing the network, not guaranteed interest. Protocols are subject to smart contract vulnerabilities, validator slashing, and governance risks.
• Redemptions are instant: Converting an LST back to the native asset through the protocol requires waiting in the network's withdrawal queue. This exit period can take days or weeks depending on network congestion.

What to Watch

The liquid staking sector faces ongoing structural and regulatory developments. Market dominance by a single protocol remains a central concern for base-layer network decentralization. If one protocol controls a supermajority of staked assets, it theoretically gains outsized influence over transaction ordering and network consensus. Regulators globally, including the SEC and ESMA, continue to evaluate whether staking-as-a-service models and liquid staking derivatives constitute unregistered securities offerings, focusing heavily on how node operators are selected and how rewards are distributed.