SIMD-0266

TL;DR

Replace the current version of SPL Token (`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`) program by a CU-optimized one (`p-token`).

Summary

Replace the current version of SPL Token (`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`) program by a CU-optimized one (`p-token`).

Motivation

About `~10%` of block compute units is used by the Token program instructions. Decreasing the CUs used by Token program instructions creates block space for other transactions to be executed – i.e., less CUs consumed by Token program, more CUs for other transactions. As an example, if we reduce the CUs consumed by Token instructions to `1/20th` of their current value, `10%` of block CUs utilized becomes `0.5%`, resulting in a `9.5%` block space gain. Additionally, there are benefits to downstream programs: - Better composability since using the Token program instructions require less CUs. - Cheaper (in terms of CU) cross-program invocations.

Key Changes

• unwrap_lamports (instruction discriminator 45): allows transferring out lamports from native SOL token accounts directly to any destination account. This eliminates the need for creating temporary native token accounts for the recipient. The instruction supports transferring a specific amount or the entire amount of the account.
• Replace TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA program with ptok6rngomXrDbWf5v5Mkmu5CEbB51hzSCPDoj9DrvF using the Upgradable Loader v3.

Impact

The main impact is freeing up block CUs, allowing more transactions to be packed in a block; dapp developers benefit since interacting with the Token program will consume significantly less CUs. Below is a sample of the CUs efficiency gained by `p-token` compared to the current SPL Token program, including the percentage of CUs used in relation to the current SPL Token consumption — the lower the percentage, the better the gains in CUs consumption. | Instruction | spl token | p-token | % of spl-token | | ---------------------------- | --------- | ------- | -------------- | | `Approve` | 2904 | 124 | 4.2% | | `ApproveChecked` | 4458 | 164 | 3.6% | | `Burn` | 4753 | 126 | 2.6% | | `BurnChecked` | 4754 | 129 | 2.7% | | `CloseAccount` | 2916 | 120 | 4.1% | | `FreezeAccount` | 4265 | 146 | 3.4% | | `InitializeAccount` | 4527 | 154 | 3.4% | | `InitializeAccount2` | 4388 | 171 | 3.8% | | `InitializeAccount3` | 4240 | 248 | 5.8% | | `InitializeImmutableOwner` | 1404 | 38 | 2.7% | | `InitializeMint` | 2967 | 105 | 3.5% | | `InitializeMint2` | 2827 | 228 | 8.0% | | `InitializeMultisig` | 2973 | 193 | 6.4% | | `InitializeMultisig2` | 2826 | 318 | 11.2% | | `MintTo` | 4538 | 119 | 2.6% | | `MintToChecked` | 4545 | 169 | 3.7% | | `Revoke` | 2677 | 97 | 3.6% | | `SetAuthority` | 3167 | 123 | 3.8% | | `SyncNative` | 3045 | 61 | 2.0% | | `ThawAccount` | 4267 | 142 | 3.3% | | `Transfer` | 4645 | 76 | 1.6% | | `TransferChecked` | 6200 | 105 | 1.6% | Considering the usage distribution of instructions (shown below), migrating to p-token will significantly reduce the block CUs currently consumed by the token program. | Instruction | Usage (%) | | --------------------------- | --------- | | `TransferChecked` | `36.33%` | | `Transfer` | `13.22%` | | `CloseAccount` | `12.23%` | | `InitializeAccount3` | `9.98%` | | `InitializeImmutableOwner` | `9.78%` | | `SyncNative` | `4.53%` | | `InitializeAccount` | `2.58%` | Other instructions account for less than `1%` each.

Backwards Compatibility

Fully backwards compatible, no changes are required for users of the program. Note that we are proposing omitting instruction name logs (e.g., "Instruction: <name>") . ````

Security Considerations

`p-token` must be guaranteed to follow the same instructions and accounts layout, as well as have the same behaviour than the current Token implementation. Any potential risk will be mitigated by extensive testing and auditing: - ✅ **[COMPLETED]** Existing SPL Token test [fixtures](https://github.com/solana-program/token/blob/main/.github/workflows/main.yml#L284-L313) - ✅ **[COMPLETED]** Fuzzing using Firedancer tooling ([solfuzz_agave](https://github.com/firedancer-io/solfuzz-agave)): this includes executing past mainnet instructions — with or without random modifications amounting to millions of individual instructions — and verifying that the complete program output (i.e., both the program result and accounts' state) matches. - ✅ **[COMPLETED]** Audits - [Neodyme Audit (2025-06-12)](https://github.com/anza-xyz/security-audits/blob/master/spl/NeodymePTokenPinocchioAudit-2025-06-12.pdf) - [Zellic Audit (2025-06-30)](https://github.com/anza-xyz/security-audits/blob/master/spl/ZellicPTokenPinocchioAudit-2025-06-30.pdf) - [Zellic Audit (2025-10-13)](https://github.com/anza-xyz/security-audits/blob/master/spl/ZellicPTokenAudit-2025-10-13.pdf) - ⏳ *[IN PROGRESS]* Formal Verification Since there are potentially huge economic consequences of this change, the feature will be put to a validator vote. The replacement of the program requires breaking consensus on a non-native program. However, this has been done in the past many times for SPL Token to fix bugs and add new features.