DEV Community: Suliman Mokhtar

How Many Confirmations Does a Solana Deposit Need?

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:30 +0000

Originally published on xroot.dev.

An exchange support page says your Solana deposit needs “a few confirmations”. A wallet shows a green tick after about a second. Your own explorer tab says “confirmed”, then, a while later, “finalized”. None of those three is using the word the same way, and none of them says what it counted.

Solana’s commitment levels are not a count of blocks the way Bitcoin’s are. Two of them are measurements of stake, and the third is a depth. This post is what each one measures, read from the validator and the reference client, and the one deadline in the client that decides when it gives up.

Processed, confirmed, finalized: what each one is

A transaction has three states the network will report.

Processed means one node executed it in a block that node built or replayed. Nothing else has agreed. The block can still be abandoned, and a transaction can be “processed” and never land.
Confirmed means the block reached optimistic confirmation: more than two-thirds of the epoch’s stake has voted for it. The validator stores this as an array of 32 buckets of stake, one per lockout depth, and “confirmed” is the lowest depth at which more than two-thirds is locked out. That is a one-vote-deep supermajority. It is also the level at which a wallet turns the tick green.
Finalized means the block is rooted — the validator’s tower has 32 votes stacked on top of it, the maximum lockout history plus one. At that depth a validator can no longer vote for a competing fork without forfeiting its stake, and the reference client treats it as irreversible.

Worth knowing: the two-thirds number is a stake fraction, not a validator count. Two hundred small validators voting is not “confirmed”; three large ones might be.

How long each one takes, in today’s slots

Confirmed arrives when enough stake has voted once, which in practice is a handful of slots. Finalized arrives when 32 blocks have been built on top, which is 32 slots on a healthy chain.

At the 250 ms slot time in force when this was written, 32 slots is 8 seconds. The 200 ms step activated this morning and takes effect next epoch, after which it is 6.4 seconds. Under the original 400 ms slot it was 12.8 seconds, which is where most “about fifteen seconds” rules of thumb came from.

Those are the best cases. A skipped leader adds its window. A fork adds the time to resolve it. And the reference client has a hard stop: if a transaction has not finalized within 120 seconds, the client gives up and reports that it may have landed on an abandoned fork.

The query that answers it for one block

getBlockCommitment returns the 32-bucket stake array and the total stake for a slot. The sum of buckets at depth d and deeper is how much stake has that block at least d votes deep. Divide by total stake and you have a number, not a word.

Two limits on it. The node only keeps commitment for slots between its root and its tip, so a block that has already been rooted returns nothing — it is final; the array is gone. And the array is that node’s view: a node a few slots behind reports less stake than one at the tip.

For a signature rather than a block, getSignatureStatuses reports confirmations as a count up to 31, and null once the block is rooted. Null does not mean unknown. It means finalized.

Crediting a deposit: a rule that does not pretend

If you credit on “confirmed”, you credit on two-thirds of stake having voted once. That has not been reorganised in practice, but it is one vote deep and the protocol does not promise it. If you credit on “finalized”, you wait 32 slots and get the protocol’s own definition of irreversible.

For small amounts the difference is a few seconds; for large ones it is the difference between a measurement and a promise. The honest rule is to credit on confirmed for display and on finalized for release, and to use the stake array rather than the word when the amount justifies a query.

One more thing the word hides: a transaction that never landed also never confirms, and the client will tell you nothing until its blockhash expires — 150 slots, 37.5 seconds at 250 ms and 30 seconds at 200 ms. A deposit that is “pending” past that window is not slow. It is gone, and the reasons are a separate post.

What Alpenglow replaces

Everything above is the tower-voting model. Alpenglow, active on testnet and devnet and not yet queued on mainnet when this was written, replaces vote depth with certificates: a block is final when 60% of stake has signed a finalize certificate after notarizing it, or when 80% notarizes in one round. There is no 32-block depth to wait for, and “confirmed” versus “finalized” collapses toward one event.

Until the mainnet gate activates, the model in this post is the one in force. After it, the right question is “does a finalize certificate exist”, and the numbers are in the Alpenglow post.

Confirmations: Questions People Actually Ask

How many confirmations does Solana need to be final?

Thirty-two. “Finalized” means 32 blocks have been built on top of the one holding your transaction, which is about 8 seconds at 250 ms slots and 6.4 seconds at 200 ms.

What does “confirmed” mean on Solana?

More than two-thirds of the epoch’s stake has voted for the block at least once. It is a stake measurement, one vote deep, and it is the level most wallets show as a green tick.

Why does getSignatureStatuses show confirmations as null?

Because the block has been rooted. Null is the finalized state, not an unknown; counts from 1 to 31 appear only while the block is still accumulating depth.

How long should an exchange wait before crediting a Solana deposit?

Display on confirmed and release on finalized. If a deposit has not confirmed within the blockhash lifetime of 150 slots, it did not land and will not.

The three numbers

Two-thirds of stake, voting once — that is “confirmed”, and it is what the green tick means.

Thirty-two blocks deep — that is “finalized”, 8 seconds today and 6.4 next epoch.

One hundred and twenty seconds — that is when the reference client stops waiting.

Credit on the second, display on the first, and treat the third as the point at which something has gone wrong rather than slow.

— The Number Moves With the Slot Time —

Confirmation times are slot counts times a slot length that keeps changing.

The upgrades tracker reads the slot-time and Alpenglow gates from the chain every minute, so the seconds you quote match the regime actually in force.

Open the Upgrades Tracker ↗

The replacement for all of this is a certificate rather than a depth — Alpenglow finality in numbers — and the transaction that never confirms at all is a drop with no error. Every second-count above moves with the slot-time ladder.

Constants read from the Agave validator source at commit beee69b958: runtime/src/commitment.rs and rpc-client/src/nonblocking/rpc_client.rs. Slot times and gate states were read from mainnet on 8 October 2026, epoch 1052.

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

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:28 +0000

Originally published on xroot.dev.

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.

When Solana Staking Rewards Arrive, and Why Yours Was Zero

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:26 +0000

Originally published on xroot.dev.

The epoch ended an hour ago. Your friend’s stake account already shows its reward; yours does not. Or it shows one, and it is zero, with no explanation anywhere. Both are normal, and both are computable — the node knows exactly which block your reward lands in and exactly why it paid nothing, and it keeps neither fact anywhere you can see it.

This post is both facts, from the runtime.

Rewards are paid in a window, not at the boundary

Staking rewards are not credited at the epoch boundary. They are credited over a window of blocks at the start of the new epoch, one partition of stake accounts per block, because paying a million accounts in a single block would stall the network.

The schedule is fixed by three rules:

Distribution begins one block after the first block of the epoch.

Each block pays a fixed number of stake accounts — 4,096 at the original 400 ms slot, 2,560 at the 250 ms slot in force when this was written, 2,048 at 200 ms.

The whole distribution must finish within the first 10% of the epoch. The number of partitions is the number of rewarded accounts divided by the per-block count, clamped to at most a tenth of the epoch’s slots.

With a million rewarded stake accounts at 2,560 per block, that is about 390 blocks — under two minutes at 250 ms slots. A stake account paid in partition 300 sees its reward about a minute and a quarter after one paid in partition 1.

Which block is yours: a hash of your address

The partition a stake account lands in is not random and not by size. It is a hash of the stake account’s address, keyed by the blockhash of the epoch’s first block, taken modulo the number of partitions. The runtime computes it to pay you; the RPC recomputes it to answer getInflationReward, which is how it knows which block to look in.

Everything in that formula is public the moment the epoch’s first block lands: the parent blockhash is in the block, the partition count follows from the number of rewarded accounts. Your reward block is therefore knowable at the start of the window, before it arrives. A wallet that shows “reward pending” could show “reward in block N, about 40 seconds away”. None does.

Worth knowing: ask the RPC for a reward during the window and it refuses with error -32017, “epoch rewards period active”, and hands back the block height at which the distribution completes. That number is the end of the window for everyone, not your partition.

Nine reasons the node pays zero

When the reward calculation skips a stake account, it records a reason. There are nine. The runtime discards them; here is what each one means for you.

DisabledInflation — inflation is off for the cluster. Not a mainnet case.
JustActivated — the stake became effective this epoch and has no credits yet. Your first reward is next epoch, and it covers only the portion that was effective. See the cool-down post for why that portion can be partial.
ZeroPoints — the stake earned no points, which happens when it had no effective lamports during the epoch or its validator earned no credits.
ZeroPointValue — the epoch’s total points were zero, so no reward could be priced. Rare; a cluster-level condition.
ZeroReward — the computed reward rounded to zero lamports. Dust stakes on low-credit validators hit this.
ZeroCreditsAndReturnZero, ZeroCreditsAndReturnCurrent, ZeroCreditsAndReturnRewound — the validator’s vote account earned no new credits this epoch. The middle one is the most common and the source code annotates it with a single word: delinquent. Your validator did not vote, and the stake delegated to it earned nothing.
TooEarlyUnfairSplit — the reward was so small that splitting it between you and the validator’s commission would have rounded one side to zero, so the runtime paid neither and did not advance your credits. Under tower voting your points carry over; under Alpenglow the residual lamport goes to the voter instead.

