DEV Community: Suliman Mokhtar

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.

SPL Token Was Replaced In Place: p-token, Explained

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

Originally published on xroot.dev.

Every token you have ever held on Solana that is not Token-2022 lives under one program: the classic Tokenkeg… address. It is the most-called program on the chain, it has not materially changed in years, and most people assume it never will, because changing it would mean changing an address that half the ecosystem has hard-coded.

SIMD-0266 did not change the address. It changed what runs behind it. On 13 May 2026, at the start of epoch 971, a feature gate swapped the program's bytecode for a new implementation called p-token, moved the program from the original loader to the upgradeable loader, and set its upgrade authority to nothing. Same ID, same instructions, same accounts, faster code, and no one who can change it again.

This post is what the swap actually does, from the validator source, and what it changes for people who never write a line of code.

What a Feature Gate Can Do to a Program

Solana's runtime can replace a builtin or a program's bytecode at a feature activation. The mechanism is the same one that moved the stake, config, address-lookup-table and feature-gate programs from native code to on-chain bytecode over the past year. The validator carries the new binary, the feature account activates at an epoch boundary after 95% of stake adopts it, and at that boundary the runtime writes the new program data under the old address.

For SPL Token the feature is replace_spl_token_with_p_token. The source names both sides of the swap: the target is the classic token program ID, and the source is a buffer account that already holds the p-token binary on chain. The runtime copies the buffer into a program-data account, points the program at it, and records the upgrade authority as none.

Worth knowing: agave's own bundled copy of the classic token program is already p-token — the file is spl_p_token-1.0.0.so, about 109 KB. Every local test validator and every fresh genesis has been running the new implementation for a while. Mainnet followed on 13 May 2026, at the start of epoch 971 (slot 419,472,000).

What p-token Is

p-token is a reimplementation of the SPL Token program in Pinocchio, a framework for writing Solana programs with no allocator and minimal runtime overhead. The instruction set is the original one: the same discriminators, the same account layouts, the same errors, so a wallet, an explorer or a DEX sees no difference in what it sends or reads.

What changes is what each instruction costs to execute. The original program was written against the standard Rust framework and pays its overheads on every call. p-token strips them. The proposal's whole justification is compute: the same transfer, the same approve, the same close, for fewer compute units.

The exact per-instruction numbers belong in a benchmark, not a paragraph, and the buffer is on chain for anyone to measure against. What the swap guarantees is the direction.

Why Cheaper Compute Is a Fee Story

A leader ranks transactions by reward divided by the block space they request. If the token transfers inside your swap cost fewer compute units, and your compute-unit limit is set from a simulation, the limit falls, the block-space cost falls, and your rank rises at the same fee. Wallets that hard-code a compute limit for token transfers will keep paying for the old number until they re-measure.

The other side of the same coin: the per-account limit on how much of a block one account can consume — 30 million units at today's 300 ms slots, and 25 million from epoch 1037, when 250 ms slots start — goes further when each transfer costs less. A hot token account jams later.

None of this needs action from a holder. It needs re-measurement from anyone who sets compute limits by hand.

The Part Nobody Will Be Able to Undo

After the migration the program's upgrade authority is set to none. The validator source is explicit about why: the original program lived under a loader that has no concept of an upgrade authority, so the migrated program is given the closest equivalent, which is "nobody".

p-token is the final form of the classic token program unless another feature gate replaces it the same way. There is no key that can push a patch. If a bug is found, the fix is a new feature gate, a new buffer, and another 95%-of-stake activation. This is the same immutability the ecosystem asked for and the same immutability it will have to live with.

It is worth reading next to the rule that stops old programs being frozen at all: the network is making immutability harder to reach by accident and permanent when it arrives.

What Could Break, and for Whom

The instruction ABI does not change, so the expected answer is "nothing", and the honest answer is "nothing anyone has found since mainnet activated it on 13 May 2026". Three places deserve a look regardless:

Programs that call the token program by CPI and set a tight compute budget for the callee. Cheaper is fine; a budget computed from the old costs will simply leave headroom.
Anything that identifies the token program by inspecting its loader or its program-data account. After the swap it is a loader-v3 program with a program-data account and no authority. Tooling that assumed "loader v2, no program-data" will need updating.
Indexers that key on the program's executable bytes or hash for any reason. The bytes change; the address does not.

p-token: Questions People Actually Ask

Is the SPL Token program address changing?

No. The classic token program ID stays the same. SIMD-0266 replaced the bytecode behind it with p-token via a feature gate that activated on 13 May 2026, and the instruction set and account layouts are unchanged.

Will my tokens or token accounts change?

No. Balances, delegates and authorities are data in your accounts, not in the program. The swap changes how instructions execute, not what they mean.

Can the token program be upgraded after p-token?

Not by a key. The migrated program gets no upgrade authority. Any future change would need another feature gate with another 95%-of-stake activation.

Why does p-token lower fees?

Token instructions cost fewer compute units, so a simulated compute limit drops, the block-space cost drops, and the leader ranks the transaction higher for the same fee.

What to Do, by Who You Are

Holding tokens: nothing. Your balances, accounts and approvals are unaffected, and the program that guards them cannot be changed by anyone afterwards.
Sending transactions with hand-set compute limits: re-simulate now and lower them. The saving is real and it is yours.
Building on the token program: run your test suite against a local validator now — it already runs p-token — and against the on-chain buffer if you want the exact mainnet bytes.

— Already Live —

The most-called program on Solana, replaced without a single address changing.

The gate is one feature account. The upgrades tracker reads it from the chain every minute and shows the state per cluster — which is also how you know when to re-measure your compute limits.

Open the Upgrades Tracker ↗

Migration details read from the Agave validator source at commit beee69b958: feature-set/src/lib.rs and program-binaries/src/lib.rs. Per-instruction compute figures are deliberately not quoted here — measure them against the on-chain buffer rather than trusting a number in a blog post.

Solana’s Minimum Stake Delegation Is Now 1 SOL

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

Originally published on xroot.dev.

For as long as Solana has had staking, the minimum you could delegate has been one lamport — a billionth of a SOL. It is why the network has tens of thousands of stake accounts holding a few thousandths of a SOL: airdropped stake, split leftovers, test delegations that were never cleaned up. Each one is a full account the runtime tracks and rewards, and each one costs more to process than it earns.

That ended on 18 June 2026, when version 5 of the stake program activated on mainnet. The minimum delegation is now 1 SOL. And the reason that change can ship as a program upgrade rather than a validator release is the quieter story underneath it: the stake program is no longer native code inside the validator. It is on-chain bytecode, and it is upgradeable.

The Stake Program Is Now a Program

For most of Solana's life the stake program was a builtin: Rust compiled into the validator binary, changed only when validators upgraded. Over the past year the core programs were migrated one by one to Core BPF — real on-chain programs under the upgradeable loader — and the stake program's migration is complete. The validator ships version 5.1.0 of it as a 212 KB binary, and every feature ID in the migration table is now "none", which is the source's way of saying the migration is live on every cluster.

Changes to staking rules are now program upgrades gated by features, not validator releases. SIMD-0490 is the first substantive one.

The Rule

The runtime's minimum-delegation function has exactly two branches:

v5 stake program gate active — 1 SOL

Otherwise — 1 lamport

Minimum balance of a delegated account — rent-exempt reserve + minimum delegation

A stake account is 200 bytes; at today's rent rate of 5,080 lamports per byte, in force since 11 September 2026, its reserve is 0.00166624 SOL. So a delegated stake account needs a shade over 1.0017 SOL in it to be valid.

