program: Add `batch` instruction by abelmarnk · Pull Request #884 · solana-program/token-2022

abelmarnk · 2025-12-07T15:03:19Z

This PR adds the batch instruction to the token-2022 program, implementation drawn from here and originally proposed here.

The purpose is to allow the execution of multiple token instructions in a single program instruction – e.g., it is possible to execute multiple instructions in a single CPI call, which saves at least 1000 CUs (CPI base fee) for each additional instruction.

Scope

Update the TokenInstruction instruction variants(regular and POD) and associated tests
Add de/ser helper for the TokenInstruction variant
Update the processor code
Update the processor tests
Also adds program owner checks for all instructions

It closes #787.

abelmarnk · 2025-12-08T13:41:09Z

@joncinque, I didn't add client code because the main purpose of the instruction seems to be for use with CPI, would it still be better to add it in as an instruction that takes raw bytes as arguments?

abelmarnk · 2026-01-06T15:07:32Z

Hey @joncinque, following up on this.
Has there been a chance to review it yet? Thanks!

joncinque · 2026-01-09T12:39:58Z

Sorry for the late response, between Breakpoint and the holidays, we had a few other priorities unfortunately.

@febo can you take a look?

joncinque

Sorry for the slowness here, but looks great overall!

Just a few small points, and one huge point that someone (probably me) will need to go through all instructions to check for owner checks. Once that's done, we should be able to land this

joncinque · 2026-03-19T21:34:40Z

+    }
+
+    /// Deserialize the data for the Batch variant of the `TokenInstruction`
+    pub fn deserialize<'de, D>(d: D) -> Result<Vec<u8>, D::Error>


This return type made me go cross-eyed for a bit, since I've never seen a deserialize function that returns bytes, but in the context of TokenInstruction::Batch, it makes sense

joncinque · 2026-03-19T21:47:32Z