The practical reading: a zero reward on an account that had a reward last epoch almost always means one of the three “zero credits” cases — your validator was offline. A zero reward on a newly delegated account means JustActivated. A zero reward on a tiny account means ZeroReward or the unfair split.

The commission you were charged is two epochs old

One more thing the runtime does that no dashboard shows. The commission applied to your reward is not the validator’s current rate. It is the rate from the vote state saved a full epoch before the rewarded epoch — the source comment says this is “to prevent last minute commission rugs”. A validator that raises its commission today does not take the higher cut from this epoch’s reward or the next one’s.

That protection predates the newer rule that delays all commission changes by an epoch, and the two now agree. It also means the number on your validator’s profile page today is not the number in your last reward, if it changed recently.

Staking Rewards: Questions People Actually Ask

When are Solana staking rewards paid?

Over a window of blocks at the start of each epoch, starting one block after the epoch’s first block and finishing within the first 10% of the epoch. Each block pays a fixed partition of stake accounts.

Which block will my reward be in?

The partition is a hash of your stake account’s address keyed by the epoch’s first blockhash, modulo the number of partitions. It is computable the moment the epoch’s first block lands.

Why did I get zero staking rewards this epoch?

Most often because the validator earned no vote credits that epoch (it was delinquent), or because the stake only became effective this epoch. The runtime records one of nine reasons; the common ones are those two.

Why was my reward smaller than the validator’s advertised commission implies?

The commission applied is the rate saved a full epoch before the rewarded epoch, not the current one. A recent change does not apply to the reward you just received.

What to check, in order

Was the account effective last epoch? If it was activating, the first reward is partial and arrives next epoch.

Did the validator vote? Zero credits in its vote account for the epoch means a zero reward for everyone delegated to it, with no notice.

Is the window still open? If the RPC returns -32017, the distribution is in progress; your partition may simply be later than your friend’s.

Is the stake tiny? Rewards below one lamport, or too small to split with the commission, are not paid.

Every one of these is a plain account read. The node computed the answer when it skipped you; it just did not write it down.

The commission taken from that reward has its own delays — two commissions, one epoch delay — and under Alpenglow the reward itself changes shape: half of every vote reward goes to the leader.

Constants read from the Agave validator source at commit beee69b958: runtime/src/bank/partitioned_epoch_rewards/mod.rs, runtime/src/inflation_rewards/points.rs and rpc/src/rpc.rs. Per-block counts follow the slot regime in force when this was written.

Solana RPC Error Codes Explained: -32001 to -32021

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:24 +0000

Originally published on xroot.dev.

JSON-RPC reserves the codes from -32000 to -32099 for server-defined errors, and Solana’s node defines twenty-one of them, -32001 through -32021. Most client libraries pass them through as a number and a string, parse two of them structurally, and leave you to search the number. Here is the whole list from the node’s source: what each code means, the message and data the node attaches, and the client action it calls for.

The useful discovery is that several of these errors are not failures. They are the node telling you something precise — its own lag, its retention floor, the block height a reward period ends — that no successful response would have told you.

Transactions

-32002 — SendTransactionPreflightFailure. The simulation before send failed. The data field carries the entire simulation result: the error, the logs, units consumed, return data. This is the one code every client should parse, because the logs inside it are the diagnosis. Action: read the data; do not resend unchanged.
-32003 — TransactionSignatureVerificationFailure. A signature does not verify against the message. Action: a client bug; check the signing order and that the message was not modified after signing.
-32006 — TransactionPrecompileVerificationFailure. An ed25519, secp256k1 or secp256r1 precompile instruction failed verification; the message names the precompile error. Action: for secp256r1 the usual cause is a high-S signature; normalise and retry.
-32013 — TransactionSignatureLenMismatch. The number of signatures does not match the number the message requires. Action: client bug.
-32015 — UnsupportedTransactionVersion. You asked for a versioned transaction without declaring support. The message contains the fix verbatim: retry with maxSupportedTransactionVersion set to the version it names. Action: do exactly that.

Node state

-32005 — NodeUnhealthy. The node is behind the cluster. If it knows by how much, the message reads “Node is behind by N slots” and data carries numSlotsBehind; otherwise “Node is unhealthy”. This is the only place a node volunteers its own lag. Action: fail over, and log the number — it is a free health metric for your provider.
-32008 — NoSnapshot. The node has no snapshot to serve. Action: another node.
-32016 — MinContextSlotNotReached. You asked for a response at or after a slot (minContextSlot) that this node has not reached; data carries the node’s actual contextSlot. Action: retry after a short wait, or route to a node that is ahead. The attached slot tells you how far behind this one is, which makes the code a free staleness probe.
-32021 — NoSlotHistory. The SlotHistory sysvar is unavailable, so a request that depends on it (block production, skipped-slot checks) cannot be answered. Action: another node.

History and archives

-32001 — BlockCleanedUp. The slot you asked for is older than the node’s ledger retains. The message states “First available block: N” — the node’s retention floor. Action: route older queries to an archive endpoint, and record N; it is the boundary between hot and cold history on that provider.
-32004 — BlockNotAvailable. The slot is within retention but the block is not present on this node — typically a slot it has not received or confirmed yet. Action: retry, or try another node.
-32007 — SlotSkipped. The slot produced no block, or is missing because the node jumped to a recent snapshot. Action: not an error for your query; move to the next slot.
-32009 — LongTermStorageSlotSkipped. The archive (Bigtable) has no block for the slot. Action: as above.
-32011 — TransactionHistoryNotAvailable. The node does not serve transaction history at all (history is disabled on it). Action: a different provider.
-32014 — BlockStatusNotAvailableYet. The block exists but its status (confirmed/finalized) is not yet known on this node. Action: retry.
-32019 — LongTermStorageUnreachable. The archive backend could not be reached. Action: retry later; the hot path still works.
-32020 — FilterTransactionNotFound. A before or until signature passed to a history query could not be found. Action: the pivot is wrong or not yet archived; drop it or wait.

Indexes, scans and epochs

-32012 — ScanError. An accounts scan behind getProgramAccounts or a similar query failed or was aborted on the node; the message carries the scan error. Action: narrow the filters, or retry on a node with the index you need.
-32010 — KeyExcludedFromSecondaryIndex. You asked getProgramAccounts with a filter the node could have served from its token index, but the key you filtered on is excluded from that index on this node. Action: the query will not be fast here; narrow it or use a provider with a full index.
-32017 — EpochRewardsPeriodActive. You asked for an inflation reward while the epoch’s rewards are still being distributed; data carries rewards_complete_block_height. Action: wait until the chain passes that block height, then retry. The number is the end of the distribution window for everyone.
-32018 — SlotNotEpochBoundary. A query that must be made at an epoch boundary was made at another slot. Action: use the epoch’s first slot.

What the reference client does with them

The stock Rust client parses exactly two of these into typed errors: -32002 and -32005. Everything else arrives as a code and a message string. The structured data the node attaches to -32016 (the actual context slot), -32017 (the completion height) and -32001 (the first available block) is sent and then discarded by the client, unless you read the raw response yourself.

If you build on top of an RPC — a bot, an indexer, a wallet backend — those three payloads are worth catching. They turn three failures into three measurements.

RPC Errors: Questions People Actually Ask

What does Solana RPC error -32005 mean?

The node is unhealthy or behind the cluster. If it knows its lag, the message reads “Node is behind by N slots” and the data carries the number. Fail over to another node and keep the number as a health signal.

What does error -32002 mean when sending a transaction?

The preflight simulation failed. The error’s data field contains the full simulation result, including the program logs, which is where the actual cause is.

How do I fix -32015 UnsupportedTransactionVersion?

Retry the request with maxSupportedTransactionVersion set to the version named in the message. The message states the fix verbatim.

What does -32016 MinContextSlotNotReached mean?

You asked for data at or after a slot this node has not reached. The data carries the node’s actual context slot, so you know how far behind it is; retry shortly or route to a node that is ahead.

The ones worth handling specially

-32002: read the simulation in data; it is the diagnosis.

-32005 and -32016: read the slot numbers; they are the node’s lag, measured by the node.

-32001: read the first available block; it is the provider’s retention boundary.

-32015: do what the message says.

-32017: wait for the block height it gives you.

The rest are “try another node” or “you have a client bug”, and the message says which.

The worst failures produce no code at all — the seven places a transaction disappears. -32015 is the code transaction v1 made common, and -32017’s block height is explained in when staking rewards arrive.

Constants read from the Agave validator source at commit beee69b958: rpc-client-api/src/custom_error.rs and rpc-client/src/http_sender.rs. Codes are added with releases — check the list against the version you run.