What the rule does to delegations that already exist below the minimum, read from the v5 program source: nothing. The minimum is enforced when stake is delegated, split or moved. A new delegation below 1 SOL is rejected; a split must leave both sides at or above the minimum unless the whole stake moves; a move-stake must leave both sides at or above it. Deactivate, withdraw and merge carry no minimum check, and the proposal says merging is always allowed even when the result stays below 1 SOL. An existing sub-1-SOL delegation keeps earning. It cannot be split or moved, only merged, deactivated or withdrawn.

Who Has Sub-1-SOL Stake Without Knowing

More people than you would think.

Anyone who received staked SOL through a distribution program. Grants, airdrops and vesting schemes commonly delivered stake accounts in small tranches; the leftovers are often below 1 SOL.
Anyone who split a stake account to move part of it. Splits leave a remainder, and remainders are forgotten.
Anyone who tested staking once with a small amount and moved on.

Liquid-staking users generally do not have this problem; the pool's accounts are large. Direct stakers do.

The Three Instructions That Fix It

The stake program has always had what is needed; the gate just gives a reason to use it.

Merge. Two stake accounts delegated to the same validator, with compatible state, can be merged into one. Small tranches on the same validator become one account above the minimum.
Withdraw. A deactivated stake account, or the inactive portion of an active one, can be withdrawn to your wallet. Dust that is not worth merging is worth withdrawing, and the account's rent comes back with it.
Deactivate delinquent. A separate case: stake delegated to a validator that has stopped voting for a long time can be deactivated by anyone — the instruction is permissionless. Stake stuck on a dead validator is not lost; it is waiting for someone to send one instruction.

Every one of these is a transaction your own wallet signs with the stake or withdraw authority. No custody, no third party.

What the Rest of the Ecosystem Has to Change

Stake pools, dashboards and any tool that creates stake accounts programmatically need to enforce the new minimum at creation time, or their users will get a confusing rejection from the program. Explorers that display "stake activation" for tiny accounts will need to decide what to show for accounts below the floor. And the getStakeMinimumDelegation RPC call, which many tools ignore because the answer used to be 1 lamport, now returns 1 SOL.

The Alpenglow admission changes ride a separate gate, and that gate had not activated on mainnet as of 17 September 2026. The stake-account side of staking has already changed; the vote-account side has not.

Minimum Delegation: Questions People Actually Ask

What is the minimum stake delegation on Solana?

One SOL. The v5 stake program gate activated on mainnet on 18 June 2026, at epoch 989; before that it was one lamport. A delegated stake account must hold the rent-exempt reserve plus that minimum.

Why can Solana staking rules change without a validator upgrade?

The stake program is now Core BPF: on-chain, upgradeable bytecode under the upgradeable loader. Rule changes arrive as feature-gated program upgrades rather than validator releases.

What happens to stake accounts below 1 SOL?

New delegations below the minimum are rejected, and a split or a move must leave both sides at or above it. Delegations that were already below 1 SOL are untouched: they keep earning, and you can still merge, deactivate or withdraw them.

Can I free stake stuck on a validator that stopped voting?

Yes. The deactivate-delinquent instruction can be sent by anyone against stake delegated to a long-delinquent validator; the stake then cools down and can be withdrawn.

What to Do This Month

List every stake account your wallet controls, with its delegated amount. Anything under 1 SOL is now fixed in shape: it earns, but it cannot be split or moved.
For each one: merge it into a larger account on the same validator, or deactivate and withdraw it. Both remain available; the rule does not touch existing delegations.
While you are in there, take the rent surplus those accounts are holding. A stake account funded before the 11 September 2026 cut to 5,080 lamports per byte is over-funded whether you merge it or not.

— One Feature Account Sets the Floor —

The minimum changed at an epoch boundary, not on an announcement.

The v5 stake-program gate activated once 95% of stake ran software that supported it, which happened at epoch 989 on 18 June 2026. The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state on each cluster.

Open the Upgrades Tracker ↗

Constants read from the Agave validator source at commit beee69b958: runtime/src/stake_utils.rs, program-binaries/src/lib.rs and feature-set/src/lib.rs. The treatment of existing sub-minimum delegations was verified on 17 September 2026 against the SIMD-0490 text and the v5 program source (solana-program/stake: process_delegate, process_split, process_move_stake). The v5 gate activated on mainnet at slot 427,248,000 (epoch 989, 18 June 2026) and v5.1 at slot 443,232,000 (epoch 1026, 31 August 2026).

Sent SOL to an Address That Doesn’t Exist Yet? SIMD-0312 Fix

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

Originally published on xroot.dev.

It is the most common support ticket in crypto, on every chain, and on Solana it has a specific mechanical cause. Someone is given an address — a deposit address, a program-derived address, an account a dApp is about to create — and sends SOL to it before the account exists. The SOL arrives. The address now has a balance and no account behind it. And when the program that was supposed to create the account finally tries, the system program refuses, because you cannot create something that already holds lamports.

The funds are not lost. But getting them into a working account has required a workaround that most programs did not implement, and most users could not perform. SIMD-0312 replaces the workaround with one instruction.

Why Creating a Funded Address Failed

Solana's CreateAccount instruction does three things at once: allocates space, assigns an owner program, and transfers the initial lamports from a funder. It was written with a strict precondition: the target must be empty — zero lamports, zero data, owned by the system program. A target with a non-zero balance fails the check, and the instruction errors.

The precondition exists for a reason. It stops one party from pre-loading an account another party expects to initialise, and it makes the "fresh account" invariant something programs can rely on. But it also means the ordinary human act of sending money to an address slightly too early bricks the creation path.

The workaround was a three-instruction dance: Allocate space, Assign the owner, then Transfer the top-up. It works, it is fiddly, and it requires the creating program to anticipate the case. Most did not.

What SIMD-0312 Adds

A new system instruction, CreateAccountAllowPrefund, that does what its name says: creates the account whether or not the address already holds lamports. If the address has been prefunded, the existing balance counts toward the requested amount; the funder tops up only the difference, if any.

Two details from the implementation that anyone building on it needs:

Account order is reversed — new account = index 0, funder = index 1

When requested lamports = 0 — only one account is required: the target

The reversal matters because it is the opposite of CreateAccount, and a transposed pair of accounts is the kind of mistake that compiles, passes a happy-path test, and fails on the first prefunded address in production. And when the address is already fully funded there is no funder to reference, because nothing is being transferred.

It is gated by a feature, create_account_allow_prefund, which activated on mainnet on 29 May 2026 (epoch 979, slot 422,928,004).

Who This Fixes, and Who It Does Not Fix By Itself

The instruction is a tool for programs and wallets, not a button a user presses. Nothing changes for a stranded deposit until the software that owns the address adopts it. So:

Deposit systems — exchanges, payment processors, anything that hands out addresses before creating accounts — can now create the account after the money arrives, in one instruction, with no special path. The pattern "give the customer an address, let them fund it, create-and-claim later" becomes cheap and safe.
Program-derived addresses — vaults, escrows, per-user state accounts — can be funded by a user before the program initialises them, and the program's init can succeed anyway.
Users with SOL sitting at an uncreated address are still dependent on whoever controls the creation path. The difference is that the fix on that side is now trivial, which is the strongest argument for it happening.

The Invariant That Changes

The "fresh account" guarantee weakens slightly. A program that uses CreateAccountAllowPrefund must be written to tolerate a target with a pre-existing balance — which is the whole point — and must not assume the lamports it sees were put there by its funder. For most programs that is harmless. For a program whose logic depends on the exact initial balance, it is a case to handle deliberately: read the balance after creation, not the amount you asked for.

The classic CreateAccount keeps its strict behaviour. Programs that want the old invariant keep using it.

What It Does Not Do

It does not recover SOL sent to a wrong address. If the address was mistyped, or belongs to someone else, or is an address nobody controls, the instruction is irrelevant; there is no account to create on your behalf.

