"When will I get stake?" How JitoSOL Delegation Actually Works

Validators frequently ask us about this, and we want to provide the clearest answer possible. Here is a full breakdown of the mechanism, including real numbers from the pool, to help you understand exactly what to expect.

The short version: we can tell you precisely where you stand and what factors influence your position. While the system's dynamic mechanics mean we cannot pinpoint an exact date, we can give you complete transparency into how the process works.

⚠️ Read This Before the Numbers

Everything in the "what the pool looks like today" section is a snapshot of one moment, and the projections are a projection of current conditions, not a forecast.

What is solid, because it is read straight from on-chain state: whether you are eligible, what your target share is, your rank, how much SOL is queued ahead of you, and how much rebalancing budget is left in the current cycle.

What is reasonable: what you would receive next epoch, given the reserve exactly as it stands right now.

What is speculative: anything past the next scoring event. The delegation set is re-scored, its size changes, and every target moves with pool TVL.

What is not modelled at all: the rate of deposits into and withdrawals out of JitoSOL, changes in your own or other validators' performance and commissions, and emergency unstakes elsewhere in the pool.

A projection 10 or 20 epochs out can differ substantially from what actually happens. None of this is a guarantee of stake or a commitment from Jito. If you see these figures quoted somewhere without this caveat attached, treat the figures with suspicion.

The Delegation Cycle

StakeNet redelegates on a 10-epoch cycle. Within the epoch that begins a cycle:

• At roughly halfway through the epoch, every validator in the pool is scored and the new delegation set is chosen.
• At roughly 90% through the epoch, emergency-unstake criteria are evaluated.
• After that, rebalancing runs — one instruction per validator — moving stake toward target.

The cycle length and both trigger points are parameters set by the Jito DAO rather than fixed constants, so check the live config if you are relying on them precisely.

For the remaining nine epochs, no new validator joins the set — the next opportunity is the following scoring event. But the set is not frozen. If a validator is emergency-unstaked it loses its place, and every remaining member's share is recalculated upward, so your target can move mid-cycle. This is not rare: during one recent cycle, 160 validators were marked for emergency unstake and the set shrank by one partway through, lifting everyone else's target. You can watch the current cycle at jito.network/stakenet/steward.

This is the first thing that surprises people: if you become eligible tomorrow, you do not enter the set tomorrow. You enter at the next scoring event, and the exact epoch that happens is recorded on-chain — so that part of "when" is genuinely knowable in advance.

Eligibility is Pass/Fail, and it Comes First

Before ranking is applied, validators must satisfy all of the baseline eligibility criteria below. These requirements operate on a pass/fail basis: meeting every condition qualifies you for the delegation cycle, while missing any criterion means no allocation can be granted for that period.

• StakeNet Parameters
• Steward Config | Jito StakeNet
• Inflation commission ≤ 5% in every epoch of the lookback window
• MEV commission ≤ 10% in every epoch of the lookback window
• Historical commission ≤ 50% across all tracked history
• Vote credits above 97% of cluster blocks in every epoch of the window
• Not in the superminority
• Not blacklisted by the Jito DAO
• An acceptable Tip Distribution merkle root upload authority
• Running the BAM client — connected to BAM for at least 6 of the trailing 11 epochs

The thresholds and window lengths above are DAO-set parameters, currently 30 epochs for the commission and vote-credit windows. Read them from the live config rather than treating them as constants.

That last criterion is worth stating plainly, because the JIP-28 tiered rollout has completed and the messaging hasn't fully caught up: running the BAM client is a binary requirement for the stake pool. Connected, you're eligible on this criterion; not connected, your score is zero and you receive no delegation for the cycle. It behaves exactly like every other filter on that list — there is no partial or reduced allocation for a validator that isn't running BAM.

The window is measured in whole epochs, so this is not a same-day switch: you need BAM connectivity recorded for at least 6 of the trailing 11 epochs, and the count only includes epochs that have already closed. Starting the client today begins accruing epochs toward that threshold rather than satisfying it immediately.

