Solana: batching token instructions with p-token

Documentation Index

Fetch the complete documentation index at: https://docs.chainstack.com/llms.txt

Use this file to discover all available pages before exploring further.

• p-token is a compute-optimized, drop-in rewrite of the SPL Token program. It runs at the same program ID, so your existing code and Chainstack endpoints already use it — a transfer now costs ~76 compute units instead of ~4,645.
• It adds a batch instruction that bundles several token operations into one token-program call.
• Batching only pays off through cross-program invocation (CPI): it amortizes the fixed per-CPI base cost across all the bundled operations.
• At the top level, batching is pure overhead — instructions there are already cheap, so send them separately.

​

What p-token changes

​

The batch instruction

• numberOfAccounts — how many accounts this sub-instruction consumes from the flat account list.
• dataLength — the byte length of the instruction data that follows.
• data — the raw token instruction bytes, including that instruction’s own discriminator.

​

What you can batch

• A batch itself — the batch instruction is not batchable, so no nesting.
• Associated token account (ATA) creation — the Associated Token Account program is a separate program that in turn calls the token program, so its instructions cannot be folded into a token-program batch. If you want account creation inside the same batch, create a plain token account (the System program’s create-account plus initializeAccount) rather than an ATA.

• The 255-account-reference limit — a single instruction can reference at most 255 accounts, and a batch counts accounts across all its sub-instructions (they are not deduplicated). Instructions that touch few accounts let you pack the most in.
• The ~1,232-byte transaction size — each sub-instruction’s header, data, and account references add up.

​

When batching pays off

• Two separate token CPIs — 2 × 1,000 base CU + 2 × operation cost.
• One batch CPI — 1 × 1,000 base CU + 2 × operation cost.

​

Batch via CPI in Rust

[dependencies]
pinocchio = "0.7"
pinocchio-token = "0.6"

use pinocchio::{account_info::AccountInfo, program_error::ProgramError, ProgramResult};
use pinocchio_token::instructions::{Batch, IntoBatch, Transfer};

pub fn process_swap(accounts: &[AccountInfo]) -> ProgramResult {
    let [src_a, dst_a, src_b, dst_b, authority, _rest @ ..] = accounts else {
        return Err(ProgramError::NotEnoughAccountKeys);
    };

    // Pre-allocate the batch buffers on the stack.
    // Data buffer = header_data_len(N) + sum of each sub-instruction's data size.
    // A Transfer is 9 bytes (1 discriminator + 8 amount); here N = 2.
    let mut data_buf = [core::mem::MaybeUninit::<u8>::uninit(); Batch::header_data_len(2) + 9 + 9];
    let mut ix_accounts_buf = [core::mem::MaybeUninit::uninit(); 6]; // 3 + 3 accounts
    let mut cpi_accounts_buf = [core::mem::MaybeUninit::uninit(); 4]; // unique accounts

    let mut batch = Batch::new(&mut data_buf, &mut ix_accounts_buf, &mut cpi_accounts_buf)?;

    // First transfer: src_a -> dst_a
    Transfer { from: src_a, to: dst_a, authority, amount: 1_000_000 }.into_batch(&mut batch)?;

    // Second transfer: src_b -> dst_b
    Transfer { from: src_b, to: dst_b, authority, amount: 500_000 }.into_batch(&mut batch)?;

    // One CPI for both transfers — the 1,000 CU base cost is paid only once.
    batch.invoke()
}

​

Build a batch instruction in TypeScript

npm install @solana-program/token @solana/kit

import { getBatchInstruction } from "@solana-program/token";

// Encode a Transfer sub-instruction: discriminator (3) + amount (u64 LE) = 9 bytes.
function encodeTransfer(amount: bigint): Uint8Array {
  const data = new Uint8Array(9);
  data[0] = 3; // Transfer discriminator
  new DataView(data.buffer).setBigUint64(1, amount, true);
  return data;
}

const batchIx = getBatchInstruction({
  data: [
    // Transfer uses 3 accounts: source, destination, authority.
    { numberOfAccounts: 3, instructionData: encodeTransfer(1_000_000n) },
    { numberOfAccounts: 3, instructionData: encodeTransfer(500_000n) },
  ],
});

// Attach the flat account list in sub-instruction order:
// [source1, destination1, authority1, source2, destination2, authority2]
// as the instruction's accounts, then add batchIx to your transaction message
// and send it through your Chainstack endpoint.

​

Caveats and gotchas

• No instruction-name logs — p-token does not emit the Program log: Instruction: Transfer lines the old program logged, because logging cost ~103 CU and was a large share of each instruction’s total. If you parse logsSubscribe output or Geyser streams, parse instruction data instead of instruction-name logs.
• Indexers must look inside batches — a batch is a single top-level instruction (discriminator 255) that hides its real operations as sub-instructions. To catch every transfer or mint, descend into discriminator-255 instructions and walk their sub-instructions; scanning only top-level instructions will miss anything bundled in a batch.
• 255-byte data cap per sub-instruction — the dataLength header is a single byte, so each bundled instruction’s data must be 255 bytes or less. Transfers (9 bytes) are far under this, but parameter-heavy instructions can approach it.
• Account ordering is positional — accounts are consumed in sub-instruction order from one flat list. A misordered list is a silent bug, not an error.
• Token-2022 has no equivalent — batch exists in p-token only. Token-2022 (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) is a separate program with no batch mechanism.

​

The other new instructions

• withdraw_excess_lamports — recovers SOL mistakenly sent to a mint or multisig account above its rent-exemption minimum, which the old program left stranded.
• unwrap_lamports — moves lamports directly out of a wrapped-SOL token account to a destination, without the create-and-close dance.

​

Additional resources

• Transferring SPL tokens on Solana — the single-transfer baseline batching builds on.
• Compute budget — set compute unit limits and prices for your transactions.
• Listening to programs using Geyser and Yellowstone gRPC — where the no-logs change matters most.
• SIMD-0266: efficient token program — the proposal behind p-token.
• solana-program/token — p-token source and the generated clients.