It does not apply to token accounts. Associated token accounts have had their own tolerant creation path for a long time; this is about system-owned accounts and program-derived ones.

And it does not fire on its own. The gate has been active on mainnet since 29 May 2026, but until the program in question uses the instruction, a prefunded address is exactly as stuck as it was before.

Prefunded Addresses: Questions People Actually Ask

Why does Solana fail to create an account that already has SOL?

The classic CreateAccount instruction requires an empty target: zero lamports, zero data, system-owned. A balance sent early fails that check and the creation errors.

What does SIMD-0312 change?

It adds CreateAccountAllowPrefund, a system instruction that creates the account and counts any existing balance toward the requested amount, so the funder only tops up the difference.

Can I recover SOL I sent to an uncreated Solana address?

The SOL is at the address. Whoever controls creation of that address can now create the account in one instruction; if it is a seed-derived address under your own key, you can allocate and assign it yourself.

Does SIMD-0312 apply to token accounts?

No. Associated token accounts already tolerate prefunding through their own creation path. This instruction is for system-owned and program-derived accounts.

If You Have SOL at an Address That Does Not Exist

Find out who controls creation of that address. If it is a program, the fix is one instruction on their side, live on mainnet since 29 May 2026. If it is a seed-derived address under your own key, you can allocate and assign it yourself today, and the top-up is already there.

If you build software that hands out addresses: adopt the new instruction now; the gate has been live since 29 May 2026. The support tickets you stop receiving are the measure of the change.

— The Gate Is Live on Mainnet —

The instruction exists. The question is which cluster has it.

create_account_allow_prefund activated on mainnet at the epoch 979 boundary on 29 May 2026, after 95% of stake adopted it. The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state per cluster.

Open the Upgrades Tracker ↗

Two neighbours to this problem: SOL that vanishes en route rather than on arrival is a different failure with seven causes, and SOL sitting in accounts you already control is the rent surplus left by the rent cut.

Instruction behaviour read from the Agave validator source at commit beee69b958: programs/system/src/system_processor.rs and feature-set/src/lib.rs.

Token Balances That Change Without a Transaction on Solana

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

Originally published on xroot.dev.

You hold a token. You did not trade, transfer, stake or touch it. Your balance is different this morning than it was last night, and there is no transaction in your history to explain it.

On Solana that is not a hack and not a display bug. It is one of two Token-2022 extensions doing exactly what they were built for: making the number a wallet shows depend on time, not on transactions. The raw amount in your account never changed. The interpretation of it did. Here is what the node computes, where the number comes from, why every tax tool and most archives get it wrong, and how to read your own balance correctly.

Two Extensions, One Idea: The Display Is a Function of the Clock

Interest-bearing mints carry a rate, in basis points per year, and a timestamp. The raw token amount is fixed; the displayed amount is the raw amount compounded continuously at the rate since the mint's initialisation, with a separate average rate for periods before the last rate change. Nothing accrues on chain. The "interest" is a formula applied at display time.

Scaled-UI-amount mints carry a multiplier, and optionally a scheduled new multiplier with the timestamp at which it takes effect. The displayed amount is the raw amount times the multiplier in force now. A stock-split token, a rebasing wrapper, a share class with a periodic revaluation — all one multiplier field.

In both cases, the on-chain balance in your token account is a plain integer that only transactions change. The extension tells readers how to present it.

What the Node Actually Does When You Ask

When an RPC serves a parsed token account, a token supply, or a token account balance for one of these mints, it reads the extension config from the mint and evaluates it against the node's own clock — the bank's current unix timestamp. The same account, queried a minute apart, returns a different display amount. Queried from two nodes whose clocks differ by a slot — 300 ms at today's mainnet slot time, 250 ms from epoch 1037 — it can return two different amounts at the same moment.

