Solana (SOL) Token Account Proposal SIMD-0567 Merged With 81% Compute Cut

SIMD-0567 Merged With 81% Test Cut

Solana's token account machinery is set for a major compute cut, and the paperwork moved on Monday: SIMD-0567, a rebuilt associated token account program, was merged into the network's improvement proposal repository, with test results showing an 81% average reduction in compute units once instruction usage frequency is weighed in. The old and new paths sit far apart in the measurements the proposal cites: creating a standard SPL token account consumes 18,433 CU under the current program, while the p-ATA design completes the same instruction at 3,085 CU, a cut of 83.3%. That makes this a network engineering story rather than a Solana price event, and no market reaction to the merge itself was recorded at publication time. An associated token account is the standard account a wallet opens to receive a specific token, with its address derived from the wallet and the token; every flow that touches a token needs one, from plain wallet transfers to composable interactions such as Solana Blinks. The p-ATA design keeps the same program address as the existing ATA program and preserves the Create, CreateIdempotent and RecoverNested instruction interfaces, so applications and wallets do not need to change addresses or calls when the new program goes live. Savings elsewhere in the instruction family landed between 63.3% and 85.7%, with the exact figure depending on the token program involved and whether the account had to be created during the call. A further instruction, CreateWithArgs, was proposed to accept extra optimization information; in tests where all of that information was supplied, compute use fell further for some token types and commands and rose for others, and one Token-2022 account creation used 182 CU more than the existing p-ATA path.

Scope and Cost Limits

Scope is the first thing to get right: SIMD-0567 replaces the program that creates token accounts, not the token transfer program itself. The p-token, the separate token program, has been introduced by the Solana (SOL) Foundation as fully deployed to mainnet. For the network as a whole, the change is about block capacity: every token account creation currently burns close to 18,400 CU, so an 83% cut frees real room in each block for the rest of the ledger's work, including the account-heavy churn of high-frequency participants such as market makers and AI trading bot infrastructure that open large numbers of token accounts. Our Solana coverage tracks these protocol threads alongside market news. The proposal's own discussion narrows what users actually save. Its author explained in the official proposal discussion that the cost of an account-creating transaction is almost entirely the deposit reserved for rent exemption, with the compute fee making up only a small slice of that bill. An 81% CU reduction therefore trims the compute slice, not the deposit. The distinction matters for anyone budgeting on-chain costs: the deposit, not the compute fee, sets what a new account costs today. Status is the other limit: the document sits at review, and no activation date has been set. The proposal names three verification steps before the feature moves further: a comparison of execution results between the existing and the new programs, testing that replays historical mainnet transactions, and an external security audit. Validators, whose nodes execute these programs under staking-backed economic security, will only face the change once activation is scheduled. Until then, node operators and application teams keep running the current ATA program unchanged, and the merge itself alters nothing on mainnet today.

Activation and Audit Still Pending

Our reading is that the merge advances a real efficiency gain while leaving its payoff timing open. The 81% figure comes from the proposal's own tests, not a live deployment; activation is unscheduled and the external audit is pending, so the market side, from recent Solana ETF outflows to institutional adoption such as tokenized bond issuance on Solana, continues to move on its own calendar. The limit that survived the change is the rent-exemption deposit: because it accounts for nearly all of what an account-creating transaction costs, user bills will not fall in line with the compute cut, and our Solana technical analysis will track the price picture separately from this engineering thread.