“Log Truncated” on Solana: The 10,000-Byte Rule Explained

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:22 +0000

Originally published on xroot.dev.

The transaction failed. You open it in the explorer, scroll to the program logs to find the error, and the logs stop mid-flow with two words: Log truncated. The error, if the program printed one, is somewhere in the part you cannot see.

The limit is small, it is applied in a way that drops more than you expect, and it applies to simulation too, which is why “I’ll just simulate it and read the logs” does not work either. Here are the rules, from the log collector, and what logging costs you in compute so you can stop paying for the lines that get cut.

The limit, and the way it is applied

Every transaction’s program logs go into one collector with a byte budget of 10,000 — ten thousand, decimal, not ten kibibytes. Each line a program emits is counted against it.

The check runs before a line is stored: if the bytes already written are at or above the limit, the line is dropped. The comparison is >=, not >, with a consequence that is often missed: the line that would cross the limit is not cut short to fit — it is dropped whole, and so is every line after it. Then the collector appends its own line, “Log truncated”, once, and stops.

The collector’s own test spells out the arithmetic: 20,000 attempts to write a one-byte line produce exactly 9,999 stored lines, then the marker. A program that logs a 2,000-byte line at byte 9,000 loses the whole line.

Simulation is capped too

The natural workaround — simulate the transaction and read the full logs — does not work, because the simulation path uses the same collector with the same default. The runtime’s simulation entry point passes “no limit” to the collector constructor, but “no limit” at that layer means “use the default”, and the default is 10,000.

There is exactly one way to construct an unlimited collector, and nothing in the validator calls it. Full logs are not available through any RPC on any public node.

Worth knowing: the limit is a per-validator flag. An operator can raise --log-messages-bytes-limit on their node, which means the same transaction can return different logs from different RPC endpoints. If your provider’s node has raised it, you will see more; if yours is truncated and a friend’s is not, that is why.

Where the full logs actually go

Every line the collector receives is also emitted through the validator’s ordinary logging at debug level, under a target named stable_log, before the byte budget is applied. An operator running a node at debug verbosity for that target sees the untruncated stream in the node’s log file — the one place the limit does not reach.

That is not a feature you can use from a wallet or an explorer. It is a reason to run your own node for debugging, or to ask your provider whether they can.

One more way a line goes missing, unrelated to the budget: the logging macro the runtime uses tries to borrow the collector, and if the collector is already borrowed at that moment, the line is silently dropped with no marker at all. It is rare and it is non-deterministic, which is the worst kind of missing log.

What each log line costs you

Logging is not free, and the cost is charged whether or not the line survives the budget.

msg! with a string — the sol_log_ syscall — costs the larger of 100 compute units and the string’s length in bytes. A 40-character message costs 100; a 4,000-byte dump of an account costs 4,000.

Logging a number (sol_log_64) costs 100. Logging a public key (sol_log_pubkey) costs 100.

sol_log_data, the structured variant, costs 100 × (1 + number of fields) plus the total bytes — so three 32-byte fields cost 100 × 4 + 96 = 496.

A program that logs generously can spend a meaningful fraction of its compute budget on lines nobody will see past byte 10,000. And because the leader ranks transactions by fee divided by requested compute, a bloated compute limit to cover logging also lowers your landing rank.

What to do instead

Log less, and log the thing that matters first. The error you need to read should be the first line, not the last.

Log bytes, not formatted strings. A formatted string of a struct is long; its discriminant and one or two fields are not.

Use return data for structured output. A program can set up to 1,024 bytes of return data that the RPC surfaces in simulation and transaction metadata, outside the log budget, and it is the right channel for “here is the result” rather than “here is a diary”.

Put the diagnostics behind a flag. A compile-time feature that enables verbose logging on devnet and strips it on mainnet costs nothing in production and keeps the budget for the line you need.

Log Truncation: Questions People Actually Ask

What does “Log truncated” mean on Solana?

The transaction’s program logs exceeded the 10,000-byte collector limit. The line that crossed the limit and every line after it were dropped, and the collector appended “Log truncated” once.

Why are my logs truncated in simulateTransaction too?

Simulation uses the same collector with the same default. “No limit” at the simulation entry point resolves to the 10,000-byte default, and no RPC path constructs an unlimited collector.

How much compute does msg! cost?

The larger of 100 compute units and the message length in bytes. Numbers and public keys cost 100 each; sol_log_data costs 100 per field plus one, plus the bytes.

Can I get the full logs anywhere?

On a node whose operator raised the per-validator log limit, or from the node’s own debug log, which receives every line before the budget applies. Neither is available from a standard public RPC.

The two numbers

Ten thousand bytes per transaction, applied as “drop the crossing line and everything after it”, in simulation as well as execution.

One hundred compute units minimum per line, rising with length, charged whether the line is kept or not.

The second number is the one you control.

A truncated log often hides the line that explains the failure, which is when the RPC error codes carry the rest of the diagnosis — and a simulation can be deliberately misleading even with complete logs. What each log call costs feeds straight into the leader’s ranking formula.

Constants read from the Agave validator source at commit beee69b958: svm-log-collector/src/lib.rs, syscalls/src/logging.rs and validator/src/commands/run/args.rs.

Stake-Weighted QoS on Solana, With the Actual Formula

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:20 +0000

Originally published on xroot.dev.

Every Solana RPC provider now sells some version of “staked connections”: your transactions ride a validator’s stake to the leader’s door, so they get in when unstaked traffic does not. The pitch is right. The mechanism is a formula in the validator’s QUIC server, and reading it tells you three things the pitch does not — how much a connection actually gets, where extra stake stops helping, and why a sender on the other side of the planet is given more room than one next door.

The door: connections and streams

A leader accepts transactions over QUIC. Each sender holds a connection, and sends each transaction on a stream inside it. The leader limits both.

Connections are split into two pools, each 2,000 deep by default: one for senders whose identity holds stake, one for everyone else. A staked identity may hold up to 16 connections, an unstaked one up to 8, and each IP address may open 8 new connections per minute by default — the validator binary raises that to 32 to tolerate container hosts.

Staked senders are keyed by public key, not IP: the 16-connection cap and any ban follow the identity across every address it connects from. All connections under one identity share a single stream counter, so opening more connections buys no more streams.

The stream allowance, exactly

How many streams a connection may have in flight at once is the number that decides whether your transactions are admitted under load. For a staked sender:

streams = clamp( stake_ratio × (100,000 − 128) + 128, 128, 512 )

where stake_ratio is the sender’s stake divided by total stake. Then every sender, staked or not, has the result scaled by round-trip time:

streams × clamp(rtt_ms, 50, 350) ÷ 50

An unstaked sender gets a flat 128 before the RTT scaling.

Three things fall out of the arithmetic.

The ceiling is low. The formula reaches 512 when stake_ratio × 99,872 + 128 = 512, which is a stake ratio of about 0.38%. A sender holding more than roughly 0.38% of all stake — on the order of 1.5 million SOL at today’s totals — gets exactly the same 512 streams as one holding 0.38%. Beyond that point, stake buys zero concurrency.
Distance is rewarded. The RTT factor runs from 1× at 50 ms to 7× at 350 ms. A peer 350 ms away gets seven times the in-flight streams of one 50 ms away. That is bandwidth-delay-product scaling — the far peer needs more in flight to keep the same throughput — but it means a sender who measures a long RTT to a leader is granted more room, not less.
There is a trapdoor at the bottom. A staked identity whose stake ratio is below 1/50,000 — about 8,000 SOL at a 400-million-SOL total — is reclassified as unstaked. Small stake is not a small lane; it is no lane.

Throttling: when the budget is actually enforced

The allowance above is a cap on concurrency. A second mechanism caps rate: the leader admits at most 500 new streams per millisecond across all senders, and it meters per 100 ms window.

The unstaked pool is throttled always: each unstaked connection gets 20 streams per 100 ms, derived from a 200-transactions-per-second budget per connection.

The staked pool is throttled only under load. The server tracks an exponential moving average of stream load, and until that average reaches 95% of capacity, a staked sender may use the whole staked budget — 40,000 streams per 100 ms. Past 95%, each staked sender’s share becomes its stake ratio times 40,000, with a floor of 21.

So the system is bimodal. In a quiet block, a staked connection with any stake at all is effectively unlimited. In a hot block, it gets its proportional share, and the share of a small validator is small.

How stake is bought: the override

The stake the server consults is not only the validator’s real delegation. A validator can grant virtual stake to any peer identity through its admin interface, and the server refreshes its view of staked nodes every 5 seconds. That is the mechanism under every “staked connections” product: the provider’s sending identity is given stake it does not hold, by validators it has an arrangement with, and the leader treats it accordingly.

Two properties of the override matter to a buyer. It takes effect, or is revoked, within five seconds. And it only counts at validators that have granted it — a lane sold by one validator is a lane at that validator’s slots, which are a fraction of the schedule.