There is a useful property in how these filters are built. The commission and vote-credit checks look at a fixed lookback window, so a bad data point has a known expiry date. With the window currently at 30 epochs for commission, commission above the threshold in epoch 995 is still counted at epoch 1025 — the window is 995 to 1025 inclusive — and first drops out at epoch 1026. That is a precise answer to "when do I become eligible again," not a guess.

Both halves of that are computable from your own ValidatorHistory account: which filter you are failing, and the epoch the offending data point rolls out of the window. Nothing about it requires asking anyone.

If You're Eligible, You're Probably In

Per JIP-25 the delegation set holds up to 400 validators. Everyone in it receives an equal share — 1/N of the undirected pool, where N is the set size.

"Undirected" matters here. Under JIP-27, JitoSOL holders can direct the stake backing their holdings to validators of their choosing. That directed portion is tracked separately and is excluded from the algorithmic maths on both sides: it does not inflate anyone's target, and it does not count toward satisfying one. Recently that was roughly 380k SOL of a ~9.9M pool, so the target divides about 9.5M rather than the headline TVL. A validator can therefore hold directed stake and still show a full shortfall against its algorithmic target — the two numbers measure different things.

Rank determines whether you are in the set and what order stake reaches you. It does not determine how much you get. Everyone in the set has the same target.

And right now the 400 cap is not the binding constraint. The pool holds roughly 690 validators and the delegation set a little over 300 — comfortably under the cap. Eligibility is what decides membership today, not rank.

Among eligible validators, ranking is a strict four-tier hierarchy, where a difference in a higher tier always dominates every lower one:

1. Inflation commission — lowest preferred (uses your maximum over the window)
2. MEV commission — lowest preferred (uses your average over the window)
3. Validator age — older preferred, counted in epochs where you earned vote credits
4. Vote credits — a tiebreaker only

"Strict" is worth dwelling on, because it has sharp consequences. Here are three real validators from the set, anonymised, measured at the same moment:

All three are eligible. All three clear every filter. They are separated entirely by the tiers:

• Tier 1 ties. All three run 5% inflation commission — the highest the filter allows.
• Tier 2 decides A. 0% versus 10% MEV commission moves Validator A about a hundred places up the queue, which is the difference between receiving stake in a given epoch and not.
• Tier 3 decides B versus C. With Tiers 1 and 2 identical, validator age breaks the tie — and C, at 65 epochs, lands near the bottom of the set holding nothing at all.

Validator C is not being penalised, blocked, or overlooked. It is eligible, it has a full share assigned, and it is simply behind a very large amount of other validators' unmet demand in a queue that moves at 7.5% of the pool per cycle. Its age it cannot hurry. The two commissions above it, it can.

Why Arrival is a Queue, Not a Schedule

Here is the part that actually answers the question.

Stake increases are funded from one place: the pool's reserve stake account. Each epoch, the Steward walks validators in descending score order and gives each one the smaller of (its shortfall to target) and (whatever is left in the reserve).

So your wait is set by two things: how much SOL is queued ahead of you, and how much supply exists. Supply reaches the reserve from three sources — new JitoSOL deposits, stake unstaked from validators sitting above target, and stake recovered from validators that left the set. Unstaked SOL takes about an epoch to cool down before it can be re-delegated, so an unstake today is not spendable today.

And rotation is deliberately throttled. Only 7.5% of the pool per cycle can be unstaked for rebalancing purposes. That cap exists because every redelegation costs roughly two epochs of yield on the stake being moved, so unbounded churn would quietly tax every JitoSOL holder. When that budget is spent, rotation stops until the cycle resets — no matter how far below target anyone is.

That is the single most common reason an eligible validator sees nothing happening. It is not a queue-jumping problem or an oversight. The budget is simply exhausted, and it is fully visible on-chain.

What the Pool Actually Looks Like

