SOLANA·HUB
DE

P-Token: Anza's Pinocchio-based SPL Token Rewrite Explained

How P-Token replaces the classic SPL Token program: same program ID via feature gate, 95 percent compute savings, three new instructions, Pinocchio instead of the solana-program crate. What devs, wallets, DEXes, and forensic tools need to know.

SOLANA·HUB ·

Solana’s most-used program was silently replaced — and almost nobody noticed. Here is why that was possible, and what it means for every user, every app, and every forensic tool on the network.

In plain terms: Think of it like a car manufacturer remotely swapping your engine overnight. The body is the same, the controls are the same, all your old keys still fit. But the new engine uses a twentieth of the fuel for the same journey. That is P-Token: Solana rebuilt the core of every token transaction from scratch — using a leaner framework called Pinocchio (a Rust library that cuts out the standard library entirely). Since May 2026 it runs under the exact same address as before. No user, no app, no indexer had to change a thing.

Core idea

P-Token is Anza’s complete rebuild of the classic SPL Token program — the foundation behind USDC, USDT, BONK, JUP, and most Solana token liquidity. Instead of the old solana-program crate (Solana’s standard program library), it is now written in Pinocchio, a lean Rust framework with no heap allocations and no standard library. That saves up to 98 percent of the compute cost per transfer operation, while keeping external behavior fully identical. Since epoch 971 (13 May 2026), P-Token is live on mainnet, activated through a feature gate (an automatic bytecode swap at the epoch boundary via validator vote) — no wallet or dApp had to do anything. The formal specification is SIMD-0266 “Efficient Token Program”.

What this is about

On 13 May 2026, in epoch 971, Solana swapped out its most-used program — without any wallet, dApp, or indexer having to migrate. Behind program ID TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA, P-Token has been running instead of the classic SPL Token program. P-Token is written from scratch in Pinocchio, a new Rust framework from Anza that replaces the older solana-program crate. The authors are febo and Jon Cinque (Anza). The specification is published as SIMD-0266 “Efficient Token Program”.

The result: a standard Transfer instruction now consumes 76 instead of 4,645 compute units (the execution cost unit of the Solana VM). That is a reduction of over 98 percent for the most common token operation on Solana. The Anza announcement on X and the Helius deep dive describe the scope of the change.

This article explains what Pinocchio is, how P-Token works architecturally, what changes for devs, wallets, DEXes, and forensic tools, and what roadmap Anza has lined up for the next wave (P-Token-2022, p-memo, p-ATA).

Not financial advice. This article describes a Solana protocol change and its technical implications.

Key facts

  • P-Token has been on mainnet since epoch 971 (13 May 2026) and replaces the classic SPL Token program — same program ID, same behavior, up to 98 percent fewer compute units per operation.
  • The swap was performed through the feature gate ptokFjwyJtrwCa9Kgo9xoDS59V4QccBGEaRFnRPnSdP by validator vote — no migration step required from holders, wallets, or dApps.
  • Three new instructions are added: batch (multiple token calls in one invocation), unwrap_lamports (direct wrapped-SOL unwrap), and withdraw_excess_lamports (recovering stranded SOL from mints).
  • Token program usage drops network-wide from roughly 10 percent to roughly 0.5 percent of block compute units. That creates headroom for more complex DeFi routes, more transaction volume, or higher effective TPS.
  • Token-2022 was NOT swapped — it stays on the old solana-program crate. A P-Token-2022 variant is on febo’s roadmap, but without a concrete timeline.
  • Tooling cost on the indexer side: instruction names are no longer logged. Log-based webhooks and custom indexers must switch to instruction-data decoding.

Pinocchio — the framework behind P-Token

Pinocchio is a Rust library (a code package in the Rust programming language) from Anza, maintained on GitHub as anza-xyz/pinocchio. The name plays on “no strings attached” — no standard-library threads, no heavy dependencies. Pinocchio is explicitly an alternative to the older solana-program crate (Solana’s previous standard program library), not a layer on top of Anchor.

Three architectural properties set Pinocchio apart:

no_std architecture. Pinocchio runs without the Rust standard library. No heap allocations (no dynamic memory management), no Vec-based deserialization, no standard IO. The Solana BPF VM (virtual machine that executes programs on Solana) is the only runtime; anything else must be built explicitly. That saves significant compute units because no per-invocation setup costs accrue.

Zero-copy account access. The AccountInfo struct (account data record in Solana programs) is a pointer to the original input buffer, not a deserialized copy. You read account data directly from the memory the runtime provides — without Borsh (Solana’s standard serialization format), without cloning, without touching the heap. That is exactly what makes token operations extremely cheap.

Three entrypoint macros. Pinocchio offers entrypoint! (migration from the older crate), program_entrypoint! (decouples allocator setup), and lazy_program_entrypoint! (nothing is parsed upfront). Programs can selectively pick the setup they need.

