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.
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.