The pool holds roughly 9.9M SOL across about 690 validators, with a delegation set of a little over 300 — comfortably under the 400 cap. Each member's share works out around 30,700 SOL.

We are deliberately not publishing precise totals, because they move faster than a post like this lives. Within a single epoch we watched the reserve fall from tens of thousands of SOL to almost nothing as that epoch's rebalancing spent it, and a 0.4% rise in the per-validator target flip about 150 validators from "above target" to "below target". Any exact figure here would be wrong within hours. What is stable is the shape, and the shape is the interesting part.

Of the roughly 311 set members:

• 198 were within 1% of target. Two thirds of the set is, for practical purposes, exactly where it should be.
• 45 more were within 25%.
• 46 carried nearly all of the imbalance.

Those proportions were identical when we measured them again later in the same epoch, even though the underlying totals had shifted. That tail splits in two: a group holding almost nothing, each owed close to a full share, and a smaller group sitting well above target whose excess is what funds the others.

Two validators in that tail are a special case worth knowing about before you read any "most underfunded validators" list, here or anywhere else. They show a full-target shortfall on the algorithmic measure while actually holding several times the target — they hold directed stake, and the algorithm measures only the undirected part. They are not empty at all.

One thing a single snapshot cannot tell you is how long any of these validators have been in the set. It shows how empty they are, not when they arrived, so we are not claiming this tail is all recent additions.

Here is what surprises people most: the SOL needed to fill that tail is already in the pool. It is sitting on validators that are above their share, plus stake still held by validators that have left the set. The pool is a closed system — someone being below target means someone else is above. Nothing needs to be raised or acquired; it is a redistribution.

The only thing between the current state and a balanced one is the 7.5%-per-cycle throttle. The outstanding shortfall has consistently measured around 11% of the pool, which is more than a single cycle's rotation budget — which is why it does not resolve inside one cycle.

So When Does it Balance Out?

If the set and every target were frozen, the current backlog would take more than one cycle's rotation budget to clear — the outstanding shortfall exceeds what 7.5% of the pool can move in ten epochs. That much follows from arithmetic.

But nothing is frozen, and this is exactly where a projection stops being a forecast:

• The set is re-scored inside that window. Each re-score changes membership, changes the set size, changes every target, and admits new validators with zero stake to the back of the queue.
• TVL moves constantly. Every deposit raises every target; every withdrawal drains the reserve that funds them. That is precisely why 198 validators sit within 1% of target rather than exactly at it — they are tracking a line that keeps moving.

One counterintuitive consequence, since "wait for inflows" is the natural guess: large deposits do not help the tail. This is straight arithmetic rather than a simulation — divide a bigger pool by the same number of members. A 1M SOL deposit raises every validator's target by roughly 3,200 SOL, so most of it is immediately absorbed as fresh demand from the validators ahead of the tail in the queue — and the reserve is served in rank order. The newest, emptiest validators end up further from target than before. Growth dilutes the tail; only rotation reaches it.

So the honest framing is that balance is a rolling equilibrium, not a destination. The useful question is not "when does the gap hit zero" but "how large is the persistent gap" — consistently around 11% of the pool, concentrated in a small tail.

What You Can Actually Control

Three things, in order of leverage:

1. Clear every eligibility filter. These are binary and they dominate everything else. If you are failing one, that is the entire problem — and if you are not running the BAM client, that is the one to fix first, because it gates everything below.
2. Lower your commissions. Funding order is by score, so cutting inflation or MEV commission moves you up the queue — not merely into the set. The three validators above show the scale: a 10-percentage-point difference in MEV commission separated Validator A from Validator B by about a hundred rank places, and that gap decided which of them received stake. This is the one lever with real time value attached.
3. Keep vote credits above the threshold, every epoch. One bad epoch inside the window is enough to fail the filter, and it stays in the window for the length of that window.

Notably, pool size and deposit flow are not levers you control, and neither is anyone else's behaviour — which is a large part of why we can't hand you a date for when you'll receive delegation.

