A proposal to replace one of the most-used programs on Solana with a far cheaper version has cleared its first formal step. SIMD-0567, which describes a rewrite of the Associated Token Account program called p-ATA, was merged into the Solana Improvement Documents repository at 11:02 UTC on 1 November 2026. The proposal text projects that p-ATA would use 81% less compute on average than the program it replaces, and estimates a cut of about 10-11% in compute use across the whole network.
The merge does not switch anything on. The SIMD's header still lists its status as Review and its feature gate as "TBD", so p-ATA has no activation date and is not running on mainnet. Gabe Rodriguez of Anza, listed first of the proposal's two authors alongside Peter K. of Ergonia, posted after the merge: "p-ATA SIMD is merged. Cluster-wide CU reduction in the pipeline."
What the Associated Token Account program does on Solana
The Associated Token Account (ATA) program creates the default account a wallet uses to hold a given token. On Solana, every token balance lives in its own account, and the ATA program derives that account's address from the wallet and the token so that apps and wallets can always find it. When someone receives a token for the first time, or a trading bot buys a freshly launched coin, a transaction usually calls the ATA program to create that account, or to confirm it already exists.
That makes the program unusually busy. According to mainnet sampling published in SIMD-0567, the ATA program appears in 11.85% of all transactions (31.3% of non-vote transactions), ranks fifth among programs by instruction count, and accounts for 13.28% of all compute units used. Compute units (CU) are how Solana meters the work a program does, and each block can hold only a fixed amount of them, so a program that burns 13% of the total takes a large share of block space.
How p-ATA cuts compute with a Pinocchio rewrite
p-ATA keeps the same job and the same address but rebuilds the program on Pinocchio, a lightweight library for writing Solana programs that avoids copying data and pulls in very few dependencies. The proposal points to SIMD-0266, the p-token rewrite of the main Token program, as the precedent. That SIMD is now marked Activated, and it cut a TransferChecked instruction from 6,200 CU to 105 CU.
The SIMD's benchmarks for the four most common ATA calls, weighted by how often each occurs, show where the 81% comes from:
| ATA instruction (share of use) | Legacy ATA | p-ATA | Change |
|---|---|---|---|
| Create if missing, new SPL account (39.86%) | 22,940 CU | 4,171 CU | -81.8% |
| Create if missing, account already exists (30.32%) | 3,710 CU | 530 CU | -85.7% |
| Create if missing, existing Token-2022 account (18.60%) | 8,210 CU | 1,616 CU | -80.3% |
| Create, SPL token (5.65%) | 18,433 CU | 3,085 CU | -83.3% |
Developers would not have to change anything to get those savings. SIMD-0567 keeps the program ID, the instruction interface, the address and bump derivation, and the error codes identical to the legacy program, so existing apps and wallets would keep working and use less compute. It also adds one optional instruction, CreateWithArgs, which lets a caller pass hints the program would otherwise work out itself. The proposal puts the extra saving at 143 to 254 CU on most calls and 1,229 CU when checking an existing Token-2022 account.
Compute is the budget blocks are packed against. The time a validator spends running a transaction is a separate measure, and reviewers on the pull request pressed on the gap between the two. In the PR thread, Rodriguez cited a 35% reduction in wall-clock execution time from legacy ATA to p-ATA, a smaller gain than the compute figure, and the discussion covered cases where a cheaper-in-CU approach can run slower in practice.
Who reviewed SIMD-0567, and the Certora verification
The pull request was opened on 17 June 2026 and drew review from engineers at Anza and Firedancer. Firedancer's topointon-jump approved it on 29 June, and Anza's bw-solana approved it on 31 October, the day before the merge. On 30 October, Anza engineer febo posted in the thread that formal verification by Certora was complete, linking Certora's report dated 14 October 2026. Formal verification uses mathematical proofs to check that code behaves as specified; the SIMD's stated aim is to prove p-ATA behaves identically to the legacy program.
The proposal's security section also commits to differential testing against the old program, fuzzing with replayed mainnet transactions, and at least one external security audit of the final code. No audit report beyond the Certora verification has been posted in the PR.
What has to happen before p-ATA activates on mainnet
Several steps remain before p-ATA replaces the live program, and none has a published date. The SIMD lists three dependencies, SIMD-0312, SIMD-0449 and SIMD-0690. SIMD-0690 sets the migration rules: the new program is uploaded to a staging buffer ahead of time, and its contents are checked against a verified build hash before the swap. During the activation slot itself, the ATA program cannot be called, and p-ATA takes effect one slot later. The proposal also still needs a feature gate, the on-chain switch Solana uses to turn on protocol changes, which has yet to be assigned.
We first covered p-ATA's benchmark in our report on the Agave 4.1 release, and Pinocchio is also behind the smaller programs in Anchor 2.0's release candidate. SIMD-0567 is the formal proposal to make that work part of the protocol. If it activates as written, one of the network's heaviest compute users would need roughly a fifth of the compute it uses now, with no change asked of the apps that call it.