Stake is also revalidated on a randomised one-to-two-hour cycle, and a stale cache can over-grant by at most a factor of two. Increases never evict an existing connection; a newcomer with more stake evicts a lower-staked connection only by winning a two-sample lottery, and if it loses it is silently demoted to the unstaked pool.

What this means for a transaction you send through an RPC

Your wallet never holds a connection to a leader; your RPC provider’s sending node does. The node’s identity, its granted stake, and its RTT to the current leader decide its stream allowance, and under load that allowance is what your transaction competes for.

If the provider’s node is unstaked, your transaction is in the 128-stream pool with every other unstaked sender’s, throttled to 20 streams per 100 ms per connection, always. If it holds a sliver of stake above the 1/50,000 floor, it is in the staked pool, unthrottled until the leader is 95% loaded, and then proportional. If it holds 0.38% or more, it has the maximum, and more stake than that is marketing.

Stake-Weighted QoS: Questions People Actually Ask

What is stake-weighted QoS on Solana?

A rule in the leader’s QUIC server that allocates connection slots and in-flight streams by the sender’s share of stake. Staked senders get between 128 and 512 concurrent streams, scaled by round-trip time; unstaked senders get 128 and are rate-limited always.

How much stake does an RPC need for the maximum lane?

About 0.38% of total stake. At that ratio the formula reaches its 512-stream cap, and additional stake buys no more concurrency.

Can a validator sell its stake-weighted lane?

Yes. A validator can grant virtual stake to a peer identity through its admin interface; the server refreshes the grant within five seconds. The lane applies only at that validator’s own slots.

Why does a far-away sender get more streams?

The allowance is multiplied by round-trip time, clamped between 50 and 350 ms and divided by 50, so a 350 ms peer gets seven times the in-flight streams of a 50 ms peer. It is bandwidth-delay scaling, not a reward.

The three numbers to ask a provider for

Their sending identity’s stake ratio — real or granted — against the 1/50,000 floor and the 0.38% ceiling.

Which validators have granted it, because the lane only exists at those validators’ slots.

Their RTT to leaders, because the server multiplies the allowance by it.

Nothing else in the pitch changes the formula.

This is door three of the seven places a transaction disappears, and it decides who is heard before the fee ranking is ever consulted. Stake buys a seat in consensus too — the 2,000-seat cap.

Constants read from the Agave validator source at commit beee69b958: streamer/src/nonblocking/swqos.rs, streamer/src/quic.rs and core/src/staked_nodes_updater_service.rs.

Passkeys on Solana: Why Half of WebAuthn Signatures Fail

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:18 +0000

Originally published on xroot.dev.

A passkey wallet is the obvious future: no seed phrase, a thumbprint or a face, the device’s secure chip holding the key. Solana made it possible by adding native verification for the curve those chips use — P-256, called secp256r1 in the code — as a precompile, the same way it verifies Ethereum-style secp256k1 signatures.

Then developers wired it up and found that roughly every second signature failed. Nothing was wrong with the authenticator and nothing was wrong with the chain. The two disagree about what a valid signature looks like, and the chain’s rule is the stricter one. Here are the rules the precompile enforces, what each verification costs you in fee and block space, and the one-line fix for the failures.

What the precompile checks, in order

A secp256r1 instruction carries a count byte, a reserved byte, an offsets table, and then the signatures, public keys and messages it references. The verifier reads it in this order:

The count is data[0]. Zero is rejected. More than eight is rejected. That is the hard cap per instruction; a transaction needing more signatures needs more instructions.

data[1] is read by nobody. The source says so in a comment: “we do not check or use the byte at data[1]”. It is one free byte per instruction that the consensus ignores.

Each signature is checked for low S. The S component must be at most half the curve order; anything above is rejected as an invalid signature, even though it is mathematically valid.

Each public key is validated as a point on the curve, and the signature is verified against the message through OpenSSL.

Why half of them fail: high S

An ECDSA signature has two halves, R and S, and for any valid S there is a second valid value, the curve order minus S. Both verify. One is “low” (at most half the order) and one is “high”. A signer that does not normalise will produce each about half the time.

Bitcoin and Ethereum reject high-S signatures to prevent malleability — the ability to produce a second, different-looking signature for the same message — and Solana’s precompile does the same. WebAuthn authenticators do not normalise. They return whichever half the hardware produced, and about half the time that is the high one.

The fix is one line, and it belongs in the client before the transaction is built: if S is greater than half the order, replace it with the order minus S. The signature stays valid, the authenticator is none the wiser, and the precompile accepts it every time. A passkey wallet that does not do this will fail roughly half its transactions and blame the network.

What each signature costs

Two costs, charged in different places.

Fee. Every precompile signature counts as a signature for the base fee. The fee calculation sums transaction signatures, ed25519 signatures, secp256k1 signatures and secp256r1 signatures, and multiplies the total by the per-signature rate. A transaction with one fee-payer signature and one passkey signature pays two signatures’ worth of base fee — 10,000 lamports at the default rate, not 5,000.
Block space. The cost model charges 4,800 compute units per secp256r1 verification — 160 microseconds at the 30-units-per-microsecond ratio the model uses. For comparison an ed25519 precompile signature costs 2,400 and a secp256k1 one 6,690. Those units are added to your transaction’s cost, which is the denominator in the leader’s ranking formula, so a passkey transaction ranks lower than an identical ed25519 one at the same priority fee.

The eight-per-instruction cap interacts with the cost: the verifier sets up its curve context once per instruction, so eight signatures in one instruction cost less validator time than eight instructions of one signature, even though the cost model charges the same.

How a passkey transaction is actually built

The precompile verifies a signature; it does not authorise anything by itself. The pattern that makes a passkey a wallet is:

A smart-wallet program owns the user’s assets and stores the user’s P-256 public key.

A transaction carries a secp256r1 precompile instruction with the passkey signature over a message, followed by an instruction to the smart-wallet program.

The smart-wallet program reads the precompile instruction from the transaction’s instruction sysvar, confirms it verified the expected public key over the expected message, and only then moves assets.

A relayer or the user pays the fee with an ordinary ed25519 key, because the fee payer must still be a Solana keypair. That is why the base fee counts two signatures.

Two consequences follow. The passkey never signs a Solana transaction directly — it signs a message the program checks — so replay protection is the program’s job, not the runtime’s. And a transaction that references the wrong instruction index, or a message the program does not expect, fails in the program, not in the precompile.

The limits you will hit first

Eight signatures per instruction, and the instruction count and size limits of the transaction itself. A P-256 signature is 64 bytes, a compressed public key 33, and the message whatever the program expects — WebAuthn messages include the authenticator data and client data hash, which are not small. In a 1,232-byte legacy transaction, two or three passkey signatures fill it. Transaction v1’s 4,096-byte envelope is the comfortable home for multi-signature passkey flows.

The precompile is feature-gated, and on mainnet the gate has been active since epoch 800. Check its state on any other cluster you target before you ship a wallet that depends on it.

Passkeys: Questions People Actually Ask

Does Solana support passkeys natively?

Solana verifies P-256 (secp256r1) signatures through a precompile, which is the curve passkeys and WebAuthn authenticators use. A smart-wallet program reads the verified signature and decides what it authorises; the precompile is feature-gated, so check its state on your target cluster.

Why do my WebAuthn signatures fail on Solana?

The precompile rejects high-S signatures. Authenticators produce high S about half the time. Normalise S to the low half (order minus S when S exceeds half the order) before submitting.

How much does a passkey signature cost on Solana?

A full signature’s share of the base fee, plus 4,800 compute units of block-space cost per verification. A transaction with a fee payer and one passkey pays two signatures of base fee.

How many passkey signatures fit in one instruction?

Eight. The precompile rejects a count of zero or more than eight; additional signatures need additional instructions, and the transaction size limit applies.

The checklist for a passkey integration

Normalise S to the low half before building the transaction. This alone removes the “random” failures.

Budget two signatures of base fee per passkey transaction, and 4,800 compute units of block space per verification.

Keep to eight signatures per precompile instruction and read the transaction size as you add them.

Verify, in your program, that the precompile instruction you are trusting checked the key and message you expect. The precompile proves a signature exists; your program decides what it means.

Each passkey signature is block space like any other — the ranking formula counts its 4,800 units — and signed approvals that must wait for a human pair naturally with a durable nonce. Verification data fits more comfortably in a 4,096-byte v1 transaction.

Constants read from the Agave validator source at commit beee69b958: precompiles/src/secp256r1.rs, cost-model/src/block_cost_limits.rs and fee/src/lib.rs. The enable_secp256r1_precompile gate has been active on mainnet since slot 345,600,000, the first slot of epoch 800.

Solana Honeypots That Pass Your Sell Simulation: How

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:17 +0000

Originally published on xroot.dev.

