How LSTs protect your SOL

In my recent video below, I explained how native staking works on Solana and why delegating your SOL to a validator doesn’t give them permission to withdraw it:

https://x.com/JamesHanley/status/2090075651286192452

But that raises the obvious question: what about LSTs?

When you hold a liquid staking token, who can actually access the SOL backing it? The validator? The team whose name is on the token? The people running the stake pool? What even is a stake pool?

In this article, I’ll focus on the SPL Stake Pool and Sanctum’s LSTs.

TL;DR: stake pools provide protection for stakers through a similar separation of authorities to that of native staking. The people who manage stake pools (Sanctum for example) and the validators receiving stake do not have the ability to withdraw SOL from inside the pool. This protects staker’s SOL. Instead, the only way to get SOL out is enforced by the stake pool program which controls the process for LST holders to redeem.

A simple analogy for understanding the separation of authorities in stake pools is a rental property.

Imagine you buy a rental property and want to lease it out. So you appoint a property manager. The property manager selects and manages the tenants on your behalf. But that authority does not allow them to take the keys and claim the property as their own. The law prevents this.

The stake pool works similarly. But instead of relying on legal permissions and enforcement like the rental property, the stake pool’s restrictions are enforced by code.

Functionally, the stake pool holds native stake accounts on behalf of depositors (LST holders). The LST represents a share of this pool.

In our analogy, LST holders are the property owners, while the pool’s operators (Sanctum for example) are the property managers who manage the property on behalf of the owners.

This role is called the ‘pool manager’, well there’s another role too but more on this later.

The important distinction to note here is that managers of the pool do not have permission to withdraw SOL (steal the house keys). Instead, they’re only allowed to manage the stake (tenancy) on behalf of the property owners (you, the staker).

The stake pool program design has separate rules for managers and LST holders. The manager handles settings such as fees and selecting the validators to stake to. The manager can monitor validator performance and delegate stake from underperforming validators to better performing validators on behalf of the LST holders (stakers).

In the SPL stake pool design, the pool’s stake accounts use what is called a Program Derived Address (‘PDA’) to hold both staking and withdrawal authorities. Meaning it is the stake pool (program) itself which holds the keys. The stake pool program grants the stake pool manager certain permitted instructions to operate and manage the pool on behalf of stakers.

@brimigs on X from Solana Foundation did a great video explaining PDAs here:

https://x.com/brimigs/status/2092658694542573910

So what does this mean in the context of the stake pool?

As mentioned at the top, in a typical native staking setup, the staker’s wallet controls both the stake authority and the withdraw authority. Meaning they have all the power to decide which validator to stake to and withdraw the underlying staked SOL whenever they choose.

In a stake pool on the other hand, many holders share in the stake pool, so the program itself holds and controls those authorities and enforces the LST holder’s redemptions.

To do this, the program uses a Program Derived Address (‘PDA’). This address is derived from the stake pool program’s ID and has no private key or seed phrase. See @brimigs video above to understand this bit in more detail.

In practice, this means only the associated stake pool program can authorise actions as that PDA using Solana’s program signing mechanism.

It’s important to note that the PDA does not automatically make the pool secure.

In the same way that the legal system protects the property owner from the rental agent taking their house keys, the code enforces the rules when using the PDA’s authority.

In the stake pool context, these come into play when an LST holder is seeking to redeem their LST back to SOL.

1. You authorise a withdrawal using your LSTs.
2. The program checks the relevant pool accounts and calculates the stake you are entitled to after accounting for the withdrawal fee*.
3. The tokens (LST’s) are burned and the withdrawal fee amount (denominated in units of the LST) are transferred to the pool’s fee account.
4. The program uses the pool’s PDA authority to split out the corresponding stake and assign the resulting stake account’s authorities to the address specified in your withdrawal.

*Quick note on withdrawal fees: these exist inside the stake pool to protect the against economic attacks such as strategies that move in and out around epoch boundaries extracting rewards at other holders’ expense. You can read more on this here in the Solana Program Library stake pool docs: SPL Stake Pool fee documentation.

Importantly, the burn and release occur within one atomic transaction. If the transaction fails for whatever reason, all the unstake steps are rolled back.

Then after a successful stake withdrawal as noted above, you now control a native stake account. If its stake is still active, you can deactivate it and withdraw the SOL once deactivation completes.

Once complete, the SOL can be withdrawn to your wallet.

Depending on the interface you’re using to do this, you may need to return and claim it. You can check to see when the next epoch boundary is here: https://explorer.solana.com/

The good news is that at Sanctum we abstract all this complexity away to make it simple for you as a staker - ‘unstaker’ in this case.

But if you really need to know how the LST turns to SOL in your wallet when you unstake, there are a few paths which can be taken:

First, the stake pool may actually have enough unstaked SOL available in its reserve when you want to unstake. If it does, you can redeem directly for SOL without waiting.

At this point you may be wondering why the stake pool would have any SOL at all unstaked in reserve. In short, the reserve gets SOL when new users deposit into the stake pool. This SOL remains unstaked until the pool’s staking operations allocate it to delegated stake accounts.

Importantly, LSTs don’t want to keep SOL idle in the reserve as it reduces the pool’s overall staking yield. So the SOL usually doesn’t sit in this reserve for very long.

Second, is to swap your LST through a liquidity source such as Sanctum’s Infinity. An interface or router such as Jup or Titan will often swap this way based on the available SOL and the cheapest price for you, the swapper.

In this case, it’s actually a swap technically not an unstake: Sanctum Infinity receives your LST and gives you a proportional amount of SOL in return. The swap route itself does not burn your LST to redeem its underlying stake in the process. Well… not right away ;)

Interfaces such as Sanctum’s simplify these steps by hiding them behind our UI. But as you can see, there are clear differences between immediate liquidity (swaps) and redemption of the underlying stake from an LST (delayed unstakes).

Alright, back to the stake pool manager.

As mentioned earlier, for Sanctum LSTs, we act as both the stake pool manager and operator.

This basically just means day to day operations of the pool.

The manager can:

• choose which validator(s) the pool stakes with;
• allocate SOL to those validators and move stake between them;
• adjust the pool’s fees within the program’s rules;
• change where management fees are paid to;
• appoint someone else to take over these responsibilities; and
• require approvals for new deposits or withdrawals of unstaked SOL directly from the pool’s reserve.

Note: importantly, LST holders can always redeem for SOL without the manager’s approval. So the manager can’t ever stop you as a staker from accessing your SOL.

In short, no. The manager could choose to stake with poor performing validators, or gradually increase the fee in the stake pool. Both of these will result in lower yield (APY) but can NEVER eat into your original SOL principle and everything you’d earned up to that point.

This means a good LST has a good manager which ensures you’re getting the best yield possible. But, even if they were hit by a bus tomorrow, you would not lose access to any of your SOL.

As with all on-chain programs, they can be upgraded (changed).

This is true for Sanctum programs too.

The upgrade authority for Sanctum programs is held by an 11-member multisig.

The members of this multisig are highly reputable actors across Solana from Jupiter, Jito, Sanctum and more. Any change to the program would require majority approval.

Yes. Especially Sanctum LSTs.

Delegating the management of your SOL staking using a stake pool does not give the manager access to withdraw it. The rules of the program ensure your principle (SOL) as a staker is protected.

The LST you hold represents a proportional share of ownership of the SOL inside the stake pool and the program enforces the rules for redeeming each LST’s share.

The program uses a ‘PDA’ with no private key to handle the withdraw authority meaning only the program can process redemptions.

Back to our rental property analogy at the top, as a holder of Sanctum LSTs, you are the property owner and we at Sanctum are your humble property manager.