+    pub fn process_batch(
+        program_id: &Pubkey,
+        mut accounts: &[AccountInfo],
+        mut data: &[u8],
+    ) -> ProgramResult {


This looks correct, but as we have to do in p-token, we need to explicitly check ownership for any instructions that assume the runtime will do ownership checks at the end of the instruction: https://github.com/solana-program/token/blob/be42014b739dc8fbf7942f597d6ac736857896dd/pinocchio/program/src/processor/batch.rs#L49-L96

This will probably be a very painful process 🙃 We could add new cases for every successful instruction test, in which we hack the owner of all token accounts to another program, and see if the program returns an error, or if the runtime does.

If the runtime returns an error, we need to add an explicit ownership check.

Or we can just go one by one by hand and add check_program_account to all input accounts.

@febo any better ideas for how we can do this?

I wasn't sure about why those checks were there, the main instructions seem to fail immediately upon write attempt, the ones that reach the end of execution and then fail are Close and Withdraw Excess Lamports.

I assumed that for cases where we are writing into account and the account did not belong to the program then it should at least be in the same state that it was at the start of execution of the batch instruction, though the drawback would be that an instruction would allow for accounts that don't belong to it's program to pass of as if they did in a transaction explorer(though Reallocate and Withdraw Excess Lamports currently seems to allow for this).

The changes i made were to add checks for each non-extension instruction(i.e instructions that don't have full fledged sub processors) that the runtime returns an error for and leave the non-extension instructions that already had checks, since the extensions are not used as frequently and most already had program owner checks i added checks for all the rest(i.e the group extension, metadata extension...), i can make re-adjustments after further review if need be.

The batch checks were added here and the tests here, the other changes are in the different processor files.

Or we can just go one by one by hand and add check_program_account to all input accounts.

This seems a good approach.

joncinque · 2026-03-19T22:28:27Z

Also, can you rebase your branch when you get the chance?

joncinque

Thanks for addressing all the comments, this is really great work! I went over the whole program too, and confirm that all of the extension-related processor changes are good.

For the additional ownership checks, they're required with the batch instruction because it's possible to trick the token program otherwise.

For example, I can do initialize_account + + close_account, and the token program will happily write data to the new account, do things with it, and close it at the end of the batch instruction. With wrapped SOL accounts, this can become dangerous.

So with that in mind, let's add more explicit checks in processor.rs:

_process_initialize_mint (mint_info)
_process_initialize_account (new_account_info / mint_info)
_process_initialize_multisig (multisig_info)
process_transfer (mint_info)
process_approve (source_account_info / mint_info)
process_revoke (source_account_info)
process_set_authority (account_info)
process_close_account (source_account_info)
process_toggle_freeze_account (source_account_info, mint_info)
process_initialize_mint_close_authority (mint_account_info)
process_get_account_data_size (mint_account_info)
process_initialize_immutable_owner (token_account_info)
process_create_native_mint (native_mint_info)
process_initialize_non_transferable_mint (mint_account_info)
process_initialize_permanent_delegate (mint_account_info)
process_withdraw_excess_lamports (source_info)
process_unwrap_lamports (always check source_account_info)

joncinque

One last thing, then we can land this! Thanks for the quick turnaround on all these

joncinque · 2026-03-24T12:11:00Z

+        source_account.base.amount = remaining_amount.into();
+        if source_account_info.key != destination_account_info.key {
+            let source_starting_lamports = source_account_info.lamports();
+            **source_account_info.lamports.borrow_mut() = source_starting_lamports
+                .checked_sub(amount)
+                .ok_or(TokenError::Overflow)?;

-                let destination_starting_lamports = destination_account_info.lamports();
-                **destination_account_info.lamports.borrow_mut() = destination_starting_lamports
-                    .checked_add(amount)
-                    .ok_or(TokenError::Overflow)?;
-            }
-            Ok(())
+            let destination_starting_lamports = destination_account_info.lamports();
+            **destination_account_info.lamports.borrow_mut() = destination_starting_lamports
+                .checked_add(amount)
+                .ok_or(TokenError::Overflow)?;
        }


nit: This can now be put in a if amount !=0 { block

joncinque

This is good to go on my side! The audit failure will be addressed in #1060

@febo can you just give a quick look at the instruction implementation?

febo

Looks good – just have a question about the ordering of the owner checks.

febo · 2026-03-25T00:33:02Z

Are we ok with returning a different error? For example, a previous instruction that would fail to unpack the account data if an invalid account is passed, will now fail with an invalid owner.

Changing errors shouldn't make a difference, since it's impossible to recover from errors in CPI

But this will change errors for non-cpi calls as well, since the new checks are on the individual instructions.

Sure, but what impact can that have?

febo · 2026-03-25T00:37:41Z

        error,
        TokenClientError::Client(Box::new(TransportError::TransactionError(
-            TransactionError::InstructionError(0, InstructionError::InvalidAccountData)
+            TransactionError::InstructionError(0, InstructionError::IncorrectProgramId)


This is an example of the change that I mentioned about the ownership checks. Probably it is ok to return a different error. Alternatively, we could move the owner checks to be the last statement of the processor. We would still get a different error if the account is not owned by the program, but other validation checks will stay the same.

I see what you mean, but keeping the source code easier to read is more important in my opinion

joncinque · 2026-03-25T11:25:23Z

Thanks for your contribution! This will be a huge help

abelmarnk mentioned this pull request Dec 8, 2025

Feature proposal: batch instruction #787

Closed

abelmarnk marked this pull request as ready for review December 8, 2025 13:46

abelmarnk force-pushed the batch branch from 86443f9 to f1a1d9d Compare January 6, 2026 14:55

abelmarnk force-pushed the batch branch from f1a1d9d to 4d44983 Compare February 3, 2026 22:10

joncinque reviewed Mar 19, 2026

View reviewed changes

abelmarnk added 6 commits March 20, 2026 04:16

Add Batch instruction variants

030c146

Add Batch de/ser helpers

eb57a4c

Add Batch instruction processor

a0d6078

Add Batch instruction tests

2ef74ed

Review fixes - tests

4995d14

Review fixes - checks

d365a82

abelmarnk force-pushed the batch branch from 4d44983 to d365a82 Compare March 23, 2026 01:41

abelmarnk added 2 commits March 23, 2026 02:52

clippy fix

28b2a8a

nit

9bd82e4

joncinque reviewed Mar 23, 2026

View reviewed changes

Comment thread program/src/extension/token_metadata/processor.rs Outdated

Comment thread program/src/processor.rs Outdated

Review fixes II - checks

f0aa0d2

joncinque reviewed Mar 24, 2026

View reviewed changes

nit - II

3e6f68c

joncinque changed the title ~~Add batch instruction~~ program: Add batch instruction Mar 24, 2026

joncinque approved these changes Mar 24, 2026

View reviewed changes

febo reviewed Mar 25, 2026

View reviewed changes

joncinque merged commit 6ce35b6 into solana-program:main Mar 25, 2026
39 of 40 checks passed

Conversation

abelmarnk commented Dec 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

abelmarnk commented Dec 8, 2025

Uh oh!

abelmarnk commented Jan 6, 2026

Uh oh!

joncinque commented Jan 9, 2026

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abelmarnk Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

joncinque commented Mar 19, 2026

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joncinque left a comment

Choose a reason for hiding this comment

Uh oh!

febo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

joncinque commented Mar 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

abelmarnk commented Dec 7, 2025 •

edited

Loading

abelmarnk Mar 23, 2026 •

edited

Loading