The careful trader’s routine: before buying a new token, simulate a sell. Build the swap back to SOL, run it through simulateTransaction, confirm it succeeds. If the sell simulates, the token is not a honeypot. Buy.

The routine has a hole, and some tokens are built to sit in it. A program can tell whether it is running inside a simulation or inside a real block, and behave differently in each. The sell succeeds on paper and reverts on chain, every time, for everyone. This post is the mechanism — it is in the validator’s own test suite — and what a check has to do instead.

How a program knows it is being simulated

When a node simulates a transaction, it runs it against a copy of the current state. For almost everything the program can see — accounts, balances, the clock — the simulation and the real execution are identical. For one thing they are not.

The SlotHistory sysvar is a bitmap of which recent slots produced blocks. In real execution a program reads the sysvar as it stood when the block began. In simulation, the node substitutes its own version of that one account — it is the only account the simulation path overrides, and the source says so in a comment: no other overrides are expected. The substituted version is not quite the same shape as the one a block producer provides.

The validator’s test corpus includes a program that does exactly this: it reads the SlotHistory account, finds its newest slot, and compares it with the slot in the Clock sysvar. The two relationships differ between simulation and execution, and the program branches on the difference. The test exists to make sure the detection keeps working, because tooling relies on it. It also hands anyone who reads the test suite a honeypot recipe.

What the honeypot does with that bit

The pattern is short. The token’s transfer logic — a Token-2022 transfer hook, or a custom program the pool routes through — checks the simulation flag. If simulated, allow the transfer. If real, fail it for any wallet that is not on the deployer’s list.

Every sell simulation in the world passes. Every real sell fails. Explorers show successful simulated sells, bots report “sellable”, and the only transactions that ever execute are buys and the deployer’s own exits.

Two smaller tricks sit alongside it, and they do not even need the simulation bit. Simulation uses a blockhash age six slots more conservative than a leader, so a program that reads the blockhash age can occasionally distinguish the two. And a program can simply read the Clock and behave differently after a fixed slot — a sell that works until launch day plus one epoch, then stops.

Why the static checks still matter

The simulation-aware honeypot is the rare case. The common honeypot is still a configuration you can read without executing anything:

A freeze authority that can freeze your token account after you buy.

A transfer hook program whose source you cannot read.

A pausable or default-frozen mint, or a permanent delegate that can burn or move your balance.

A transfer fee at or near 100%.

A permissioned mint whose allowlist you are not on.

Those are flags on the mint and its extensions, and a static audit reads them in one account fetch. The audit page runs those reads and reports each one with what it means. What it cannot do, and does not claim to do, is execute your sell on chain — which is the only test the simulation-aware class fails.

The test that cannot be fooled

Execution. A sell that is actually submitted and actually lands, for a wallet the deployer does not control, is the one check that no program can branch around — it runs in a real block with the real sysvar.

That is expensive to do for every token and impossible before you hold any. The practical compromise: buy an amount you can lose, sell a fraction of it immediately in a real transaction, and only then size up. A sell that lands is evidence; a sell that simulates is a claim.

The other signal is history. A token whose only successful sells belong to a handful of wallets, while hundreds of buys never produce a sell, has told you what the program does without you reading it. Address history with block positions makes that pattern visible, and it is the same data the sandwich post uses.

What this post does not say

It does not say the detection trick is common. Most tokens that cannot be sold are stopped by a freeze authority or a hook, and a static audit finds those. It does not say a passing simulation is worthless — a failing one is still a reliable refusal. And it does not say any page, including ours, can certify a token as sellable. A certificate would be a promise the mechanism cannot keep.

Honeypots: Questions People Actually Ask

Can a Solana program detect that it is being simulated?

Yes. Simulation substitutes one sysvar account, SlotHistory, and a program that compares it with the Clock sysvar can tell the two environments apart. The validator’s own test suite contains a program that does this.

My sell simulation passed. Is the token safe?

Not necessarily. A simulation-aware program allows the sell in simulation and refuses it on chain. A passing simulation rules out the common honeypot configurations only if the static checks also pass, and a real sell is the only decisive test.

What is the safest way to test if I can sell a token?

Sell a small amount in a real, submitted transaction before buying more. A sell that lands on chain cannot be faked by the program.

Does the token audit catch simulation-aware honeypots?

No. It reads the mint’s authorities, extensions, fee and hook configuration, which catches the ordinary cases. It does not execute a sell, and no static check can detect behaviour that only appears in a real block.

The order of checks

Read the mint: authorities, extensions, fee, hook. Refuse on any of the flags above.

Simulate the sell. Refuse on failure; treat success as necessary, not sufficient.

Sell a fraction for real before you size up. That is the only step a program cannot see coming.

— Most Traps Are Static —

Read the mint before you buy, then prove the exit with a real sell.

The token audit reads the authorities, extensions and hooks that stop most unsellable tokens, straight from the chain. What it cannot see is a program that behaves differently when it is not being simulated — which is why the last check is a small real sell.

Audit a Token ↗

The same blind spot has a sibling that needs no clever program at all — owner reassignment — and the legitimate version of a frozen-until-approved token is Token ACL.

Constants read from the Agave validator source at commit beee69b958: programs/sbf/rust/simulation/src/lib.rs, svm/src/account_loader.rs and runtime/src/bank.rs.

The Solana Scam a Wallet Simulator Cannot See: Assign

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:15 +0000

Originally published on xroot.dev.

Your wallet simulates every transaction before you sign. It shows the SOL going out, the tokens coming in, the accounts touched. You have been told, correctly, to read that preview and refuse anything that drains you.

There is an instruction that drains you and shows nothing. No balance changes. No tokens move. The preview reads “no balance change”, you sign, and from that moment your account belongs to someone else’s program. In December 2025 SlowMist reported a case in which one signature with no visible balance change replaced a victim’s owner permission: more than $3 million was drained, and about $2 million held inside a DeFi position was later recovered with that protocol’s help.

The instruction is Assign, in the System program. Here is what it does, why simulators are blind to it, and the one check that catches it.

Every Solana account has an owner, and the owner is the only writer

An account on Solana is a balance, some data, and an owner — the program allowed to modify the data and debit the balance. Your wallet’s main account is owned by the System program, which is why the System program’s Transfer instruction can move your SOL when you sign. A token account is owned by the token program; a stake account by the stake program.

The rule the runtime enforces is strict: only the owning program can change an account’s data or reduce its lamports. Any other program may read it and may add lamports to it, nothing more.

Assign changes the owner. It is a legitimate instruction — every program-derived account starts life as a System account and is assigned to its program — and it requires the account’s signature. Your signature. Which is exactly what a phishing transaction asks for.

Why the preview says “no balance change”

Wallet simulators run the transaction and diff the result: lamports before and after, token balances before and after. Assign changes neither. The account holds the same SOL after the instruction as before. The diff is empty, and the preview says so, in the reassuring green that every simulator uses for a transaction that costs you nothing.

The preview is not lying. It is answering the wrong question. “Did my balance change” is the question for a transfer. The question for Assign is “can I still move this balance”, and no simulator asks it, because the answer is not a balance.

Worth knowing: an Assign that sets the owner to the owner the account already has is a no-op the program accepts without even checking for a signature. A transaction that includes one is odd, but harmless. The dangerous one names a program you do not control.

What you can and cannot do afterwards

After the reassignment, the account’s SOL is still there and still yours in every sense except the one that matters.

You cannot transfer it. The System program’s Transfer requires the source to be a System-owned account, and will also refuse any account that carries data. Your account now has a different owner, and whichever program that is decides what happens to the lamports.

You cannot reassign it back. Assign requires the current owner program’s cooperation, and the attacker’s program will not give it.

You cannot close it, or recover its rent, or use it as a fee payer in any transaction that touches its balance.

The attacker’s program, meanwhile, can debit the account at will, which is how the SOL leaves. Tokens held in your wallet’s token accounts are a separate matter: those accounts are owned by the token program, and Assign on your main account does not touch them. But the same phishing transaction routinely includes a token SetAuthority on each of them, changing the authority to the attacker — a different instruction, the same empty preview.

The one check

Read the owner. getAccountInfo returns it for any address. For a wallet’s main account it must be the System program, 11111111111111111111111111111111. For a token account it must be the token program, and the authority recorded inside the account’s data must be your wallet.

If either has changed, the account is no longer yours to operate, and no amount of revoking or re-signing fixes it. Move what can still be moved — tokens in accounts whose authority is still you, SOL in accounts still owned by the System program — and treat the reassigned account as gone.

Before you sign, the check is different: read the instruction list, not the balance diff. An Assign naming an unfamiliar program, or a SetAuthority on any of your token accounts, is a refusal regardless of what the preview says. Most wallets now flag these; the campaign in January is why.

What this post cannot offer

