P-Token: Solana’s Next Big Efficiency Unlock

Many thanks to Febo, Jacob Creech, and 0xIchigo for reviewing earlier versions of this work.

Introduction

One of the less appreciated factors behind Solana’s rapid adoption is its safe, straightforward, and standardized approach to tokens. Unlike many other blockchains, creating a token on Solana does not require deploying a custom contract. Instead, everything runs through the heavily audited and battle-tested SPL token program (AKA Tokenkeg) originally deployed by Solana Labs. This approach makes common actions such as minting, burning, and transferring tokens trivial. Deploying a Solana token can be achieved with a single CLI command, for example.

The SPL Token Program is the most heavily used program on Solana (aside from the System program). Over the past six months, weekly creation of new fungible tokens through the SPL token program has averaged between 200,000 and 300,000. This represents a 20x increase over two years earlier in September 2023, when weekly new SPL token creations were regularly under 10,000. Overall, except for 2023, every year since Solana’s launch has recorded a significant increase in the number of new tokens issued, as shown by the chart below.

The growth in SPL token transfers has been even more pronounced. Over the past three months, weekly transfers have consistently exceeded 650 million, peaking at 867.8 million in late July. This peak represents a 17.5x increase from the low of 49.4 million weekly transfers recorded in early August 2023.

Enter P-Token

P-token is a compute-optimized, drop-in replacement for the current SPL Token program, first proposed by the Anza team in March through SIMD-0266: Efficient Token Program. It offers substantial reductions in compute unit (CU) usage while remaining fully backward compatible with existing SPL tokens. 

Because p-token mirrors the exact instruction set and account layouts of the SPL Token program, it can be swapped in as a direct substitute. This means p-token is not a new token standard. The client code continues to function exactly as before, ensuring that the transition unlocks significant efficiency gains while requiring no adjustments for applications or users.

The drive for adoption of p-token aligns with Solana’s broader push for greater program and framework efficiency, which complements work to increase the network’s capacity, most notably through the 2025 goal of doubling available block space.

The recent success of proprietary AMMs on Solana showcases the impact of lower compute costs and the advantages of highly efficient programs. For instance, oracle updates on platforms like HumidiFi have been hyper-optimized down to just 143 CUs. Doppler, a new open-source oracle program from BlueShift, brings costs down even further to just 21 CUs.

The p-token initiative has already garnered strong endorsements from leading ecosystem developers.

dr cavey phd ⏳

@cavemanloverboy

·Follow

the highest EV thing solana can do rn for markets is not MCP, 100M cu blocks, ACE, or any other of these big ideas it's p-token

9:25 PM · Aug 8, 2025

76

Reply

Copy link

Read 14 replies

Pinocchio

The “p” in p-token stands for Pinocchio, an optimized, performant, zero-dependency library for writing Solana programs developed by Anza. Pinocchio serves as a replacement for the standard solana-program crate, which makes extensive use of zero-copy types for handling instruction and account data. With zero-copy, data is not duplicated into new memory locations when read or written. Instead, the state is accessed directly through pointers. This design achieves significant compute savings by avoiding unnecessary memory operations, while also reducing runtime overhead.

Pinocchio is also no_std, meaning it does not rely on Rust’s standard library or heap allocations, since the Solana Virtual Machine (SVM) already provides the runtime environment. This further streamlines execution and reduces dependencies, ensuring leaner, faster programs.

Efficiency Gains

CUs measure the cost of execution in Solana’s runtime. The smallest operation, such as the addition of two integers or a bitwise operation, consumes 1 CU. Programs are capped at 200 thousand CUs per instruction and 1.4 million CUs per transaction.

P-Token delivers dramatic efficiency improvements, reducing CU consumption for standard SPL token transactions by roughly 95% (a 19x gain in efficiency). This faster execution translates to a smoother user experience, while freeing up compute allows more transactions to fit within each block, directly boosting network throughput.

Today, Token program instructions account for around 10% of block-wide CU usage. By cutting their cost to just 5% of current levels, p-token can lower that share from 10% to 0.5%, unlocking an additional 9.5% of block capacity for other transactions. P-token also benefits downstream programs, offering improved composability by reducing overall CU usage and lowering the cost of cross-program invocations (CPI).

Below is data detailing the CU efficiency gained by p-token instructions compared to the current SPL Token program in both chart and table form.

Another notable optimization, enabled largely by `no_std`, is the reduction of the program binary size from 131 KB down to 95 KB.

Additional Instructions

P-token proposes to add three new instructions (`withdraw_excess_lamports`, `batch`, and `unwrap_lamports`) to the token program not present in the original SPL token program.

Withdraw Excess Lamports

Similar to the current SPL Token-2022 implementation, `withdraw_excess_lamports` allows for the recovery of excess SOL “bricked” in the mint account. This usually happens when a user mistakenly sends lamports to the token mint account.

Withdrawal requires authorization from the mint authority, either the designated signer for standard mint accounts or the multisig for multisig accounts. Since most SPL tokens have their mint authority revoked, authorization can instead be provided by using the mint account itself as the signing authority, with the instruction signed by the mint’s private key.

Out of all SPL token mint accounts, ~869,000 hold more SOL than the minimum rent-exempt threshold of 0.0014616 SOL. Collectively, this amounts to 176,961.5 SOL locked inside token mint accounts, worth $36 million USD at today’s price. The largest amounts of SOL locked in token mint accounts are typically tied to memecoins, legacy tokens, and major blue-chip assets. The single largest amount of SOL locked within a token’s mint account is BOOK OF MEME ($BOME), a memecoin, with 6,328 SOL. The adoption of p-token would potentially allow for the unlocking of these balances, providing a windfall for the teams behind these tokens.

Batch

