Liquid Staking and LSTs on Solana

‍Note: Readers should have some background knowledge of the high-level concepts of LSTs.

Introduction

This piece explores the main structure for Liquid Staking Tokens (LSTs) on Solana. LSTs enable users to unlock the liquidity of their staked assets. Typically, when tokens are staked on a Proof of Stake (PoS) blockchain, they are locked up for a certain period, providing network security in exchange for rewards. These staking rewards can include fees, other MEV revenue, and issuance (a transfer from non-stakers to stakers).

While crucial for economic security, this staking mechanism renders the staked assets illiquid, restricting their utility in other financial activities within the ecosystem. Staking decreases outstanding float by locking tokens inside the protocol. This incentivizes the creation and use of LSTs for capital efficiency, allowing token holders to earn staking rewards while retaining liquidity.

This piece also explores how these constructions differ from Ethereum as well as additional considerations with respect to LST constructions on Solana.

LST Constructions on Solana

Solana utilizes an in-protocol Delegated Proof-of-Stake (DPoS) mechanism. Users enter stake pools run by different individual validators by depositing SOL. The staking operators can then issue their own LST backed by the delegated SOL. This enables users to have instant liquidity on their stake.

Stake Pool LSTs

LSTs involve stake pools that utilize the SPL stake pool program. By contributing SOL to these non-custodial pools, stake is distributed across a selection of qualified validators. In exchange, participants receive an LST such as Jito’s JitoSOL.

Each stake pool employs a distinct strategy for delegating stake. For instance, Jito prioritizes validators running its client. This maximizes MEV returns and rebalances across the top 100 performing validators, according to their criteria.

We can represent the transference of stake across the stakeholders in a given stake pool as balance sheets (should be read left to right, top to bottom):

A staker/delegator deposits 10 SOL directly into a stake pool and receives an LST “spSOL” (“stake pool SOL”) balance representing their claim on their deposited 10 SOL for redemption.
The stake pool now has 10 SOL. In this case, it delegates 5 SOL to “Stake Pool Validator 1” and the other 5 SOL to “Stake Pool Validator 2”. The stake pool receives a total of 10 vSOL (“validator SOL”) – 5 vSOL from each validator. While not encoded into an actual token, this represents a virtual claim on their deposited SOL for redemption.
“Stake Pool Validator 1” and “Stake Pool Validator 2” each stake their 5 SOL, performing execution and consensus duties. They receive a virtual “sSOL” from the Solana protocol, representing its claim on deposited SOL (also not encoded into a token, but is used to demonstrate how the protocol tracks redemptions).

Note that this is the simplest case where there are no fees or slashing. In reality, there is no programmatic slashing in Solana today, but some LSTs charge fees.

Validator LSTs

Validator LSTs enable projects to issue LSTs against a single validator more easily, creating a sense of “tribalism” around a given validator-issued LST.

Validator LSTs operate very similarly to a stake pool, except for the fact that there is only a single validator:

A staker/delegator deposits 10 SOL directly into a stake pool and receives an LST “v_lstSOL” (“validator LST SOL”) balance representing their claim on their deposited 10 SOL for redemption.
The stake pool manager then delegates into the only validator in the pool, depositing the 10 SOL into the validator and receiving a virtual “vSOL”.
The validator now has 10 SOL. Since the validator is the entity participating in consensus duties, it deposits 10 SOL into Solana. The validator receives a virtual “sSOL” from the Solana protocol, representing its claim on deposited SOL.

In both cases, stakers are delegating SOL to validators, validators are performing validation duties, and a portion of the SOL rewards are given to stakers. Validator LSTs have zero deposit stake fees, zero withdrawal fees, and zero management fees.

Mechanically, validator LSTs are more lightweight. They significantly reduce the total stake accounts, decreasing the time required to calculate rewards for stake accounts. Additionally, validator LSTs can run incentive or loyalty programs: Laine recently airdropped block rewards and priority fees to laineSOL holders, resulting in a large APY to laineSOL holders. Tensor can enable users to place bids using tensorSOL instead of SOL, generating yield on open orders. This allows Tensor to potentially award extra points to its users and conduct a no-loss lottery system where every tensorSOL payment offers a chance to win a portion of the accumulated staking rewards.

LST Token Mechanics

Similar to Ethereum, the mechanics of the LST token can either be reward-bearing or rebasing, with different LSTs choosing different designs for how to relay rewards onto the staker for reasons including potential tax efficiency. Solana currently has no rebasing LSTs.

LST Usage on Solana

On Ethereum, the vast majority of staked ETH comes from LSTs, including stETH, rETH, and cbETH. stETH represents ~70% of the total LST market.

On Solana, LSTs represent less than 5% of the total staked amount. Jito and Marinade represent 35% and 42% of the LST market, respectively.

This disparity in LST usage can be attributed to a number of reasons:

LST usage on Ethereum is largely path-dependent, with the Merge having a large effect on the current LST usage equilibrium. Large, compounding network effects and adoption revolved around the 1-3 liquid staking tokens that took off, creating a self-reinforcing “moneyness” flywheel.
LSTs do not yet have enough on-chain utility, with users being highly sensitive to impairments to collateral weights in Solana DeFi (unlikely).
The incentives are higher to run your own validator (stake-weighted services) for large holders (institutions and individuals) and choose to stake without external stake for potential legal liability. Large SOL accounts/conglomerates that have high stake (likely previously locked) prefer not to participate in LST staking, so they just run their own validator and receive respective staking rewards (for legal, regulatory, or other reasons).
Solana users are not very familiar with the structure of LSTs.

