STAKING — Solana × Warm-up and Cool-down

How Long to Unstake Solana: The 9% Cooldown Queue Explained

6 min read
SolanaStakingUnstaking

You click “unstake”, the wallet says the stake is deactivating, and you wait for the epoch to roll over. It does. Your SOL is still not withdrawable, or only part of it is. Nothing is broken, and nobody told you about the queue.

Solana limits how much stake can enter or leave the active set per epoch. The limit is a percentage of all stake on the network, not of yours, which means the time it takes for your SOL to become withdrawable depends on how many other people are leaving at the same time. Here is the rule, from the stake program’s constants and the runtime’s arithmetic, and how to read your own stake account to know where you are in the line.


Stake does not switch off, it drains

A delegated stake account has three portions at any moment: effective (earning and voting), activating (on its way in), and deactivating (on its way out). When you deactivate, the whole amount moves to the deactivating column at the next epoch boundary, and from there it drains into “inactive” over one or more epochs. Only inactive lamports can be withdrawn.

The drain is governed by one number: the warm-up/cool-down rate. It was 25% per epoch at launch and has been 9% since the reduce_stake_warmup_cooldown feature activated. Both constants are still in the stake interface, in basis points — 2,500 and 900 — and the lower one is what the network uses today.


The formula, and why it is about everyone else

For each epoch, the runtime computes how much of your deactivating stake becomes inactive:

your change = your deactivating portion × cluster effective stake × 900 ÷ (cluster deactivating portion × 10,000)

Read the fraction. The network allows at most 9% of its total effective stake to leave per epoch. If the total deactivating that epoch is below that allowance, everyone drains fully in one epoch and you never notice a queue. If it is above — a large unstake wave, a validator exodus, an exchange moving its book — the allowance is shared out pro rata, and your drain slows by exactly the ratio of the allowance to the demand.

An example. Suppose 400 million SOL is effective and 60 million is deactivating in the same epoch. The allowance is 36 million (9% of 400). Your account drains 36 ÷ 60 = 60% this epoch, then 60% of the remainder the next, and so on. A 100 SOL unstake becomes 60 withdrawable after one boundary, 84 after two, 93.6 after three.

Since 31 August 2026 that arithmetic runs in fixed-point integers (stake program v5.1.0) rather than floating point, so the result is exact and identical on every validator. It is also saturating: there is no path by which a crowded queue drains faster than the allowance.

Worth knowing: there is a floor. Each epoch, at least one lamport of a deactivating stake becomes inactive, so a drain always terminates and a dust-sized stake exits in a single epoch no matter how crowded the network is.


Warm-up is the same queue in reverse

Activating stake is subject to the same 9% allowance. Delegate during a rush and your stake earns on only the portion that has become effective each epoch — the rest is waiting with everyone else’s. The symptom is a first reward that is smaller than you expected, which is a different post.

The two queues are independent: a heavy inflow does not slow outflows, and vice versa.


Epochs are getting shorter, so the queue is getting faster in hours

An epoch is 432,000 slots, and slots have been shrinking all year. At the 250 ms slot time in force when this was written, an epoch is about 30 hours; the final 200 ms step will bring it to 24 hours. A three-epoch drain that took six days at launch takes under four now, and three once that step lands.

The percentage per epoch has not changed. Only the length of the epoch has.


Reading your own position

Your stake account carries the numbers you need: the delegation’s activation epoch, its deactivation epoch, and the stake amount. Combined with the network’s stake history sysvar — which records effective, activating and deactivating totals per epoch — the runtime’s own function returns your effective, activating and deactivating lamports for the current epoch. The reference CLI prints exactly this breakdown for any stake account, and any explorer that shows “activating” and “deactivating” rows is calling the same function.

What you can withdraw right now is the inactive portion minus the rent-exempt reserve. If a wallet shows a withdrawable balance that does not match that, it is rounding.


Unstaking: Questions People Actually Ask

How long does it take to unstake Solana?

At least one epoch boundary — about 30 hours at 250 ms slots, 24 hours at 200 ms — and longer if more than 9% of the network’s total stake is deactivating in the same epoch, because the allowance is shared pro rata.

Why is only part of my stake withdrawable after an epoch?

Because the exit queue was over the 9% allowance that epoch. Your deactivating stake drained by the allowance-to-demand ratio, and the rest drains in the following epochs.

Can I speed up unstaking?

No. The rate is a network constant applied identically to every account. The only control you have is timing: deactivate when the queue is quiet, which the stake history sysvar shows.

Does the same queue apply when I stake?

Yes. Activation is limited by the same 9% allowance, independently of deactivation, so stake delegated during a rush becomes effective over more than one epoch.


The three things to know before you unstake

It is not instant: the earliest your SOL can be fully withdrawable is the first epoch boundary after you deactivate, and only if the network’s exit queue is quiet.

It is proportional: if more than 9% of all stake is leaving, your drain slows by the same ratio as everyone else’s, over as many epochs as it takes.

It is predictable: the stake history sysvar is public, so the queue’s depth for the current epoch is readable before you deactivate, and the stake program’s math is now exact integer arithmetic that any tool can reproduce.

— One Epoch Is the Unit —

Every drain is counted in epochs, and epochs keep getting shorter.

The upgrades tracker shows which slot-time step is in force on each cluster, which is what turns “three epochs” into hours.

Open the Upgrades Tracker ↗

The 1 SOL floor on new delegations is a separate rule — the minimum delegation — and the epoch length that sets this clock comes from the slot-time ladder. What the stake earned on its way out arrives on its own schedule: when staking rewards are paid, and why one can be zero.

Constants read from the Agave validator source at commit beee69b958: the stake interface’s warmup_cooldown_allowance.rs, runtime/src/stake_history.rs and feature-set/src/lib.rs. The live slot time was read from mainnet on 7 October 2026.

xroot.devOn-chain research, published in full
𝕏 @xrootdev
← Back to all notes