The difference from Anchor: Anchor is an opinionated framework (a development scaffold with built-in conventions) that builds on Borsh serialization, IDL generation (auto-generated program interface descriptions), and macro layers. Anchor optimizes for developer velocity. Pinocchio is a library, not a framework, and optimizes for compute efficiency. Both coexist — Anchor remains the default choice for rapid development and team collaboration, Pinocchio is the choice for performance-critical production programs.

Who is already using Pinocchio? Exo Tech is an early adopter. In a mid-2025 Pinocchio overview, Helius counted more than 1,200 devs with Pinocchio builds in their CI pipelines, particularly in wallets, DAO frameworks, and multisig infrastructure. Lead maintainers are febo and Jon Cinque, both at Anza. The library is production-ready for experienced devs, but coverage of sysvars is not yet complete, and the library itself has no standalone audit.

P-Token architecture in depth

The P-Token code lives under github.com/solana-program/token in the pinocchio/program directory, since early 2025. The earlier febo/p-token repository was archived in February 2025. What is specifically interesting about P-Token: the program adheres byte-for-byte to the account layouts of the classic SPL Token implementation. Mint, Account, and Multisig are 1:1 identical — that is the foundation for the drop-in behavior.

The feature-gate activation mechanism works as follows: Solana clusters activate code through feature-gate accounts. On the epoch transition to 971, the runtime detected the feature gate ptokFjwyJtrwCa9Kgo9xoDS59V4QccBGEaRFnRPnSdP as active and replaced the bytecode behind TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA via Upgradable Loader v3 with the P-Token bytecode — originally deployed at the staging address ptok6rngomXrDbWf5v5Mkmu5CEbB51hzSCPDoj9DrvF. Program ID stays, bytecode changes.

This matters for DEXes: Raydium, Orca, and Marinade typically maintain strict CU budgets within their CPI paths. Because P-Token consumes substantially fewer CUs, those budgets shrink automatically — no code update on the DEX side required. During the audit phase, Neodyme replayed mainnet transactions from 3 to 11 August 2025 and confirmed identical output behavior, with savings between 8.9 and 9.14 trillion CUs.

What stays 1:1 compatible: account state, discriminator bytes 0 to 24 for legacy instructions, authority logic, mint/burn/transfer semantics, SyncNative, multisig paths. Even the InitializeMultisig quirks are deliberately preserved so that no existing software breaks.

New are three instructions:

  • withdraw_excess_lamports (discriminator 38) — recovers SOL accidentally sent to mint accounts. The USDC mint alone holds about 323 SOL from historical mis-transfers, per SIMD-0266.
  • batch (discriminator 255) — bundles multiple token instructions into a single CPI call. Saves the 1,000-CU CPI overhead per extra instruction.
  • unwrap_lamports (discriminator 45) — direct transfer out of wrapped-SOL accounts. Replaces the older three-step pattern of create ATA, transfer, close.

The three instructions were deliberately not split into separate SIMDs — that would have required multiple separate upgrades to critical infrastructure.

SIMD-0266 — the spec behind the swap

SIMD-0266 was submitted on 19 March 2025 by febo and Jon Cinque. The PR #266 collected over 60 positive reactions with surprisingly little pushback — remarkable for a change to the chain’s most-used program.

Three documented discussion threads from the PR are relevant:

  • pooriagg pointed out that token programs are Solana’s backbone. The reply from deanmlittle: a comprehensive test suite plus formal equivalence verification defuses the risk.
  • zfedoran proposed splitting the three new instructions into separate SIMDs. The majority argued: one upgrade is better than three because validator coordination and adoption windows are more manageable.
  • Log removal was the most contentious point. The thread discussed whether log-injection attacks would become easier without instruction names. febo’s reply: logging itself costs 103 CUs per call — about 40 percent of a Transfer call — and programs should publish IDLs rather than rely on log-string matching.

The alternative strategy rejected in the PR thread: deploy in parallel at a new address with voluntary migration. The reasoning for rejection: adoption would be too slow, and many dApps would never switch. The feature-gate model guarantees universal activation.

Approval timeline: 31 January 2026 (topointon-jump from the Firedancer side), 13 March 2026 (bw-solana from Anza), merged the same day. Mainnet activation followed in epoch 971 on 13 May 2026.

What changes for classic SPL Token and Token-2022

P-Token implements exactly the surface of the classic SPL Token program under program ID TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA. That is the program on which USDC, USDT, BONK, JUP, and most token liquidity on Solana runs. According to Anza’s mainnet analysis, classic-token operations account for around 70 percent of all token calls on Solana.