The second new instruction is `batch`, which streamlines CPI interactions with the p-token program. Instead of invoking the token program multiple times, `batch` allows a variable number of token instructions to be executed within a single call. This means the base CPI cost of 1,000 units is incurred only once, rather than for each individual instruction.

The result is a substantial reduction in compute usage for protocols that rely on multiple token CPIs in a single instruction, a common pattern across Solana DeFi. For instance, an AMM might perform two transfers in a swap, or a liquidity pool deposit might involve both transfers and mints. By using `batch`, programs can achieve meaningful CU savings in these scenarios.

Unwrap Lamports

The `unwrap_lamports` instruction (recently added in a separate PR) enables direct transfers of lamports to a destination account, removing the need to create temporary native token accounts.

Previously, unwrapping lamports from a wrapped SOL account required creating and then closing an associated token account (ATA) for the recipient. With this update, lamports can now be directly transferred out from native SOL accounts, simplifying the process.

Fast Path for Transfer Instructions

Analysis of mainnet token program usage shows a strong concentration around transfer instructions, which together make up nearly half of all activity. The five most frequently used instructions are:

• transfer_checked (36.33%)
• transfer (13.22%)
• close_account (12.23%)
• initialize_account3 (9.98%)
• initialize_immutable_owner (9.78%)

This usage pattern highlights an opportunity to further optimize p-token for transfers and reduce CU consumption. Much of this optimization work was contributed by Cavey of Temporal (for a deeper dive into the approach, see his X livestream).

To achieve these gains, p-token introduces a custom entrypoint with a fast-path for transfer instructions and updates the processor to prioritize `sync_native` and `initialize_immutable_owner`. Together, these changes deliver significant CU efficiency improvements in line with observed usage patterns.

Logging

With the introduction of p-token, one open question is whether to retain the current logging behavior. The latest proposal version recommends removing logs. On Solana, logs are the primary mechanism for extracting debugging, monitoring, and event data from programs. In the existing token program, logs are minimal, limited to printing the instruction name being executed. For example:

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

However, this seemingly small log line `Instruction: <name>` costs roughly 103 compute units. In practice, that overhead can account for nearly as much compute as the instruction itself. For instance, logging accounts for approximately 40% of the total compute required for a simple transfer.

Beyond their cost, these logs aren’t always reliable; they can be truncated or manipulated through log injection, which risks misleading downstream parsers. On the other hand, removing them entirely could break workflows for developers and applications that currently depend on their presence.

Eliminating logs would increase the importance of teams publishing IDLs to provide visibility into program behavior. Anchor, for example, now enforces this by publishing IDLs for all new programs by default, unless explicitly disabled.

Auditing

Auditing of the p-token program is already underway to ensure full backwards compatibility and security. For p-token to be adopted, it must strictly adhere to the exact instructions and account layouts of the current Token program, precisely replicating its behavior. Any deviation would pose a risk, which is being addressed through extensive testing and independent audits.

Auditors Neodyme conducted equivalence testing by replaying every mainnet transaction from recent months twice, once using the original token program and once using p-token. The results confirmed identical outputs while also demonstrating significant CU savings.

According to their analysis, between August 3 and August 11, 2025, p-token would have reduced overhead by 8.9 trillion CUs with logging enabled, and 9.14 trillion CUs with logging disabled. These figures represent savings of 12.0% and 12.3% of total blockspace usage, respectively.

P-token is currently undergoing a second audit by Zellic and formal verification by Runtime Verification.

Rollout

The planned rollout process for p-token follows a staged approach. It begins with the completion of the audit, fuzzing, and formal verification. This is followed by a validator governance vote on the adoption of p-token and the formal acceptance of SIMD 266. After that, the p-token feature will be deployed to the cluster and placed behind a feature gate.

The program will first be deployed to a designated account (ptokN…UkkZ2). Once the feature gate is activated on the epoch boundary, the runtime across all validators will replace the existing token program (Tokenkeg…VQ5DA) with the new implementation, using the Upgradable Loader v3.

An alternative approach would be to deploy the p-token program to a new address, requiring users and applications to manually migrate. However, this path is not preferred, as it would likely hinder adoption and diminish the overall benefits, given that many users would be hesitant or slow to make the switch.

Economic Impact

The adoption of p-token is part of a roster of improvements poised to dramatically expand Solana’s overall capacity, allowing for more transactions to be packed into each block. Other notable upgrades include doubling blockspace to 100 million CUs and raising the per-account CU limit from a fixed 12 million to 40% of the block.

Currently, a single account is limited to 12 million CUs per block. As shown in the chart below from Anza, the most contested account in each block frequently reaches this cap. P-token alone will make it harder for accounts to reach this limit, reducing the frequency of bottlenecks for hot state.

Nearly all transactions today include either a priority fee or a Jito tip to incentivize validators to include them in a block. Since priority is determined by fee per CU, a p-token transaction, consuming fewer CUs, should, all else being equal, receive higher priority for the same fee or tip. That said, because all SPL token transactions will benefit from the p-token upgrade, the overall impact on transaction prioritization remains to be seen.

Conclusion

The adoption of p-token, assuming it passes a governance vote, represents a major step forward in improving the efficiency and scalability of Solana. By drastically reducing compute usage and streamlining CPI interactions, it strengthens the foundation of the network’s most used program while also expanding overall block capacity. If successful, p-token could serve as a blueprint for developing Pinocchio-optimized versions of other widely used programs, such as the Associated Token Account (ATA) program and even the System program, paving the way for a faster, more efficient runtime.

Further Resources

• p-token repository - GitHub
• Pinocchio repository - GitHub
• Solana Program Library (SPL) - GitHub
• p-Token SOL Savings Calculator - SendAI