# Solana p-ATA proposal merges while activation remains unassigned

Canonical: https://forkbrief.com/news/339e73f3-d70c-4617-8933-ba6f87875d42
Published: 2026-11-02T08:43:28.847Z
Publisher: Fork Brief

SIMD-0567 entered the proposal repository on November 1. Its optional caller hints and migration plan remain separate from a mainnet activation.

Solana's Improvement Documents repository merged SIMD-0567 on November 1, adding a proposed rewrite of the Associated Token Account program called `p-ATA`. The [merge record](https://github.com/solana-foundation/solana-improvement-documents/pull/567) shows the document was merged at 11:02 UTC. Its current header still says `Review`, with the feature identifier listed as `TBD`.

The proposal targets a routine part of Solana applications: creating the canonical account a wallet uses for a particular token. Its [design](https://raw.githubusercontent.com/solana-foundation/solana-improvement-documents/main/proposals/0567-cu-optimized-ata-program.md) would replace the existing ATA program at the same program address with an implementation built using Pinocchio. The stated aim is to reduce compute use while keeping existing instruction layouts, account-address derivation and error behavior compatible.

Existing callers could continue using `Create`, `CreateIdempotent` and `RecoverNested`. A new optional instruction, `CreateWithArgs`, would let callers supply information that the program otherwise determines itself. The documented payload is seven bytes: a discriminator, a creation mode, a bump hint and a four-byte account-length hint. Zero means the bump or length hint is absent. A rent sysvar can be supplied as an additional account.

Those options require attention to the particular call path. The proposal recommends the existing creation instructions when no hints are available. Its tables also show that supplying every hint can add compute in some Token-2022 creation cases. The design does not describe one uniformly cheaper setting for every transaction.

Migration is a separate implementation step. The document describes deploying a verified program artifact to a Loader v3 buffer before a feature-triggered replacement. It says the ATA program would be unavailable during the activation slot and become effective in the following slot.

Neither the merge receipt nor the proposal header assigns that activation slot. The new confirmed step is the document merge; its compute figures are proposal-reported measurements rather than evidence of results from a completed mainnet rollout.

## Sources

- [One of Solana's busiest programs could use 81% less compute](https://solanacompass.com/news/simd-0567-merged-p-ata-plans-a-cheaper-associated-token-account-program-for-solana) — Solana Compass
- [SIMD-0567: CU-optimized ATA Program (\`p-ATA\`)](https://github.com/solana-foundation/solana-improvement-documents/pull/567) — Solana Improvement Documents / GitHub
- [SIMD-0567: p-ATA, CU-optimized ATA Program](https://raw.githubusercontent.com/solana-foundation/solana-improvement-documents/main/proposals/0567-cu-optimized-ata-program.md) — Solana Improvement Documents

- [Editorial policy](https://forkbrief.com/editorial-policy)
- [Request a correction](https://forkbrief.com/corrections)