The node also refuses to give you a floating-point shortcut. The parsed balance carries a uiAmount field that is a nullable number, and for interest-bearing and scaled mints it is null. The lossless fields are amount (the raw integer) and uiAmountString (the server's decimal rendering). Any code that does arithmetic on uiAmount has a null at exactly the mints where the number matters most; any code that recomputes the string from amount and decimals locally gets the plain, un-scaled value and is simply wrong.

Worth knowing: the interest rate is a signed 16-bit integer. Negative rates are representable. A mint can be configured so that the displayed balance of every holder declines over time, with no transfer, no burn and no event in anyone's history. It is a legitimate instrument for some products and an unlabelled drain in others.

Why Archives and Tax Tools Get It Wrong

The historical record compounds the problem.

The archive that backs long-tail transaction history stores token balances by regenerating the decimal string from amount and decimals on read, and stores a null uiAmount as 0.0. Every product that reconstructs a wallet's history from the archive sees the un-scaled amount for these mints, and sees zero where the node said "not representable". Cost-basis tools, portfolio trackers and explorers that lean on archived history will present a balance for these tokens that never existed.

The live node gets it right because it evaluates the extension against the clock. The archive cannot, because it stored the answer to a question whose answer changes with time.

What This Means for Three Kinds of People

Holders. Your balance did not move; its label did. If the token is interest-bearing, the rate is on the mint and you can read it. If it is scaled, the multiplier and any scheduled change are on the mint too — including a future multiplier with the timestamp it takes effect, which is the closest thing Solana has to a pre-announced rebase.
Traders. Price a position off amount and the current multiplier or rate, never off a cached display amount. A quote built on a stale display is a quote for the wrong quantity.
Anyone doing tax or accounting. Every "balance changed" moment for these mints is a valuation change, not a transaction, and the archive-derived history you export will not show it. The raw amount and the extension config at each date are the only honest inputs.

How to Read the Mint Yourself

Fetch the mint account with parsed encoding. In its extensions you will find either the interest-bearing config — current rate, pre-update average rate, initialisation and last-update timestamps — or the scaled-UI config — current multiplier, new multiplier, and the effective timestamp of the new one. Those fields, plus your raw amount, produce your display balance at any moment you choose, on any machine.

If the parsed mint shows an extension the decoder cannot name, your reader is older than the mint; update it before trusting anything it displays.

Time-Varying Balances: Questions People Actually Ask

Why did my Solana token balance change without a transaction?

The mint is interest-bearing or uses a scaled UI amount. Your raw balance is unchanged; the displayed amount is computed from a rate or multiplier against the current time.

Why does uiAmount come back null for some Solana tokens?

The node refuses to give a floating-point value for mints whose display depends on time. Use amount (the raw integer) and uiAmountString (the server’s rendering) instead.

Can an interest-bearing token have a negative rate?

Yes. The rate is a signed 16-bit value, so the displayed balance of every holder can decline over time with no transfer or burn in anyone’s history.

Why does my portfolio tracker show the wrong balance for these tokens?

Archived history regenerates the display from the raw amount and decimals, and stores a null display as zero. Only a live node evaluating the extension against the clock returns the right number.

The One Habit That Avoids Every Error Above

Treat amount as the balance and everything else as presentation. The raw integer is what you own; the rate or multiplier is how the issuer has asked it to be shown today. Read both, compute the display when you need it, and never store the display as if it were a fact about the account.

— The Rate Is On the Mint —

Read the extension before you price the position.

The token audit reads a mint's extensions and authorities straight from the chain — including the interest rate or multiplier that decides what your displayed balance will be tomorrow, and whether it can go down.

Audit a Token ↗

Another Token-2022 capability hides the amount entirely rather than restating it — confidential transfers — and it has its own rules about what a reader can and cannot see.

RPC behaviour read from the Agave validator source at commit beee69b958: rpc/src/parsed_token_accounts.rs, account-decoder/src/parse_token_extension.rs and the archive's stored-token-amount type in storage-proto. Field names move between RPC versions — check the current docs before writing against them.

Token-2022’s New Extensions: Pausable and Permissioned Burn

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

Originally published on xroot.dev.

The post on permissioned tokens explained Token ACL: an allowlist that is a compliance feature when a regulated issuer runs it and a honeypot when an anonymous deployer does. The same year that program shipped, Token-2022 gained two extensions with the same double edge. Pausable lets an authority halt every transfer, mint and burn on a mint. Permissioned Burn puts a gate on who may destroy tokens.

Both are legitimate, both are on mainnet, and both appear in the validator's own account decoder — which is how you can tell whether the RPC you are reading even knows they exist. Here is what each one does, why regulated issuers asked for them, and the three questions that separate a compliance control from a trap.

Pausable: One Authority Stops the Mint

The Pausable extension adds a pause authority and a paused flag to a mint. When paused, the token program rejects transfers, mints and burns on that mint. Account creation and closing still work; balances do not move.

Why an issuer wants it: an exchange-listed stablecoin with a court order, a fund token during a redemption freeze, a security token under a trading halt. Every one of those is a legal requirement in the issuer's jurisdiction, and before the extension they were implemented with freeze authority applied account by account — slow, leaky and impossible to reverse cleanly. Pause is the same power, applied once, reversed once.

Why a buyer fears it: paused is "you cannot sell", and there is no difference at the program level between a regulated halt and a rug pull. The mechanism is identical. The difference is entirely in who holds the authority and whether that identity is accountable.

Permissioned Burn: The Gate on Destruction

Burning a token normally requires only the holder's signature. On a mint with the Permissioned Burn extension the token program rejects the standard burn instruction outright, and the extension's own burn instruction requires two signers: the holder (or their delegate) and the burn authority configured on the mint. If that authority is set to none, the program sends you back to the standard burn. Supply cannot be reduced by holders acting alone.

Why an issuer wants it: a tokenised asset whose supply is meant to track a real-world reserve cannot let holders destroy units at will — a burned token would strand its backing. Redemptions are meant to go through the issuer, who burns against a redemption. The extension makes the token's supply an issuer-controlled number in both directions.

Why it matters to a holder: less than Pausable. A permissioned burn does not stop you selling. It stops you burning, which most holders never do. But it is another authority on the mint, and every authority is a question.

Your RPC May Not Be Able to See Them

The validator's account decoder is what turns a mint's raw bytes into the JSON your wallet reads. It recognises both extensions by name. But it has a rule for extensions it does not know: it emits an entry called unparseable extension rather than failing. A wallet or explorer running against an older node, or using an older client library, will show a mint with an unnamed extension and no detail.

That is the tell to watch for. A mint whose decoded output contains an unparseable extension has a capability newer than the software reading it. Until the reader is updated, nobody using it can say what that capability is — and "I do not know what this authority does" is not a state to buy in.

The Three Questions That Separate Compliance From a Trap

The audit page on this site runs these for every mint it checks, and the logic is short enough to run by hand.

Who holds the authority? A pause or permissioned-burn authority held by a named issuer's known key, a multisig with published signers, or a program with published rules is a control. The same authority held by a fresh wallet with no history is a switch in an anonymous hand.
Does the token have an allowlist, and is it the same operator? A regulated token almost always carries Token ACL or a transfer hook with an on-chain policy alongside the pause authority. A pausable mint with no other compliance structure, launched on a memecoin launchpad, is the pattern to walk away from.
Can the authority be removed, and has the issuer said whether it will? Both extensions allow the authority to be set to none. An issuer that documents when and why it would pause, and what would make it renounce, is telling you the control is a control. Silence is an answer too.

Worth knowing: the platform behind this site will build permissioned tokens for issuers and will not build pause-then-rug configurations for anyone. That line is drawn on the same three questions; it is not a matter of technology.

For Issuers: The Honest Way to Hold These

If you are launching a token that legitimately needs a pause or a burn gate, the extensions are the right tool, and the way to avoid being mistaken for a rug is disclosure at the mint level, not in a chat pin:

Hold the authority in a multisig or a program, never a hot key.
Pair it with an allowlist or hook that encodes the policy, so the audit can see a compliance structure rather than a lone switch.
Publish the conditions under which you would pause, and the conditions under which the authority is renounced.

The audit reads on-chain state. Make the state tell the truth.

Pausable and Permissioned Burn: Questions People Actually Ask

What does the Token-2022 Pausable extension do?

A pause authority can halt every transfer, mint and burn on the mint at once, and unpause the same way. Balances do not move while paused; account creation and closing still work.

What does the Permissioned Burn extension do?

It moves burning behind a mint authority. On a mint with the extension the standard burn instruction is rejected, and the extension’s own burn needs two signers: the holder (or delegate) and the mint’s burn authority. Set the authority to none and ordinary burns work again. It is used where supply must track a real-world reserve and redemptions go through the issuer.

Why does my explorer show “unparseable extension” on a Solana mint?

The node or client library reading the mint is older than the extension. The mint has a capability the reader cannot name; update the reader before trusting the display.

Is a pausable token a scam?

Not by itself. The mechanism is the same for a regulated halt and a rug. What separates them is who holds the authority, whether it sits beside an allowlist or hook that encodes a policy, and whether the issuer has said when it would pause and renounce.

Before You Hold a Token With Either Extension

Read the mint, not the website. Both extensions appear in the decoded mint data if your reader is current; if it shows an unparseable extension, update the reader before you decide anything.

Then ask the three questions. A named authority with a policy is a token you may choose to hold under its rules. An anonymous authority with none is a token whose exit is not yours to control.

— The Mint Tells You, If You Read It —

Every authority on a mint is a question. The audit asks all of them.

The token audit reads a mint's extensions, authorities, supply and holder concentration straight from the chain — including the extensions an out-of-date explorer can only show you as "unparseable".

Audit a Token ↗Launch a permissioned token

A different pair of extensions makes a balance move with no transaction at all — interest-bearing and scaled-UI mints — and they are worth reading before you price anything issued under Token-2022.

Decoder behaviour read from the Agave validator source at commit beee69b958: account-decoder/src/parse_token_extension.rs. The semantics of Permissioned Burn described above — the standard burn rejected, the extension's own burn requiring both the holder and the mint's burn authority, and the fall back to the standard burn when that authority is none — were read from the Token-2022 program source and checked against mainnet on 17 September 2026.

SIMD-0500 Will Block Making Old Programs Immutable

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

Originally published on xroot.dev.

"Revoke the upgrade authority" is the last line of every honest token launch checklist and the first thing an auditor looks for. It is the on-chain promise that the code holding your money will never change. It has always been one instruction: set the program's upgrade authority to none, and the program is frozen forever.

For a class of programs, that instruction will fail once SIMD-0500 activates; as of 17 September 2026 the gate exists in the validator but has not activated on mainnet. SIMD-0500 will stop old bytecode formats from being deployed, and as part of that rule the loader will refuse to freeze a program whose bytecode is one of those old formats. A creator who built with a toolchain from a couple of years ago, never touched the program since, and leaves the renounce until after the gate activates cannot do it — until they rebuild, upgrade, and only then renounce.

Here is the rule from the loader source, who it catches, the other loader rule that changed alongside it, and what an audit should now show.

The Rule

Solana programs are compiled to SBPF, and SBPF has versions: v0, v1, v2, and the current v3. The feature disable_sbpf_v0_v1_v2_deployment, once it activates, makes the upgradeable loader reject any new deployment or upgrade whose ELF is not v3. Old programs keep executing; they just cannot be redeployed as they are.

The part that surprises people is in the authority path. When that gate is active and a SetAuthority instruction asks to set the authority to none, the loader reads the program's bytecode version first. If it is below v3, the instruction fails with an invalid-account-data error. The reasoning is consistent: a program that could never be redeployed in its current form must not be frozen in that form either, because freezing it would strand it on a format the network is retiring.

The immutability instruction becomes conditional on the bytecode being current.

Who This Catches

Anyone with a deployed program built before the v3 toolchain who has not upgraded since. That describes a large share of the long tail: token launches from 2023 and 2024 with a custom program, NFT projects, small DeFi protocols, games. Many of them intended to renounce eventually and never got round to it.

It also catches the honest-but-late: a team that goes to freeze the program as a trust signal after the gate activates, and discovers the instruction fails.

The fix is not hard, but from then on it is not one instruction:

Rebuild the program with a current toolchain, producing v3 bytecode.
Upgrade the program with the new build. The upgrade spills the old program-data's excess lamports and the buffer's balance to your spill account and leaves the buffer as a 37-byte husk holding rent.
Then set the authority to none.

Three transactions, in that order, at least one slot apart — the loader rejects a second mutation of the same program in the same slot.

The Other Loader Rule That Changed: Extends

Programs need more space over time, and ExtendProgram grows the program-data account. Two things about it are worth knowing now.

It is permissionless. The loader passes no authority check on extend; anyone can grow anyone's program-data account, paying the rent for the extra bytes themselves. A checked variant existed and was removed. This is old behaviour, but it is newly relevant because of the second point.
It has a minimum. Under SIMD-0431 an extend must add at least 10,240 bytes, unless the program is within 10 KiB of the 10 MiB size cap, in which case it must add exactly the remaining headroom. Incremental extends of a few hundred bytes — the habit of many deploy scripts that grow the account to fit each new build — now fail, and the fix is to extend in 10 KiB steps or size the account generously up front.

And extends still accept old bytecode. The source comment is explicit: the deployment gate is deliberately not applied to extend, so a legacy program can still be grown once it can no longer be redeployed or frozen.

What "Immutable" Should Mean in an Audit Now

An audit that reports "upgrade authority: none" is reporting a fact about programs that could reach that state. For programs that cannot, the report needs a second field: bytecode version. Once the gate activates, a v0, v1 or v2 program with a live authority is not "not yet renounced"; it is "cannot be renounced without a rebuild", and the difference is material to anyone deciding whether to trust it.

The token audit on this site reads the program-data account behind any program a token depends on. The version of the bytecode is in the first bytes of it, and the audit will say when a program is in the stranded state rather than implying the team simply has not pressed the button.

The Smaller Rules That Arrive With the Same Gate

Deploying will also de-register the old allocator symbol, sol_alloc_free_, so programs that depend on it load at runtime but cannot be deployed. The deploy verifier is stricter than the executor — it rejects broken ELFs that the runtime would tolerate — which means "it runs on mainnet" is not evidence that "it will redeploy".

Execution of old bytecode is a separate question with its own gates, and in the current build those gates are placeholders. Old programs keep running. The gate discussed here is about deployment and freezing, not execution.

Program Immutability: Questions People Actually Ask

Why does setting my Solana program’s upgrade authority to none fail?

Once SIMD-0500 activates — it had not activated on mainnet as of 17 September 2026 — the loader refuses to freeze a program whose bytecode is SBPF v0, v1 or v2. Rebuild with a current toolchain, upgrade, then set the authority to none.

Do old Solana programs stop running under SIMD-0500?

No. The gate blocks new deployments and upgrades of old bytecode, and freezing it. Execution is governed by separate gates that are placeholders in the current build.

Can anyone extend my Solana program’s size?

Yes. ExtendProgram carries no authority check; the caller pays the rent for the added bytes. Extends must now add at least 10,240 bytes unless the program is within 10 KiB of the 10 MiB cap.

How should an audit report a legacy Solana program?

With the bytecode version next to the authority. Once SIMD-0500 activates, a v0–v2 program with a live authority cannot be renounced without a rebuild, which is a different state from a team that has not renounced yet.

If You Hold a Program's Upgrade Authority

Check the bytecode version of every program you control. If it is below v3, you can still renounce it today, and you will not be able to once the gate activates, so plan the rebuild-upgrade-renounce sequence rather than discovering the failure in front of your community.

If you audit programs, report the version alongside the authority. "None" and "cannot be set to none" are different states, and the second one is about to become common.

And if you are extending a program, extend in 10 KiB steps. The one-byte top-up era is over.

— Authority Is Half the Answer —

Read the bytecode version next to it.

The token audit reads the program-data account behind the programs a mint depends on, straight from the chain — the authority, and the version that decides whether that authority can ever be given up.

Audit a Token ↗

A different kind of program change is happening at the same time: SPL Token is being replaced in place and ends up with no upgrade authority at all. And the lamports an upgrade spills back to you are part of the wider rent surplus sitting in old accounts.

Loader behaviour read from the Agave validator source at commit beee69b958: programs/bpf_loader/src/lib.rs and feature-set/src/lib.rs. On 17 September 2026 the deployment gate had not activated on mainnet; the rules above describe the validator's behaviour once it does. Check the tracker before relying on either rule.

Confidential Transfers Have a Kill Switch: What It Costs You

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

Originally published on xroot.dev.

The post on what is native and what is a third-party layer drew the same follow-up in three different ways: if the confidential features are native, can they be turned off?

Yes. Every confidential operation on a Token-2022 mint depends on one on-chain program, the ZK ElGamal proof program, and the validator carries two feature gates for it: one that disables it and one that re-enables it. Both switches have been used. This post is what each one does to a confidential balance, what a proof costs in compute and bytes, and why the biggest proofs need the new transaction format.

One Program Underneath Every Confidential Operation

A confidential transfer does not hide an amount by magic. The token program stores balances as ElGamal ciphertexts, and every operation that changes them — deposit into confidential form, transfer, withdraw back to plain — must be accompanied by zero-knowledge proofs that the amounts are well-formed: non-negative, within range, consistent between sender and receiver.

The token program does not verify those proofs itself. It calls the ZK ElGamal proof program, a separate native program whose only job is proof verification. If that program is unavailable, no confidential operation can be completed, because the token program cannot confirm the proofs it is handed.

That dependency is the kill switch.

The Two Gates

The validator's feature set carries disable_zk_elgamal_proof_program and reenable_zk_elgamal_proof_program, both live in the current feature snapshot. The first removes the proof program from the set the runtime will execute; the second puts it back. They are ordinary feature gates, activated at an epoch boundary after 95% of stake adopts each, and they have been used in that order once already. A flaw in the verifier's Fiat-Shamir transcript was found on 10 June 2025; the disable gate activated on 19 June 2025 at the start of epoch 805 (slot 347,760,000), and after audits the re-enable gate activated on 4 June 2026 at the start of epoch 982 (slot 424,224,000), with Token-2022 redeployed with its confidential instructions later that month. The proof program has been live on mainnet since that day, and as of 17 September 2026 the disable gate has not been used again.

What "disabled" means for a holder:

Plain balances are untouched. A mint with the confidential-transfer extension still transfers, mints and burns normally in its public balance.
Confidential balances are frozen in place. The ciphertexts remain in the account, provably yours, and no operation that needs a proof — including withdrawing back to a plain balance — can execute.
Pending confidential deposits stay pending. Applying them needs a proof.

"Re-enabled" restores all of it with no state migration; the ciphertexts were never modified.

Worth knowing: an older program, the ZK Token Proof program, still exists as an address. It was never activated on any cluster and is now a stub that returns success while doing nothing and charging no compute. A transaction that calls it succeeds silently and proves nothing. Tooling that still references it is verifying against a program that verifies nothing.

What a Proof Costs, in Compute

The proof program charges a fixed compute-unit price per proof type, and the base instruction cost is zero. From the source:

Batched range proof, 64-bit — 111,000 units

Batched range proof, 128-bit — 200,000 units

Batched range proof, 256-bit — 368,000 units

Public key validity — 2,600 units

Zero-ciphertext — 6,000 units

Ciphertext-to-ciphertext equality — 8,000 units

Ciphertext-to-commitment equality — 6,400 units

Percentage with cap (confidential fees) — 6,500 units

Grouped-ciphertext validity, 2 / 3 handles — 6,400 / 8,100 units

Grouped-ciphertext validity, batched — 13,000 / 16,400 units

Closing a context-state account — 3,300 units

A confidential transfer needs several of these. The range proof dominates: a 256-bit batched range proof alone is over a quarter of the 1.4-million-unit per-transaction ceiling and about half a percent of an entire block — 0.49% of today's 75-million-unit block limit at 300 ms slots, and 0.59% of the 62.5 million that applies from epoch 1037, when slots drop to 250 ms. Compared with a plain token transfer of a few thousand units, a confidential one is two orders of magnitude more compute — and the priority-fee arithmetic, rank equals fee divided by requested cost, punishes that accordingly.

What a Proof Costs, in Bytes, and Why v1 Transactions Matter

Proofs are large. A 64-bit range proof is 672 bytes; 128-bit is 736; 256-bit is 800. A transaction has historically been capped at 1,232 bytes total, including signatures, accounts and every other instruction. Fitting a transfer's full proof set into one legacy transaction was the reason confidential transfers were awkward to use at all.

The program offers two workarounds and the network now offers a third:

Proof-in-account. If the instruction data is exactly five bytes — a discriminator and an offset — the program reads the proof from an account instead of the instruction. You write the proof on chain first, verify against it, then close it.
Context-state accounts. Verify a proof once into a dedicated account whose size must match the context exactly, reference that account from later instructions, and close it afterwards. Closing reassigns the account to the system program, so its address is reusable.
Transaction v1. The new format raises the ceiling to 4,096 bytes, enough to carry a full proof set inline. Confidential transfers are one of the explicit motivations in the proposal, and v1 activated on mainnet on 15 September 2026 (epoch 1035), so the multi-transaction dance is now optional.

Each workaround leaves accounts behind. Context-state and proof accounts hold rent, and closing them returns it — a small, recurring reclaim that the confidential-transfer tooling of the future should do for its users automatically.

Reading Your Own Balance

A confidential balance is decryptable only by the holder's ElGamal key, and decrypting an ElGamal ciphertext is not a single operation: the implementation recovers the amount with a 32-bit baby-step giant-step search, with a precomputed table, bounded so that a phone can do it in around a second. Wallets that show a confidential balance instantly are showing a cached value. The honest number is the decrypted one, and it costs a moment.

Confidential Transfers: Questions People Actually Ask

Can Solana confidential transfers be disabled?

Yes. A feature gate removes the ZK ElGamal proof program, which every confidential operation depends on, and a second gate restores it. Both have been used: disabled on 19 June 2025 at the start of epoch 805, re-enabled on 4 June 2026 at the start of epoch 982.

What happens to my confidential balance if the proof program is disabled?

It stays encrypted in your account and cannot be moved or withdrawn to a plain balance until the program is re-enabled. Plain balances on the same mint are unaffected.

How much compute does a Solana confidential transfer use?

The range proof alone is 111,000 to 368,000 units depending on bit width, plus several smaller proofs. A plain token transfer is a few thousand units.

Why do confidential transfers need transaction v1?

A range proof is 672 to 800 bytes and a legacy transaction is capped at 1,232 bytes. Version 1 transactions allow 4,096 bytes, enough for a full proof set in one transaction.

What to Decide Before Using a Confidential Balance

Understand the dependency. Your confidential balance is safe in either state of the switch, and inaccessible in one of them. If you need the ability to exit at any moment, keep part of the position plain.
Budget the compute. A confidential transfer costs a hundred times a plain one in units; set the limit from a simulation and expect the fee to reflect the space.
Prefer v1 transactions, live on mainnet since 15 September 2026, and reclaim the proof and context accounts either way.

— Two Gates, One Consequence —

The day either flips, every confidential balance changes state at once.

Both the disable and the re-enable gate are feature accounts like any other. The upgrades tracker reads them from the chain every minute and shows which state each cluster is in.

Open the Upgrades Tracker ↗

Compute prices and sizes read from the Agave validator source at commit beee69b958: programs/zk-elgamal-proof/src/lib.rs and feature-set/src/lib.rs. The disable and re-enable dates are read from the two feature accounts on mainnet-beta, checked on 17 September 2026; the incident that prompted the sequence is covered in the native-vs-rings post.

Alpenglow: Half of Every Vote Reward Goes to the Leader

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

Originally published on xroot.dev.

The post on validator commissions covered how a validator's cut is set. This is the next chapter, and it is less discussed than the commission changes because it is buried in consensus code rather than in a vote-account field.

The alpenglow feature gate had not activated on mainnet as of 17 September 2026, so a validator still earns vote rewards by landing vote transactions, one per slot, paying a fee for each. Under Alpenglow there are no vote transactions. Votes are signed messages between validators, and the reward for a vote is paid only when a later leader certifies it — and when it is paid, half goes to that leader.

This post is the reward pipeline as the validator implements it, with the constants, and what it does to the income of a validator and the delegators behind it.

The Per-Slot Reward, and Who Gets Which Half

The validator computes each slot's inflation reward for a voting validator as:

reward — epoch reward budget × validator's stake ÷ (slots per epoch × total stake)

validator reward — reward ÷ 2

leader reward — reward − validator reward

The voter keeps half. The leader of the slot that certified the vote keeps the other half, and any odd lamport rounds to the leader. Across an epoch a validator's income is therefore half of its own votes plus half of everyone's votes during the slots it led — and the second half scales with how often it leads, which scales with stake.

Worth knowing: the pre-Alpenglow system running on mainnet today has a cruder rounding rule. When a vote reward splits between a validator and its delegators and either side would round to zero, the legacy code skips the reward entirely and does not advance the credits counter. Alpenglow's split hands the residual lamport to the voter instead. Small validators on the old system have been losing rounding dust for years; the new one stops that.

You Are Paid Only If the Leader Eight Slots Later Says So

A vote is not rewarded when it is cast. It is rewarded when it appears in a reward certificate, and reward certificates are built by the leader of the slot eight slots after the one you voted in. The leader of slot N assembles the certificates for slot N − 8 from the votes it has received, and ships its block whether or not those certificates are complete — the code uses a non-blocking request with a small queue rather than waiting.

Two things follow for a validator's income:

Your vote has to reach the right leader in time. Not the current leader — the one eight slots ahead. A validator whose votes propagate slowly, or whose connection to upcoming leaders is poor, votes correctly and is not paid.
The leader has discretion of a kind. It certifies the votes it has. It cannot invent votes, but a vote that arrives late is simply absent from the certificate and earns nothing. There is no appeal.

The votes themselves travel over a dedicated QUIC transport between validators, not through the transaction pipeline, so the fee that used to accompany every vote transaction disappears with it. Under Alpenglow the cost of voting is bandwidth, and the reward for voting depends on latency to leaders.

The Epoch Budget Is Fixed On Chain Before the Epoch Starts

The pool of SOL to be paid as vote rewards is computed at the start of the epoch and written into an on-chain account — a program-derived address under the Alpenglow program that stores the current and previous epoch's state. Every slot's payout draws from that fixed budget by the formula above. Nothing a validator does during the epoch changes the size of the pot; it only changes their share.

After the migration the vote account's historical "epoch credits" field stops counting votes and starts counting reward lamports. The runtime pushes a sentinel row at the migration epoch to mark the change. Any tool that reads epoch credits as a performance metric will see a nonsense value at the boundary and lamports afterwards — a silent unit change that every staking dashboard will have to handle.

The Admission Filter Runs Twice

The post on the 2,000-seat cap covers who gets to vote. The same filter runs again at reward time: a vote account that fails the admission test — no BLS key, zero stake, balance below rent plus one epoch's ticket after subtracting pending delegator rewards — is excluded from reward distribution as well as from consensus. For a delegator this compounds: a validator that slips out of the set does not just stop voting, it stops earning for the epoch, and so do you.

What This Does to Delegator Income

Your validator's inflation income becomes two streams: half of its own vote rewards, and half of the vote rewards of every validator during its leader slots. Both are then subject to the inflation commission it charges you. A validator with more stake leads more often and collects more of the second stream — the reward curve bends further toward large validators than it does today.

Connectivity becomes yield. Two validators with identical stake and commission will earn differently if one reaches the next leaders faster. The metric that predicts it — how quickly a validator's votes are certified — is measurable from the ledger after activation, and it is the metric a careful delegator should ask for.

The commission fields do not change. The two-commission post still applies; this post changes the size of the number the commission is taken from.

Alpenglow Rewards: Questions People Actually Ask

How are Solana validators paid under Alpenglow?

Each slot’s inflation reward for a voter is split in half: the voter keeps one half and the leader who certifies the vote keeps the other. Votes are no longer transactions, so there is no vote fee.

When is a vote rewarded under Alpenglow?

When it appears in a reward certificate built by the leader of the slot eight slots later. A vote that reaches that leader late is not certified and earns nothing.

Do delegators earn less under Alpenglow?

Your validator’s income becomes half of its own votes plus half of everyone’s votes during its leader slots, still minus its inflation commission. Larger validators lead more often and collect more of the second stream.

What happens to the epoch credits field after the Alpenglow migration?

It accumulates reward lamports instead of vote credits, with a sentinel row at the boundary. Tools reading it as a performance score will need updating.

What to Watch After Activation

If you delegate: the share of your validator's votes that actually appear in reward certificates. A validator that votes and is not certified is invisible in a commission table and visible in its reward account.
If you operate: your latency to upcoming leaders, not to the network in general. Under this reward rule, peering is revenue.
Everyone: the epoch-credits field changes units at the migration. Until dashboards catch up, read reward lamports from the vote account directly.

— Not Live on Mainnet as of Sep 17, 2026 —

The alpenglow feature account was still inactive on 17 September 2026, and it flips at an epoch boundary.

The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state per cluster. The timers and certificates that decide when a vote counts at all are in Alpenglow Finality in Numbers.

Open the Upgrades Tracker ↗Read the finality post

Constants read from the Agave validator source at commit beee69b958: runtime/src/block_component_processor/vote_reward.rs, votor-messages/src/reward_certificate.rs and core/src/certs_requestor.rs. The 50/50 split is a constant in that source — re-read it before depending on the ratio.

Which Client Built Each Solana Block: Reading the Footer

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

Originally published on xroot.dev.

"What share of Solana runs which client?" is a question that gets answered with a dashboard number every few months, and the number is usually a guess from gossip. That changes when Alpenglow activates, in a way the dashboards have not caught up with: under Alpenglow, every block names the software that built it, in the block itself, and stamps its own nanosecond clock next to the name. The alpenglow feature gate had not activated on mainnet as of 17 September 2026.

Combined with a field gossip has carried for years, that will make client share a per-block measurement anyone with an RPC connection can make — and it will make "did my fills follow a particular builder" a question with a data source. Here is what is in the footer, what gossip already tells you, and the honest limits of self-reported strings.

The Footer: A Client String and a Clock

An Alpenglow block carries a footer, and the validator writes two things into it.

A user-agent string. Agave writes agave/<version>. The field is capped at 255 bytes by a one-byte length prefix and is whatever the producing client chooses to put there. Another client writes its own name.
A producer timestamp in nanoseconds. The leader's own wall clock at production. It is not free-form: the runtime rejects the block if the timestamp is not strictly after the parent's and not more than two slot durations later. Within that window it is whatever the leader says.

Since Agave 4.3 a Geyser plugin can receive the footer directly, with the slot and bank it belongs to, independent of entries. So a data pipeline can attribute every block to a client without parsing anything else.

Worth knowing: the footer is an Alpenglow structure, and the alpenglow gate had not activated on mainnet as of 17 September 2026. Blocks produced under the current consensus have no per-block client string; until the gate flips, the only attribution available is the gossip field below.

Gossip Already Carries a Client ID

Every validator broadcasts a contact-info record in gossip that includes its software version and a client ID — an enumeration the reference client maintains. The current list, from the source:

Client IDs in gossip — SolanaLabs · JitoLabs · Frankendancer · Agave · AgavePaladin · Firedancer · AgaveBam · Sig · Rakurai · HarmonicFiredancer · HarmonicAgave · HarmonicFrankendancer · FireBAM · Raiku

Fourteen entries, and the list reads as a map of the ecosystem: the two full clients, the hybrid, the MEV and block-engine variants of each, and the alternative clients. getClusterNodes exposes the ID as a string on any RPC, alongside the node's feature-set hash and shred version. Weighting by stake gives you client share of stake today; joining to the leader schedule gives you client share of blocks before the footer even exists.

What You Can Measure, Block by Block

Put the two sources together and three measurements fall out.

Client share of blocks produced. Footer string per block, or leader schedule joined to gossip client ID. The former is authoritative once live; the latter works now.
Clock skew per producer. The footer timestamp minus the block's derived time, per validator. A producer whose declared clock runs consistently ahead or behind is visible after a few slots.
Whether your outcomes correlate with a builder. If your transactions land at a different rate, or sit at a different position in the block, under one client than another, the footer is the field that lets you group by it. The block-engine variants in the list are the ones traders will want to test first.

The Limits, Which Are Real

Both fields are self-declared. Agave writes its version because that is what the code says; nothing forces any client to tell the truth, and the gossip client ID passes sanitisation without any check. A validator can call itself whatever it likes. In practice clients are honest because there is no incentive to lie and the fingerprint of their behaviour gives them away, but the data is testimony, not proof.

The nanosecond clock is bounded, not verified. Within its allowed window it is the leader's word.

And the footer only exists after Alpenglow activates, which had not happened on mainnet as of 17 September 2026. Until then, gossip client IDs joined to the leader schedule are the measurement, with the caveat that a validator can change software between gossip refresh and block production.

The Clock That Comes With It

Alpenglow also adds an on-chain nanosecond clock, at a program-derived address seeded with the word alpenclock under the Alpenglow program. It is a system-owned account holding a single signed 64-bit integer of nanoseconds, updated by consensus. Once that gate is live, programs and users have sub-second on-chain time for the first time, derived from the producer timestamps above and bounded by the same rules.

For anyone who has ever timestamped something by multiplying slots by 400 milliseconds, it is the replacement, and that arithmetic has already broken: mainnet ran 400 ms slots until 21 August 2026, runs 300 ms today, and moves to 250 ms from epoch 1037. The on-chain clock survives the slot-time reductions that break that arithmetic.

Client Attribution: Questions People Actually Ask

How can I tell which client produced a Solana block?

Under Alpenglow the block footer carries a user-agent string written by the producer, for example agave/. Before that, join the leader schedule to each validator’s client ID from gossip.

What is the Alpenglow block footer?

A structure at the end of each block holding the producer’s client string, capped at 255 bytes, and its nanosecond timestamp, which must fall between the parent’s time and two slot durations later.

How do I measure Solana client diversity?

Call getClusterNodes, take each validator’s clientId, and weight by stake or by slots in the leader schedule. The list of client IDs in the reference client currently has fourteen entries.

Is the Solana client string trustworthy?

It is self-declared and unchecked, so it is testimony rather than proof. Clients have no incentive to lie and their behaviour fingerprints them, but treat the field as a label, not a verification.

How to Get a Client Census Today

Call getClusterNodes, keep clientId, pubkey and version. Fetch the current leader schedule. Join on pubkey, weight each validator by its slots in the epoch. That is client share of block production for this epoch, from one RPC, and it takes a minute.

When the footer goes live, the same join becomes a per-block fact instead of a per-epoch estimate. The consensus change that brings it is in Alpenglow Finality in Numbers, and the reward rule that decides what a producer earns for the block is in the post on vote rewards.

— The Footer Arrives With One Gate —

Per-block attribution starts the epoch Alpenglow activates.

Until then the gossip join is the measurement. The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state on each cluster, so you know which of the two methods you are on.

Open the Upgrades Tracker ↗

Fields read from the Agave validator source at commit beee69b958: core/src/block_creation_loop.rs, runtime/src/block_component_processor.rs and version/src/client_ids.rs. The client-ID enumeration grows with the ecosystem — re-read it rather than copying the list above.

Solana's Inflation Now Decays Twice as Fast (SIMD-0550)

Suliman Mokhtar — Wed, 16 Sep 2026 18:41:08 +0000

Originally published on xroot.dev.

Solana's inflation schedule has been the same curve since 2021: start at 8% a year, shrink by 15% of itself every year, stop at 1.5%. Stakers have quoted "about 4-and-a-bit percent" for a while because that is roughly where the curve sits five years in.

SIMD-0550 changes one number in that curve — the annual shrink rate goes from 15% to 30% — and it does so in a way that guarantees nobody notices on activation day. The rate you see the day after is the rate you saw the day before. The entire effect is in the future, and the future arrives about twice as fast.

This post is the formula, the re-anchoring trick that hides the change, and a forward curve computed from the rate that is actually live today.

The Curve, as the Validator Computes It

The validator's inflation object has four parameters: an initial rate, a terminal rate, a taper, and a foundation share. The total rate in year t is:

rate(t) — max( terminal, initial × (1 − taper)t )

With the defaults — initial 8%, terminal 1.5%, taper 0.15 — year zero is 8%, year one is 6.8%, year five is about 3.5%, and the floor of 1.5% is reached around year 10.5. The foundation took 5% of issuance for the first seven years; that period is over — getInflationRate reports a foundation share of 0 on mainnet today, so everything now goes to stakers and validators.

Worth knowing: "year" here is not a calendar year. It is slots since the inflation start slot divided by slots-per-year, and the start slot was aligned back one epoch when inflation was switched on. When slot times shrink, slots-per-year rises and the year counter keeps time correctly. The curve is defined in wall-clock terms even though it is evaluated in slots.

What SIMD-0550 Changes, and the Re-Anchor That Hides It

The feature sets the taper to 0.30. If that were all it did, the rate would drop sharply on activation, because 8% × 0.705 is a much smaller number than 8% × 0.855.

So the code does one more thing. At the epoch boundary where the feature activates, it reads the rate the old curve produces at that moment — call it the anchor — and rewrites initial so that the new curve passes through exactly the same point:

initial_new — anchor ÷ (1 − 0.30)year

The rate is continuous at activation. There is no step. The only thing that changed is the slope going forward: from here on, each year is 70% of the last instead of 85%.

The implementation detail is a small piece of care: rather than mutating the shared inflation object, the node replaces it, so that every boundary bank anchors off the pre-activation schedule and sibling forks never see a half-applied change. It is the kind of thing that matters only if it goes wrong, and it is done right.

The Forward Curve, From Today's Live Rate

The table below anchors on the rate live on mainnet as this was published: 3.65%, read from getInflationRate at epoch 1035 on 15 September 2026. If you are reading this later, pull the current rate and rerun it — the shape is what matters, not this particular anchor.

Years after activation — old taper 15% → new taper 30%

0 — activation day — 3.65% → 3.65% (no step)

1 — 3.10% → 2.55%

2 — 2.63% → 1.79%

3 — 2.24% → 1.50% (floor)

4 — 1.90% → 1.50%

5 — 1.62% → 1.50%

6 — 1.50% (floor) → 1.50%

From a 3.65% anchor the old curve takes about six years to reach the 1.5% floor; the new one takes about three. Summed across years one to three, the new curve pays about 27% less inflation than the old one would have — 5.84 percentage-points of issuance against 7.97.

Staking yield is not the inflation rate. It is the inflation rate scaled by the inverse of the staking ratio — with roughly 69% of supply staked, each staked SOL receives about 1.45× the headline rate — minus the validator's commission. The ratio and the commission are yours to look up; the halving of the slope is the protocol's.

Who Feels This, and When

Long-term stakers feel it as a slow leak. Nothing changes in the first epoch, or the first month. It shows up as a compounding gap against what the old schedule would have paid, and it is largest in years two and three.
Anyone modelling SOL yield against alternatives — liquid staking rates, lending rates, treasury bills — needs to rerun the crossover date. The date at which native staking stops out-earning an alternative moves earlier, potentially by years.
Validators feel it in revenue, which is why the same era brings block-revenue sharing and basis-point commissions: with inflation shrinking faster, the fee side of validator income gets relatively larger, and the tooling to split it with delegators is arriving at the same time.
Token holders who do not stake feel the opposite: dilution slows faster. Whether that is worth more than the lost yield depends on what you hold and why.

What This Post Cannot Tell You

It cannot tell you the activation date. The gate is one feature account, activated at an epoch boundary after 95% of stake adopts it, and the schedule is set by validator adoption rather than an announcement.

It cannot tell you your own yield, because that needs the staking ratio and your validator's commission on the day you ask.

And it cannot tell you whether 30% is the right taper. The proposal's argument is about long-run security budget and issuance; the code's job is to apply it without a jump. Both are doing exactly what they say.

Solana Inflation: Questions People Actually Ask

What does SIMD-0550 change?

The annual disinflation rate, from 15% to 30%. Each year’s inflation becomes 70% of the previous year’s instead of 85%, until the 1.5% floor.

Will the Solana inflation rate drop on activation day?

No. The code re-anchors the starting rate so the new curve passes through the rate in force at activation. The change is entirely in the slope from that point on.

How does SIMD-0550 affect Solana staking yield?

Yield tracks inflation scaled by the inverse of the staking ratio, minus commission. Over the following three years the new curve pays about 27% less inflation than the old one would have from the same anchor.

Is SIMD-0550 active on Solana mainnet?

It is one feature gate (double_disinflation_rate), activated at an epoch boundary after 95% stake adoption. Check a feature-gate tracker for the state per cluster.

The One Calculation to Do This Week

Take your staked SOL, the live inflation rate, your validator's commission, and the staking ratio. Compute your expected yield for each of the next three years under a 0.85 multiplier and under a 0.70 multiplier. The gap between the two columns is what SIMD-0550 costs you, and it is the only number in this post that is specific to you.

— The Gate Is One Account on Chain —

There is no announcement to wait for.

double_disinflation_rate activates at an epoch boundary once 95% of stake runs software that supports it. The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state on each cluster.

Open the Upgrades Tracker ↗

Mechanism read from the Agave validator source at commit beee69b958: feature-set/src/lib.rs and runtime/src/bank.rs. The anchor rate and the zero foundation share were read from mainnet getInflationRate at epoch 1035 on 15 September 2026; both columns of the table are arithmetic on that anchor.