LSTs and DeFi

On PoS networks, high lending rates in DeFi often directly compete with staking, which can compromise network security as stakers rationally withdraw their stake to pursue higher returns from DeFi lending platforms. This has been apparent on chains such as Cosmos which has historically been caught in a challenging cycle with limited DeFi activity due to the high staking yields across the ecosystem (but may be changing soon). This sets a high, often unsustainable benchmark for Cosmos DeFi to gain traction as it competes with these staking returns. A liquid and vibrant LST market can help mitigate this issue by allowing stakers to participate in both staking and lending simultaneously, reducing the incentives for attacks.

Solana DeFi has experienced a significant uptick in volume, activity, and attention following the Jito and Jupiter airdrop. These airdrops are often the genesis of more interesting shared state as activity, interest, and the number of assets grow. Unlocking all staked SOL on a shared state system such as Solana enables a richer native DeFi economy.

While the LST ecosystem on Solana is still in its infancy, it will likely have a much longer tail of LSTs (unlike Ethereum), largely in part due to the increasing popularity of validator LSTs.

Sanctum and the Long-Tail of Solana LSTs

Validator LSTs are fungible (more on this later). They are wrappers around the same stake accounts and represent a claim against the corresponding amount of staked SOL.

Validator LSTs enable validators to each distribute their own validator-specific LSTs. One of the earliest teams building for this “infinite-LST” future is Sanctum. The Sanctum Reserve provides a large pool of liquid SOL (> 200,000 SOL) that enables instant unstaking for any LST by transferring the user’s stake account to Sanctum for the corresponding amount of SOL, minus some fee (for the two-day unbonding window). The Sanctum team has also built the Sanctum Router, enabling it to swap LSTs via Jupiter’s off-chain router, and the soon-to-release Sanctum Infinity. As a result, any arbitrary LST can be instantly unstaked, exchanged with one another, and swapped for any other token with minimal fees.

LST Constructions on Ethereum

Not all protocols have a native delegation mechanism found on Solana. The following are the most popular constructions of LSTs on Ethereum:

Permissioned Node Operators (e.g. stETH)

stETH is issued by the Lido DAO, which manages the distribution and operations of staked assets among a select set of ~30 permissioned node operators. This design is characterized by its permissioned and uncollateralized nature, meaning node operators are carefully chosen based on strict criteria but are not required to post collateral (creating a principal-agent problem). The stake delegated to the LIDO pool is distributed evenly among these operators. This approach emphasizes trust in the vetted operators to maintain network security without the need for additional financial guarantees. Lido currently represents ~31% of all staked Ethereum.

Permissionless Node Operators (e.g. rETH)

RocketPool offers a permissionless node operator set, allowing anyone to become a validator as long as they meet the collateral requirements. This model democratizes access to node operation, given that one must lock up collateral to participate. Specifically, to form a full 32 ETH validator node, an operator needs to supply 8 ETH of their own funds and an additional 2.4 ETH worth of RocketPool’s native RPL token, totaling 10.4 ETH, which then qualifies them to receive 24 ETH from the pool.

This design aims to mitigate principal-agent effects, where the parties putting up risk capital and the operators are distinct entities.

Centralized Node Operators (e.g. cbETH)

Through Coinbase or other centralized entities, users can stake their ETH directly with the platform, which takes on the responsibility of running the necessary nodes. Additionally, users can access liquidity for cbETH on-chain. This model prioritizes ease of use and accessibility as users entrust Coinbase with the operational complexities of staking.

Additional Thoughts

Stake pool programs are controlled by a multisig. The staker authority – which could be a single keypair – has control over some aspects of stake delegation, and can only carry out a much more limited set of actions. Projects such as Stakenet aim to decentralize the staker authority by delegating it to a program instead of a single keypair. The staker authority can redelegate stake to different existing validators as well as raise fees (which takes at least 1 epoch to take effect). Furthermore, there are limits to what the manager can increase fees by.

As of now, Solana does not have programmatic slashing (unlike other chains such as Ethereum). This means that there are fewer exploitation vectors for the delegatee (operator) to perform malicious operations with their delegated stake. While the operators of respective validator LSTs are heavily constrained and do not have the latitude to steal delegated stake – as users maintain ownership of their staked SOL – additional considerations need to be taken if and when Solana supports programmatic slashing. Ethereum is currently exploring solutions such as two-tier staking to mitigate some of the effects of this principal agent problem with respect to slashing.

Conclusion

In this piece, we explored how the current implementation of Solana LSTs operates in practice. Additionally, this piece highlighted the contrast between Solana’s native delegation and the respective LST model with Ethereum’s.

LST usage on Solana and Ethereum reveals a significant disparity, with Solana’s LST market being relatively nascent. As the utility of LSTs expands and users becoming more familiar with their structure, more native DeFi state will arise on Solana

Thanks to FP Lee (Sanctum) and Jon Charbonneau for feedback and review.