Token-2022 is a separate program under program ID TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb. It offers the extension model with transfer fees, confidential transfers, interest-bearing mints, and so on — and it still builds on the old solana-program crate, not on Pinocchio.

Three reasons why only classic Token was rewritten:

  1. Classic Token is substantially more used — about 70 percent of all token operations. The leverage on network-wide block-CU efficiency is greatest here.
  2. Token-2022’s extension architecture is more complex. Each extension module (transfer hook, confidential transfer, interest-bearing) would need its own Pinocchio port.
  3. Stability: Token-2022 hosts MiCA-relevant features. Compliance tools, stablecoin audits, and institutional custodians depend on it. A Pinocchio rewrite would need to bring those stakeholders along simultaneously.

A roadmap for a P-Token-2022 variant exists. febo has said in his Anza blog interview that this is the most likely next request. There is no concrete timeline. The Pinocchio library pinocchio-tkn lists ConfidentialTransfer as “pending.” Additionally, the ZK ElGamal program is temporarily disabled on mainnet and devnet because of a security audit — the confidential-transfer extension is currently offline anyway.

Architectural implication: Solana gets, in the medium term, a two-speed world — performance-optimized base token (P-Token) and feature-rich premium token (Token-2022). When that converges again depends on Pinocchio maturity for extensions.

Impact on indexers and forensics

This is the painful part for tooling providers. P-Token removes the Instruction: Transfer-style logs entirely. Rationale: 103 CUs saved per call.

Concrete impact:

  • Helius webhooks matching on log patterns lose a signal. Helius recommends, in its P-Token article, switching to instruction-data decoding instead of log parsing. With the RPC methods parseTransactions and getTransactionHistory, you now have to inspect the discriminator byte at position 0 in the data buffer rather than the log string.
  • Triton getTransactionsForAddress still returns pre/postBalances correctly — the canonical PnL path stays intact.
  • Solscan and Solana Explorer display instruction names from the Token IDL — no user-facing break.
  • Custom indexers, such as private SQLite or Postgres pipelines, have to switch token-transfer detection from log matching to account-layout decoding. The account order in instructions is deterministic: source ATA at index 0, destination ATA at index 1, authority at index 2 for Transfer.

When do indexers typically catch up? At mainnet activation on 13 May 2026, the major providers (Helius, Triton, Solscan) already had pre-release builds ready. Rule of thumb: 72 hours after activation, the official RPCs are adjusted; one to two weeks are needed for smaller custom indexers. Anyone running custom webhook parsers should switch filters to instruction data now at the latest.

Impact on wallets and DeFi

Wallets immediately see lower fee estimates for token operations, because Solana prioritizes transactions by fee-per-CU. The effect on end users is marginal — you either pay less tip for the same slot, or you get top priority for the same tip amount. Since all SPL token transactions benefit, the relative advantage normalizes. A perceptible advantage emerges only once other transaction types — for example compute-heavy DeFi operations — use the freed block space.

DEXes concretely:

  • TransferChecked accounts for 36.33 percent of token program usage, according to SIMD-0266; Transfer for 13.22 percent. Both drop by 95 to 98 percent. A typical Raydium swap with two TransferChecked calls recovers around 12,000 CUs.
  • Orca Whirlpools benefit from range adjustments with two transfers and one burn — an estimated 13,000-CU saving per position adjustment.
  • Jupiter can integrate complex multi-hop routes with five to eight token touches into paths that previously failed against the 1.4-million-CU block limit.

Can dApps use the new instructions immediately? Technically yes; in practice three preconditions apply:

  • SDK updates — @solana/spl-token must recognize discriminators 255 (batch), 45 (unwrap_lamports), and 38 (withdraw_excess_lamports) as valid operations. The Solana Foundation SDKs have been ready since April 2026.
  • Wallet support — Phantom, Backpack, and Solflare need simulation and display support for batch. As of May 2026, Phantom and Backpack display batch calls correctly; Solflare still needs an update.
  • DEX-aggregator adoption — Jupiter is actively testing batch for multi-hop routes, with an estimated rollout in June 2026.

Network-wide performance math

The roughly 10-percent figure for block-CU share of the token program comes from Anza’s own mainnet analysis in the SIMD-0266 document. On a 48-million-CU block, classic SPL Token typically occupies around 4.8 million CUs. With the 95-percent reduction, that drops to about 240,000 CUs — under 0.5 percent.

Who validated the benchmarks independently?

  • Neodyme in the June-2025 audit plus mainnet replay: 8.9 to 9.14 trillion CU saved over eight days of mainnet replay.
  • Zellic in the June and October 2025 audits: equivalence tests, no explicit performance focus.
  • Helius in the Pinocchio article: confirmed 79 CUs for Transfer, 111 for TransferChecked.
  • Firedancer’s token.sbpf (repo): a pure sBPF-assembly token program with an “express” Transfer at 56 CUs. That is a comparison value, not production code. The Firedancer team validates P-Token’s numbers as a realistic Rust optimum.