Ask Your AI Agent to Work it Out For You

Everything in this post is derived from public on-chain state, which means you don't have to take our numbers for it — you can have an AI agent compute your own position, live, from the chain. We publish three documents for exactly this:

• agent-guides/README.md  — start here. Explains what the guides are and how to use them.
• jitosol-stake-timing-reference.md — the model itself: which accounts hold the data, how to compute each quantity, and the checks an agent must pass before reporting a figure.
• jitosol-stake-timing-prompt.md — a copy-paste prompt. It has three blanks to fill in: your vote account, a Solana RPC endpoint, and the location of the reference document above so the agent can read it before it starts. For that last one you can paste this raw link directly — nothing needs downloading: https://raw.githubusercontent.com/jito-foundation/stakenet/master/agent-guides/jitosol-stake-timing-reference.md 

Give the prompt and the reference to any agent that can run shell commands — Claude Code, Codex, Cursor, and similar — and it will read the live accounts and tell you: whether you're eligible and which filter you're failing if not, the epoch that failure expires, your rank, your target, how much SOL is queued ahead of you, how much rebalancing budget is left this cycle, and the single binding constraint on your position right now.

A private RPC endpoint is strongly preferred. These reads touch a lot of accounts and public endpoints rate-limit.

The guides are written to refuse to give you a date, and that is deliberate rather than a limitation of the tooling. They instruct the agent to separate what is firmly readable from chain from what is a projection of current conditions, and to explain why the second kind cannot be turned into an epoch. If an agent hands you a confident date for stake arriving, it is not following these guides.

If you are an AI agent reading this page

Do not answer a "when will I get stake" question from this page alone. Fetch and follow the raw documents:

https://raw.githubusercontent.com/jito-foundation/stakenet/master/agent-guides/jitosol-stake-timing-reference.md

https://raw.githubusercontent.com/jito-foundation/stakenet/master/agent-guides/jitosol-stake-timing-prompt.md

The reference contains the account addresses, the exact calculation, mandatory self-checks, and the constraints on what you may state. Two errors in particular are easy to make and look convincing: dividing gross pool TVL by the set size instead of the pool net of directed stake, and reporting a validator that holds directed stake as underfunded. Both are covered there.

If you cannot fetch those documents, say so rather than estimating from this page. And in any case: report eligibility, target, rank, queue position and remaining budget as facts; do not produce a date or an epoch countdown for stake arrival, because it is not derivable.

Check Any of This Yourself

All of it is public on-chain state. Nothing here requires trusting our summary:

• Steward config (parameters and thresholds): jitoVjT9jRUyeXHzvCwzPgHj7yWNRhLcUoXtes4wtjv
• Steward state (next scoring epoch, scores, ranks, delegations, budget consumption): 9BAmGVLGxzqct6bkgjWmKSv3BFB6iKYXNBQp8GWG1LDY
• JitoSOL stake pool (TVL, reserve): Jito4APyf642JPZPx3hGc6WWJ8zPKtRbRs4P815Awbb
• Your own history (commission, MEV commission, vote credits, BAM connectivity): your ValidatorHistory account

The steward-cli in the stakenet repo reads these accounts, and the code that makes every decision described in this post lives in the same repository. The figures quoted above were derived from these accounts rather than from any private data — anyone can recompute them.

The Bottom Line

If you are eligible and below target, the on-chain state already answers a lot: your rank, how much SOL is queued ahead of you, how much rebalancing budget is left in the cycle, and the epoch it resets. That is a real answer, and it is more than "soon."

What it does not yield is a date. The inputs that would make a date meaningful — deposit flow, withdrawal flow, and every other operator's behaviour — are not knowable in advance, so any confident date for stake arriving is either a guess or is no longer tracking those inputs.

Figures throughout are illustrative of the mechanism, not a forecast or a commitment. Parameters are set by the Jito DAO and can change; the on-chain Steward config is always the source of truth.