A fix. There is none. A reassigned account cannot be reclaimed by its former owner, and any page that offers to “recover” such an account is either describing something else or is the next scam. What exists is prevention — read the instructions, not the diff — and limitation: keep the balance you cannot afford to lose in an account you do not sign transactions from.

The sibling hazard is the pre-signed transaction that never expires, which is a different mechanism with the same lesson: the decisive moment is signing, and the simulator is not the judge.

Owner Reassignment: Questions People Actually Ask

What does the System program’s Assign instruction do?

It changes an account’s owner to another program. Only the owning program can modify an account’s data or reduce its balance, so after an Assign the previous owner cannot move the SOL in it.

Why did my wallet’s simulation show no balance change?

Because Assign does not move lamports or tokens. Simulators diff balances, and the diff is empty. The harm is a change of control, which a balance diff cannot show.

Can I get a reassigned Solana account back?

No. Reassigning requires the current owner program’s cooperation. Move anything that is still under your control and treat the reassigned account as lost.

How do I check whether my accounts are still mine?

Call getAccountInfo and read the owner. A wallet’s main account must be owned by the System program; a token account by the token program, with your wallet as the authority inside its data.

Two rules

A preview that shows no balance change is not a preview that shows no harm. Read the instructions.

Check your accounts’ owners today. It is one RPC call per account, the answer is a program id, and for a wallet it must be the System program. If it is anything else, the account is not yours any more, and the time to find out is before you need it.

Its closest relative is a signed transaction that never expires, and its counterpart on the token side is a honeypot that passes your simulation.

Constants read from the Agave validator source at commit beee69b958: programs/system/src/system_processor.rs and the transaction-context crate.

Solana Vanity Addresses: What a Prefix Really Costs

Suliman Mokhtar — Sat, 10 Oct 2026 10:07:14 +0000

Originally published on xroot.dev.

You want a wallet address that starts with your name, or a token mint that starts with the ticker. It is a real thing people do, the tool to do it ships with the Solana CLI, and the maths behind it fits on one line. Here is how the grinder works, how many tries a prefix costs, the two safety rules that matter, and the reason a matching prefix should never be mistaken for a matching address.

What an address is

A Solana address is 32 random bytes — a public key — written in base58. Base58 is the alphabet of digits and letters with four characters removed because they look like each other: zero, capital O, capital I and lowercase l. That leaves 58 characters, and 32 bytes come out as 43 or 44 of them.

There is no “choosing” an address. You generate a random private key, derive its public key, and look at the characters. A vanity address is a random key whose public key happened to start with what you wanted, found by generating keys until one does. The grinder is a loop.

Worth knowing: the smallest possible 44-character address is the one the tool keeps as a constant — a 2 followed by forty-three 1s. Not every string is reachable: a prefix that would decode to more than 32 bytes cannot exist, and the tool skips candidates above that bound before it bothers encoding them.

The grinder

The tool is solana-keygen grind. It takes three kinds of target, each as the pattern and a count of how many matching keys you want:

--starts-with xroot:1 — one key whose address begins with xroot.

--ends-with 1234:1 — one key whose address ends with 1234.

--starts-and-ends-with ab:cd:1 — both.

Add --ignore-case to accept any capitalisation of the letters, and --num-threads to use more cores. Every thread generates random keypairs, encodes the public key, and checks it against every target until the counts are filled. When a match is found the keypair is written to a file named after the address.

That is the whole algorithm. There is no shortcut, no table, no way to steer the key toward a prefix. Each try is independent and each has the same tiny chance.

The odds, in tries

Each character position in a base58 address is close to uniform over 58 values, so a case-sensitive prefix of n characters matches one key in 58ⁿ on average:

1 character — 58 tries

2 — 3,364

3 — 195,112

4 — about 11.3 million

5 — about 656 million

6 — about 38 billion

7 — about 2.2 trillion

--ignore-case helps by roughly the number of letters in the prefix that have both cases: a five-letter all-alphabetic prefix with case ignored is about 2⁵ = 32 times cheaper — twenty million tries instead of 656 million.

How long that takes depends entirely on your hardware, and the tool shows its progress rather than promising a rate. The useful rule is the ratio: each extra character multiplies the work by 58, each case-insensitive letter divides it by about 2. Four characters is minutes on a laptop; six is a serious machine for a long time; eight is not a thing people do for a wallet.

Two safety rules

Never use a website or a service to grind a key. Whatever generates the keypair holds the keypair. A vanity address from a web generator is an address someone else can empty, and the pattern of “cheap vanity address, drained later” is old. Run the tool yourself, on your own machine, offline if the key will hold anything.
The output file is plain text. solana-keygen writes the keypair as a plain JSON array of bytes. If you generate with a recovery phrase and a passphrase, the passphrase protects the phrase, not the file — the tool’s own source describes the file as stored as insecure plain text. Treat the file the way you would treat a seed phrase written on paper, and note that the tool refuses --no-outfile unless you also asked for a mnemonic, so a key can never be generated with no recovery path at all.

The reason a prefix is not an identity

This is the part that matters more than the odds. If you can grind an address that starts with xroot, so can anyone else. Address poisoning attacks do exactly that: generate an address whose first and last characters match a victim’s real counterparty, send a dust transfer so it appears in the victim’s history, and wait for the victim to copy the lookalike from the list.

A vanity prefix on your own address makes you easier to recognise and easier to imitate in the same move. The defence is the same as for any address: verify the whole string, or a long enough suffix as well as the prefix, and never copy an address out of a transaction history. The grinder that makes vanity addresses possible is the grinder that makes the poisoning cheap.

Vanity Addresses: Questions People Actually Ask

How do I generate a Solana vanity address?

With the CLI: solana-keygen grind --starts-with PREFIX:1, optionally --ignore-case and --num-threads N. The tool generates random keypairs until one’s public key matches, then writes the keypair file.

How long does a vanity address take?

On average 58 to the power of the prefix length tries for a case-sensitive prefix: about 11 million for four characters, 656 million for five, 38 billion for six. --ignore-case divides that by roughly two per letter. Actual time depends on your hardware.

Are vanity addresses safe?

Only if you generate them yourself, offline, and guard the plain-text keypair file. Any service that generates the key for you holds the key. A vanity prefix also makes your address easier to imitate in address-poisoning attacks.

Can two wallets have the same vanity prefix?

Yes, and that is the risk. Anyone can grind a prefix. Verify the entire address, never just the start, before sending.

If you are going to do it

Run solana-keygen grind locally, with --ignore-case if the capitalisation does not matter to you, and keep the prefix to four or five characters unless you have the hardware for more.

Treat the output file as the key itself, because it is.

Tell the people who send you money to check the full address, not the start of it. Your prefix is the easiest part of your address to fake.

A familiar-looking prefix is exactly what drainers rely on — owner reassignment is one of them — and a keypair that must stay offline signs more safely with a durable nonce.

Constants read from the Agave validator source at commit beee69b958: keygen/src/keygen.rs and clap-v3-utils/src/keygen/mnemonic.rs. Flag names change between releases — check them against solana-keygen grind --help for the version you run.

Arc Chain, in Numbers: One Dollar, Two Decimals, and 97,000 Tokens in a Day

Suliman Mokhtar — Sun, 20 Sep 2026 02:50:10 +0000

Originally published on xroot.dev.

Circle opened Arc's public mainnet on 16 September 2026. Four days later I read it the way I read every new chain — from its own node, with eth_call, ignoring the launch posts. Six numbers came back that the launch posts do not carry, and two of them will bite anyone who integrates the chain from a table instead of a query.

The headline facts hold up: an EVM layer 1 whose native coin is USDC, blocks every half second, deterministic finality, and a validator set of twelve named institutions — Circle plus BlackRock, DTCC, Visa, Mastercard, ICE and six more — running proof of authority. Everything that follows is what the chain itself says, read on 20 September at block 21,767,062, with the call that produced each figure so you can run it again.

Ground Truth in Four Calls

A chain id gets transcribed wrong, an RPC URL goes stale, and "mainnet is live" means at least four different things. So: ask the node.

RPC=https://rpc.mainnet.arc.io
call() { curl -s $RPC -H 'content-type: application/json' -d "$1"; }

call '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# -> 0x13b2 = 5042

call '{"jsonrpc":"2.0","id":1,"method":"web3_clientVersion","params":[]}'
# -> "arc/v1"            (a Reth-based client under a Malachite BFT consensus)

call '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]}'
# -> gasLimit 0x1c9c380 = 30,000,000 · gasUsed 213,828 · 4 transactions
#    baseFeePerGas 0x4a817c800 = 20 gwei · extraData 0x00000004a817c800

call '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x000000000000000000000000000000000000006b","latest"]}'
# -> 0x                   (no Arbitrum precompile: this is not a Nitro chain)

Chain ID — 5042 (0x13b2)

Stack — Malachite BFT + Reth · Osaka EVM · L1

Block — ~0.5 s · 30M gas · 3–11% used

