Most Solana transactions are urgent in a relative sense — land before someone else. Staking transactions are urgent in an absolute one: there is a boundary, and being on the wrong side of it costs a fixed amount of time.
An epoch is roughly two days. A delegation that misses the boundary does not fail. It activates in the next epoch instead, and nothing in the transaction result tells you that happened.
The Boundary Is the Whole Problem
Stake operations do not take effect immediately. They take effect at an epoch boundary:
| Operation | Takes effect |
|---|---|
| Delegate | ★next epoch boundary★ |
| Deactivate | ★next epoch boundary★ |
| Split / merge | immediately |
| Withdraw (inactive) | immediately |
★A delegation landing one slot before the boundary and one landing one slot after are two days apart in outcome.★ Both report success. Both are correct transactions. Only one of them earns rewards for the epoch you were aiming at.
This is why staking submission deserves attention that a routine transfer does not. The cost of landing late is not a worse price — it is a fixed, unrecoverable delay.
Knowing Where You Are
const info = await connection.getEpochInfo();
const slotsRemaining = info.slotsInEpoch - info.slotIndex;
const fractionElapsed = info.slotIndex / info.slotsInEpoch;
console.log(`epoch ${info.epoch}, ${slotsRemaining} slots remaining`);
★Compute your deadline in slots, not in wall-clock time.★ Slot duration varies with network conditions, so an estimate in minutes drifts precisely when the network is busy — which is when your margin matters most.
// ★Submit with slot headroom, not time headroom.★
const SAFETY_SLOTS = 300;
if (slotsRemaining < SAFETY_SLOTS) {
// Too close. Landing is not guaranteed, and a miss costs an epoch.
await scheduleForNextEpoch(operation);
} else {
await submitStakeOperation(operation);
}
The right headroom depends on how much a miss costs you and how reliably you land. For a treasury delegating once, generous headroom is free. For a liquid staking protocol rebalancing every epoch, headroom is opportunity cost, and the correct figure comes from your measured landing distribution.
Verify Activation, Not Submission
This is where staking systems most often report the wrong thing. A landed transaction means the instruction executed. ★It does not mean the stake is active.★
const activation = await connection.getStakeActivation(stakeAccount);
// activation.state: "active" | "activating" | "deactivating" | "inactive"
if (activation.state === "activating") {
// ★Landed, but not yet earning. Activates at the next boundary.★
}
Report the activation state to users, not the transaction status. A dashboard that says "staked" the moment a transaction confirms is wrong for up to two days, and the users who notice are the ones checking whether they are earning.
The same applies in reverse for deactivation. A user who requests unstaking sees a confirmed transaction and expects their SOL. It is deactivating, and it will remain so until the boundary.
If your epoch timing is right and transactions still land late, a free BoltTx key is one line to test the submission path.
Everyone Submits at the Same Time
Epoch boundaries are a scheduling point for the whole network. Liquid staking protocols rebalance, validators adjust, automated systems trigger — all on the same boundary.
★Congestion near an epoch boundary is not random. It is structural.★
The consequences for your submission path:
Fees rise predictably. Derive from recent fees rather than using a fixed value, and expect the figure to be higher here than in the middle of an epoch.
Do not aim for the last slots. The margin you need is largest exactly where you have the least of it.
Spread your own work. If you have many stake operations, submitting them across the epoch rather than all at the boundary avoids competing with yourself on top of everyone else.
// ★Stagger operations that do not need the same boundary.★
const perBatch = Math.ceil(operations.length / availableWindows);
Splitting Before Deactivating
A common operational mistake: deactivating an entire stake account to withdraw part of it.
★A stake account deactivates as a whole.★ To unstake a portion, split first, then deactivate the split:
const tx = new Transaction().add(
StakeProgram.split({
stakePubkey: existingStake,
authorizedPubkey: authority.publicKey,
splitStakePubkey: newStake.publicKey,
lamports: partialAmount,
}),
);
// Then deactivate only the new account.
Split takes effect immediately, so it can be done at any point in the epoch. Only the deactivation is boundary-bound, which means the split should never be what makes you miss a boundary.
★The new stake account needs rent exemption,★ so a split leaves slightly less than you might expect. Account for it when computing the amount, particularly if a user asked to unstake a specific number.
What Retry Means Here
Staking has a different retry calculus than trading.
const outcome = await resolve(sig, lastValidBlockHeight);
switch (outcome.status) {
case "success":
await recordActivating(stakeAccount, targetEpoch); break;
case "expired":
// ★Check the boundary before rebuilding.★
if (stillEnoughSlots()) await rebuildAndResend();
else await deferToNextEpoch(); // ★do not submit late★
break;
case "reverted":
await investigate(outcome.err); break;
}
★An expired stake transaction near a boundary should sometimes not be retried.★ If the retry would land after the boundary, submitting it means activating an epoch later than intended — which may be worse than deferring deliberately and telling the user, rather than having them discover a two-day delay themselves.
This is the opposite of trading, where you resend until expiry without hesitation. Here the retry decision depends on where the boundary is.
What Landing Looks Like
Real transactions through our delivery nodes: median confirmation 336ms — under one slot.
★For staking, that number is what sets your safety margin.★ A predictable tail lets you submit closer to the boundary with confidence. An unpredictable one forces conservative headroom, which for a protocol rebalancing every epoch is a recurring cost.
Where BoltTx Fits
We handle submission. Not stake management, not validator selection, not your rebalancing logic.
Submissions route through our own delivery nodes in four regions with stake-weighted routing and no public mempool exposure. For epoch-boundary work the relevant property is behaviour under the structural congestion that occurs at exactly those boundaries.
You sign locally with your own stake authority. We never hold funds, never sign, and never modify transaction contents. The tip travels inside the transaction, paid on chain from your own wallet, and reverts with the transaction if it fails, because that is how Solana handles atomic transactions. You pay only on transactions that reach the chain.
Get a free API key. No monthly fee:
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");
FAQ
When does a Solana stake delegation take effect? At the next epoch boundary, not when the transaction lands. A delegation landing just before the boundary and one landing just after are roughly two days apart in when they start earning.
How long is a Solana epoch?
Approximately two days, though it varies with slot production. Compute deadlines in slots from getEpochInfo rather than in wall-clock time, since slot duration drifts under load.
Why is my stake not earning rewards after the transaction confirmed?
Because it is activating, not active. Check getStakeActivation — a confirmed transaction means the instruction executed, while activation happens at the epoch boundary.
How do I check if a stake account is active?
getStakeActivation returns one of active, activating, deactivating, or inactive. Report that state rather than the transaction status, since they can differ for up to two days.
How close to an epoch boundary can I safely submit? It depends on your measured landing distribution and what a miss costs. Leave headroom in slots rather than minutes, and treat the boundary as a hard deadline rather than a target.
Why do transactions fail more often near epoch boundaries? Because the whole network schedules work there. Liquid staking rebalances, validator adjustments, and automated systems all trigger on the same boundary, so the congestion is structural rather than random.
Can I unstake part of a stake account? Not directly. Split the account first, then deactivate the split portion. Split takes effect immediately, so it can be done at any point in the epoch.
Why did splitting reduce my staked amount slightly? The new stake account needs rent exemption, which comes out of the split. Account for it when computing amounts, especially if a user requested a specific figure.
Should I retry a stake transaction that expired? Only if the retry would still land before the boundary. If it would not, deferring deliberately and telling the user is better than activating an epoch later than they expect.
How do I know which epoch my stake will activate in? The one after the boundary that follows your landing slot. Record the target epoch when you submit so you can reconcile later and answer questions about timing.
Do stake transactions need priority fees? Near an epoch boundary, generally yes, since that is when contention peaks. Derive the fee from recent activity rather than using a fixed value that will be wrong at one end.
How long does unstaking take on Solana? Deactivation completes at the next epoch boundary, after which the SOL can be withdrawn. A confirmed unstake transaction does not mean the funds are immediately available.
Can I cancel a deactivation? Yes, by delegating again before the deactivation completes. The stake returns to active rather than passing through inactive, so no epoch is lost.
Should a liquid staking protocol rebalance every epoch? That is a strategy decision, but if it does, the submission path matters more than for a one-off delegation. A miss recurs every epoch rather than once.
How do I avoid competing with my own stake transactions? Stagger operations that do not require the same boundary across the epoch. Submitting everything at the boundary means competing with yourself on top of the network-wide congestion.
What happens if a stake transaction lands in the wrong epoch? Nothing fails. It activates one epoch later than intended, which is why verifying activation state rather than transaction status is the only way to catch it.