Block-TPS impact: at around 3,000 token transactions per second on the mainnet average and an average saving of 4,500 CUs per transaction, around 13.5 million CUs per second are freed. That corresponds to potential headroom of around 9,000 additional simple transfers per second. Combined with Anza’s planned doubling of the block CU limit to 100 million CUs, this yields tangible TPS room.

Risks and open questions since activation

As of 14 May 2026, one day after mainnet activation, no critical bugs have been publicly reported. The main audit finding was an ownership-check assumption that could break under the new batch instruction — the older Token program could skip some owner checks because the runtime validated them at the end of the invocation anyway. With batch, multiple instructions are bundled into one invocation, which violates that assumption. The fix was pre-merge, no mainnet impact.

What operators should watch:

  • Validator requirement Agave v3.1.7 or newer — anyone not upgraded falls out of consensus. Stake distribution at epoch 971 was over 99 percent on compatible versions.
  • Tooling lag — smaller custom webhooks and private indexer stacks need one to two weeks to adapt.
  • batch misuse — new patterns can lead to unexpected atomicity assumptions. The Solana Foundation publishes best practices for dApp devs.

Formal verification is ongoing at Runtime Verification, with target completion in mid-May 2026, but it is not a blocker for activation.

What comes next

Short term (Q2 to Q3 2026):

  • p-ATA, a Pinocchio version of the Associated Token Account program, is in progress. The ATA program sits in the CPI path of every wallet onboarding and every DEX trade preparation — the savings would again be perceptible.
  • p-memo, a Pinocchio version of the Memo program, is close to deployment with 80 to 87 percent CU reduction.
  • Jupiter batch integration for multi-hop routes is scheduled for June 2026.
  • Wallet support for unwrap_lamports in Phantom and Solflare is pending.

Medium term (Q4 2026 and later):

  • P-Token-2022 — febo has said in the Anza blog that this is the most likely next big iteration. Harder because of the extension architecture.
  • Pinocchio for the System Program is mentioned in the Helius P-Token article as a long-term vision. That would lift compute efficiency across every Solana transaction.

Relationship to Firedancer: the Firedancer team prototyped its own sBPF-assembly token program, token.sbpf, with 56-CU Transfer, which is explicitly not intended for mainnet. Firedancer approved P-Token via topointon-jump and uses P-Token in consensus — no parallel token program. Firedancer validators thus run with the same P-Token bytecode as Agave validators.

Anchor replacement by Pinocchio? No. Both coexist. Anchor stays the default for rapid prototyping and team collaboration. Pinocchio is the choice for performance-critical production programs. Anza’s strategy is rather to make the SDK Pinocchio-aware step by step, so that type sharing between the frameworks becomes possible.

What this means for different roles

Validator operators: Agave v3.1.7+ is required. Anyone still on older versions in May 2026 has a problem. Otherwise the swap happens automatically through the feature gate.

Wallet holders: no action required. Token balances, transfers, and approvals continue to work as before. Fee estimates drop; power users notice this especially in high-frequency trading.

dApp developers: existing CPI calls continue to work. The new instructions (batch, unwrap_lamports, withdraw_excess_lamports) are opt-in, not mandatory upgrades. Anyone running close to performance CU budgets should price the new CU values into their allocations.

Indexers and forensic tools: log-based token activity tracking no longer works. Switching to instruction-data decoding is mandatory. Anyone running custom webhooks should parse the discriminator byte at position 0 of the instruction data buffer.

Forensics from the detective angle: account layouts stay 1:1 — ATAs, mints, multisigs remain readable as before. RPC methods like getTokenAccounts and getAccountInfo --output jsonParsed continue to work. What disappears is the ability to know what a transaction did from log patterns alone. Detective tools must add the instruction-data layer to their parsing.

What this means for you

P-Token is not an optional upgrade or an experimental feature — since May 2026 it is the foundation behind every USDC transfer, every DEX swap, and every wallet interaction on Solana. For end users nothing visible changes: tokens, balances, and transactions work exactly as before, just at lower compute cost. For developers and forensic tools it marks a clear break: anyone relying on log strings to detect token operations must switch to instruction-data decoding (parsing the raw bytes of a transaction). And for the network as a whole, P-Token opens up real headroom — for more complex DeFi routes, higher transaction throughput, and the next round of Pinocchio-based protocol upgrades.

Ready to put this into practice safely? This article explains the concept. For a structured, step-by-step path — wallet setup, security, staking, DeFi, and taxes — check out the Solana Guide.

Sources

Related SolanaHub content:

#solana #p-token #pinocchio #anza #spl-token #simd-0266 #performance