Gas coin — USDC · base fee pinned at 20 gwei

The last line of the block header is the interesting one. extraData is eight bytes, and it equals the base fee: Arc publishes the next block's base fee in the parent header. That is a fee market telling you its answer before you ask, and it is the subject of section three.

Multicall3, Permit2, the CREATE2 deterministic deployer and Safe v1.4.1 are all present at their canonical addresses. The MetaMask, Alchemy and Uniswap EIP-7702 delegator contracts hold code too; the docs put the EVM at the Osaka fork, which is what makes delegating to them possible.

One Dollar, Two Decimals

USDC is the native coin. That sentence hides a detail every integrator will trip on once: the node counts it in 18 decimals, and the ERC-20 contract that represents the same coin counts it in 6. Same balance, two scales, a factor of a trillion apart.

POOL=0x8366a39cc670b4001a1121b8f6a443a643e40951   # Uniswap v4 PoolManager
USDC=0x3600000000000000000000000000000000000000   # the ERC-20 face of the native coin
BLOCK=0x14c2602                                    # pin both reads to one block

# The native balance, as the node counts it: 18 decimals
eth_getBalance($POOL, $BLOCK)
# -> 3,692,022,800,475,000,000,000  wei-equivalent
#    ÷ 1e12 = 3,692,022,800,475

# The ERC-20 balance, as the contract counts it: 6 decimals
eth_call({ to: $USDC, data: balanceOf($POOL) }, $BLOCK)
# -> 3,692,022,800,475
#    = $3,692,022.800475

# decimals() on the face -> 6 · symbol() -> "USDC" · name() -> "USDC"

At the same block the two numbers agree to the unit, so this is one balance with two interfaces, not a coin and a wrapper. The contract at 0x3600…0000 also emits Transfer events for native movements — four of them in the block I pinned — which is EIP-7708 in practice: a history indexer that reads native sends and those logs counts every transfer twice.

nativeCurrency.decimals: 18 is chain precision, not display precision. A wallet that adds the network from the standard parameters and trusts the decimals field will show a one-dollar balance as 0.000000000001. Arc's own wallet guide says to divide by 10¹², label the result USDC rather than ETH, and merge the native and ERC-20 rows into one — and the network-parameters page warns that a wallet without custom-gas-token support "may display balances as ETH".

One more read on that contract, because it is where Circle's controls would live if they lived in code. The ERC-20 face is 1,798 bytes, is not a proxy (the EIP-1967 implementation slot is empty), and its bytecode contains none of the selectors the mainnet USDC contract is known for — blacklist, isBlacklisted, pause, mint. That does not mean there is no freeze on Arc; it means the freeze, if it exists, is not in this contract. The honest reading stops there.

A Fee Floor, Not a Fee Market

eth_feeHistory over the last blocks returns the same base fee six times: 20 gwei, with utilisation between three and eleven percent. Arc's fee model is EIP-1559 with a moving average on top and a hard floor — 20 gwei in the docs, and 20 gwei in every block I sampled — so under normal load the base fee never moves. It sits on the floor. The node's suggested price was 22.0 gwei, of which 2.0 was tip.

Now do the unit conversion nobody does. The native coin is a dollar, and one gwei is 10⁻⁹ of it. So a gas unit costs two hundredths of a millionth of a cent, and at the 22.0 gwei the node suggested that morning:

Plain transfer · 21,000 gas — $0.00046

ERC-20 transfer · ~65,000 gas — $0.0014

Uniswap v4 fee claim · ~250,000 gas — $0.0055

Token deployment · ~2,000,000 gas — $0.044

Two things follow. First, a fee quote on this chain is a solved problem: the price is pinned, denominated in dollars, and needs no oracle — the number on screen is the number, every time. Second, gas cannot be anyone's business model here, including the chain's. At 1.5 million transactions a day and a typical cost under a tenth of a cent, the network's whole daily gas take is on the order of a thousand dollars (an estimate from those two figures, not a measurement). Whatever pays for twelve SOC 2 validators, it is not the fee floor.

The Wrapped Token That Only Reverts

Every Uniswap deployment carries a WETH9 address — the wrapped native coin the routers and position managers use when a pool holds ETH. Ask Arc's v4 PositionManager for it and you get an answer. Ask the answer anything and you get a revert:

PM=0x6049c9a0e26405c0985f9e3685c87d0ae917f82b     # Uniswap v4 PositionManager

eth_call({ to: PM, data: WETH9() })
# -> 0x8bceaa40b9acdfaedf85adf4ff01f5ad6517937f

eth_getCode(0x8bceaa40…937f)
# -> 53 bytes:
#    6080604052 348015600e575f5ffd5b50   ; standard prologue, no value
#    60405163 ea3559ef 60e01b 8152 6004 01 ; PUSH4 0xea3559ef … REVERT
#    …fd

eth_call({ to: 0x8bceaa40…937f, data: name() })      -> revert 0xea3559ef
eth_call({ to: 0x8bceaa40…937f, data: symbol() })    -> revert 0xea3559ef
eth_call({ to: 0x8bceaa40…937f, data: decimals() })  -> revert 0xea3559ef

That is not a squatter and not a bug. Uniswap's own deployment table for chain 5042 lists the address as "Unsupported Protocol (WETH9)": a 53-byte contract whose only behaviour is to revert with one custom error, deployed on purpose so that every code path expecting a wrapper fails loudly instead of silently. On Arc there is nothing to wrap — the native coin already has an ERC-20 face at 0x3600…0000. Any "wrap" or "unwrap" button, any router path that hops through WETH, any collect-and-compound flow that calls deposit() — all of it dies here, and it dies with a selector you can grep for.

The squatter is elsewhere, and it is the same one I found on Robinhood Chain in August. Uniswap v3's canonical mainnet addresses — 0x1F98…F984 for the factory, 0xC364…FE88 for the position manager — both hold a 2,747-byte contract on Arc that is not Uniswap v3. feeAmountTickSpacing(3000) returns nothing. The real v3 factory is at 0xf0db…3918 and answers 60, and its position manager at 0x3965…1377 points back to it. A tool that copies v3 addresses from a table it trusts would be reading a stranger's contract and calling it Uniswap. Read the code, make one live call, then believe the address.

Who Got There First

Arc was built, in Circle's words, for payments, FX, tokenised assets and institutional markets. The explorer's daily transaction chart says who actually showed up:

12–15 September, private mainnet: 126K · 131K · 407K · 456K transactions a day.
16 September, public launch: 7,763,670 transactions. Reporters counted 97,025 new tokens that day, more than 83,000 of them through one launchpad, and $410.8M of trading with about 82% from memecoin launchpads.
17 · 18 · 19 September: 5,472,100 · 2,611,050 · 1,551,810. Down 80% from the launch day in three days.

The DEX numbers from DefiLlama on 20 September: $52.8M in the last day, of which Uniswap v4 is $36.8M and v3 $14.4M — 97% between them. The v4 PositionManager's nextTokenId reads 222,177, so 222,176 v4 positions have been minted so far; the v3 manager's totalSupply is 36,325. Total protocol fees on the chain, all sources, were $375K in the same day. For scale, Robinhood Chain booked roughly forty-five times that on the day I measured it in early September.

The explorer counts 1,316,279 contracts on the chain and 19,380 verified ones — one in sixty-eight. And the trending list on the pool indexer, the morning I looked, had this in it:

USDC / USDC 1% — $1.16M traded in 24 hours, $386K in reserve, on a launchpad's own exchange. A token that calls itself USDC, paired against the real one. On Arc exactly one address is USDC: 0x3600…0000. EURC is one address. USYC is one address. A ticker is a string anyone can type into a constructor; the address is the only thing a copy cannot have. GoPlus was already warning about clones of two of the chain's biggest launch tokens by the second day.

I do not read the decay as a verdict. A launch-day spike that falls 80% is the shape of every launch; the question is where the line flattens, and four days do not answer it. What the numbers do say is that the population using Arc today is the one that uses every new EVM chain in its first week — launching, trading and copying tokens — and it arrived before the institutional use the chain was named for.

A Token That Exists and Is Not Launched, and Who Runs the Chain

On launch day Circle announced a genesis mint of 10 billion ARC tokens — and, in the same breath, that they are not available to the public and that the mint is "a technical milestone, not a commitment to launch". The whitepaper post on arc.io still carries the line that any token "is merely exploratory". Gas stays in USDC. A move to proof of stake, where the token would have a job, is described as something Circle is exploring for 2027.

So: the token exists on-chain and has no holders you can become. Anything trading under that ticker today, and anything offering an "ARC airdrop" or an "ARC claim", is not Circle's. Search interest in "arc token" hit its peak on launch day, which is exactly the audience those pages are built for.

Who runs the chain is disclosed more plainly than most. Twelve named institutions run proof of authority; a block is final when more than two thirds of them pre-commit to it; Circle chose them. Arc's security page says that "validator-layer sanctions controls are part of Arc's network operating model" and names a third-party monitoring provider. On Robinhood Chain I could count how often the filtering switch had been used, because Nitro exposes the filterer as a precompile with a public nonce. Arc is not Nitro and has no such artefact, so whether the switch has been thrown is not something the chain will tell you. I record that as an unknown, not as an absence.

What to Carry Out of This

Decimals come from the asset, never from the chain. Read decimals() on the ERC-20 face and treat native units as 18; divide by 10¹² to show dollars. The two are one balance.
There is no WETH. The address Uniswap points at reverts by design. Delete the wrap path; it has nothing to wrap.
Canonical addresses are not addresses. The v3 factory is not where the tables say. Check code size and make one call the real contract must answer before you label anything.
The name is not the coin. One address is USDC. Anything else wearing the ticker is a copy, and the first week's trending list already had one.

Free tool

Is that token what it says it is?

The token audit reads a contract's owner levers, hidden spenders, holders and liquidity straight from the chain — public data, no wallet connect, nothing to sign — and on Robinhood Chain checks a stock token against its issuer's own registry, so a copy is named as a copy. Solana and Robinhood Chain today.

Run a token audit

Read the Source Yourself

Every on-chain figure above came from the public endpoint https://rpc.mainnet.arc.io, the chain's Blockscout explorer and its /api/v2/stats, and DefiLlama, all read on 20 September 2026. Reference: Arc network parameters, the fee model, Arc's wallet integration guide, Uniswap's deployment table for chain 5042, Arc's security page, and Circle's launch release. The launch-day token and volume counts are reporters' figures (BeInCrypto, CryptoRank, 17 September), not mine; the GoPlus warning was carried by KuCoin's news feed the same day. Re-run every call before relying on any of it — this chain is four days old.

xroot.dev is not affiliated with, endorsed by, or sponsored by Circle Internet Group, Inc. "Arc", "USDC" and "EURC" are used here only to name the public blockchain and the assets this article examines. Nothing here is financial advice.

After the Rent Cut, Your Old Solana Accounts Are Over-Funded

Suliman Mokhtar — Fri, 18 Sep 2026 15:33:21 +0000

Originally published on xroot.dev.

The rent-cut post explained the economics: Solana is cutting the price of account storage by 90% in five feature-gated steps, and accounts funded at the old price keep every lamport they were funded with. The follow-up question arrived within a day of publishing it: if my account holds more rent than it now needs, can I get the difference back without closing it?

For four kinds of account, yes. Here is the arithmetic per type, the instruction that withdraws it, the switch that could put the price back up, and a detail from last week that will trip anyone tracking this by feature ID.

The Formula, and Where the Ladder Stands

Rent on Solana is now a single multiplication: (128 + data length) × lamports per byte. The 128 is a fixed per-account overhead; the two-year multiplier that used to complicate this was folded into the byte price earlier this year.

The byte price is stepping down through five gates:

The ladder, lamports per byte — 6,960 → 6,333 → 5,080 → 2,575 → 1,322 → 696

Mainnet on 17 September 2026 — step two — 5,080 since 11 September, a 27% cut

Surplus against the original price — (128 + length) × 1,880 lamports

Surplus at the final step — (128 + length) × 6,264 lamports

Three steps remain, expected with Agave 4.4. At the end, the surplus is nine-tenths of what was originally deposited.

Four Account Types, Four Numbers

Per account, today against the original price, and at the last step:

Nonce account · 80 bytes — ~0.00039 SOL now · ~0.0013 SOL at the end

Stake account · 200 bytes — ~0.00062 SOL now · ~0.0021 SOL at the end

Vote account · 3,762 bytes — ~0.0073 SOL now · ~0.024 SOL at the end

Token account · 165 bytes — ~0.00055 SOL now · ~0.0018 SOL at the end

Individually small. Multiplied by the number of accounts a wallet, a treasury or a validator operator controls, not small. A validator with a hundred nonce accounts for a signing pipeline, a distribution program that created ten thousand stake accounts, a market maker with a thousand token accounts: the surplus is a line item, and it grows at every step.

Worth knowing: the surplus only exists for accounts created before a step. Everything created after the final step holds the final price and has nothing to reclaim. The stock of over-funded accounts is fixed the day the ladder finishes, and it only shrinks as people notice.

The Instruction Per Type, and Who Can Sign It

Each program guards its own accounts, so the withdrawal is four different instructions with one rule in common: the account keeps at least the current rent-exempt minimum, and the signer is the account's own authority.

Nonce accounts: WithdrawNonceAccount, signed by the nonce authority, any amount above the rent-exempt minimum.
Stake accounts: the stake program's Withdraw, signed by the withdraw authority. On a delegated account only the portion above the delegated stake plus the reserve is withdrawable; on a deactivated one, anything above the reserve.
Vote accounts: the vote program's Withdraw, signed by the authorized withdrawer, keeping the rent-exempt minimum plus pending delegator rewards — the delegators' accrued share is in the balance but is not the operator's to take. Once Alpenglow activates — the gate had not activated on mainnet as of 17 September 2026 — the account also has to keep one epoch's admission ticket: 1.2 SOL at today's 300 ms slots, 1.0 SOL from epoch 1037, when slots go to 250 ms.
Token accounts: WithdrawExcessLamports, signed by the account's owner, an instruction both token programs carry precisely for this case. The account stays open and usable.

Nothing above closes anything, and nothing requires a third party to hold a key. The live tool on the app builds the batch for the accounts a connected wallet controls, and the wallet signs it.

The Switch That Can Put the Price Back Up

The ladder has a reverse gear. A feature named set_lamports_per_byte_to_6960 restores the original price. It had not activated on mainnet as of 17 September 2026, and the validator's ordering rule gives it priority: if a rollback and a cut activate in the same epoch, the rollback wins.

The ordering rule for the cuts themselves is also worth knowing: if several cut gates activate in one epoch, the lowest price wins; if they activate out of order, the most recently activated price wins. The ladder is designed to descend, but the code allows for the messier cases.

For anyone timing account creation to a cheaper step, the rollback is the risk. A batch deferred to "after the next cut" can land after a rollback instead. Watch both directions.

The IDs Changed Recently

Feature gates are identified by public keys, and those keys are not stable until a feature activates. On 11 September 2026 the SIMD-0438 rollback gate and the remaining SIMD-0437 cut gates were re-keyed — assigned new feature IDs — in the validator source. Any dashboard, script or bookmark that tracked the old IDs is now watching accounts that will never activate.

This is normal for unactivated features, and it is the reason the tracker on this site reads the feature names from the current validator build rather than from a list someone typed in months ago. If you track gates yourself, re-read the IDs from the release you are running, every release.

Rent Surplus: Questions People Actually Ask

Can I get rent back from a Solana account without closing it?

Yes, for account types whose program allows withdrawing lamports above the rent-exempt minimum: nonce, stake and vote accounts, and token accounts via WithdrawExcessLamports. The account stays open.

How much rent surplus does a Solana account hold after the cut?

(128 + data length) × (old price − new price) lamports. At the 5,080 per byte live since 11 September 2026, against the original 6,960, a token account holds about 0.00055 SOL of surplus; at the final step, about 0.0018 SOL.

Can the Solana rent cut be reversed?

Yes. A rollback gate — not active on mainnet as of 17 September 2026 — restores 6,960 lamports per byte and overrides any cut that activates in the same epoch. Deferring account creation to a cheaper step carries that risk.

Why did the SIMD-0437 feature IDs change?

Unactivated feature IDs are not stable. The remaining cut gates and the rollback gate were re-keyed on 11 September 2026; anything tracking the old IDs is watching dead accounts.

What to Do, in Order

List the nonce, stake, vote and token accounts your keys control, with their creation-era balances.
Withdraw the surplus on the ones you keep, with the instruction for that type, leaving the current minimum and, for vote accounts, the delegators' share.
Close the ones you do not need at all; closing returns the full original deposit, which is the larger number.
Then wait for the next step and do it again. Three steps remain, and each one makes every account you funded at the old price a little more over-funded than it was.

— Without Closing a Single Account —

Take back the surplus and keep the account.

The rent-refund tool reads the accounts a connected wallet controls, computes the surplus per type against the live byte price, and builds the withdrawal batch for your wallet to sign. Nothing is closed and no key leaves your side.

Take Back the Rent Surplus ↗Check which step is live

While you are auditing stake accounts, the minimum delegation has been 1 SOL since 18 June 2026 — the same accounts. A sub-1-SOL delegation still earns, but it can no longer be split or moved, only merged, deactivated or withdrawn.

Rules and ordering read from the Agave validator source at commit beee69b958: runtime/src/bank.rs, feature-set/src/lib.rs and the rent collector. The figures assume the 5,080 lamports-per-byte rate live on mainnet on 17 September 2026 — re-check the live rate and the live step before acting on a number here.