Token2022 suppport for buffers instructions by kaze-cow · Pull Request #120 · cowprotocol/solana-programs

kaze-cow · 2026-08-26T05:41:38Z

Adds the most basic level of Token-2022 support which widens the accepted token programs and focuses on dealing with the edge cases of CreateBuffers and ReclaimBuffers.

What changes

CreateBuffer and ReclaimBuffer each take a token_program account and, until now, rejected anything that wasn't the legacy SPL Token program. They now accept Token-2022 too and issue all of their CPIs — InitializeAccount3, CloseAccount — against whichever of the two they were handed.

Token2022 accounts may have dynamic length. Previously, a buffer could only hold 165 bytes (the length of SPL token account), but now it is now allocated at the length its mint actually needs. GetAccountDataSize is used to verify the length of the token required before creating it.

For CreateBuffers creation of token accounts, We looked into the possibility of making the account longer than it needs to be and then shrinking it, but this doesn't work well because a extra CPI call is necessary to shrink the account back down to the correct size. But this requires a CPI call to Reallocate on the token program, and that is more expensive than just getting hte length.

There is an early return on token_account_len which allows for skipping the GetTokenAccountLength CPI call. We originally did the early return if the Mint size was th ebase size (the logic being that a base size mint is either a canonical SPL token OR a token2022 mint with no required extensions), but since the vast majority of token2022 mints DO actually have extensions, there is very little benefit in having this broader check. So we decided to only do the early return for SPL tokens.

Library Handling Changes

spl-token-2022-interface = "3", a library published by anza-team, and pinocchio-token-2022 = "0.4", another library published by anza-team, are added for hopefully obvious reasons.

~~spl-token-interface was removed from the settlement program because it is no longer needed (later it will also be removed from test-cli, eliminating it as a direct dependency from the repo).~~ ended up being re-added after adding new tests because apparently a lot of mint creation utilities need to be recreated without it.

pinocchio-token is bumped to 0.7 in order to gain access to the invoke_with_unverified_program(token_program) instruction builder function (prior to this release, there was no way to specify an alternative program). Its also the version that pinnochio-token-2022 transitively depends on.

Most of the functions in both pinnochio-token and pinnochio-token-2022 are close to identical. For now most of the interfaces continue to use pinnochio-token because we never actually work with token 2022 tokens directly and the interfaces usually have slightly less dependencies (ex. not specifying the extension information).

Out of Scope

BeginSettle / FinalizeSettle require a different methodology to support simultaneous settlement from both token programs, so those follow in #128.

test-cli is covered separately in #134 .

The integration tests for both this PR and #128 are in #121, as we want to expand coverage with 2022 across as many tests as possible.

At this time, only one token program can be supplied to the buffer functions. Two separate calls to CreateBuffers is required if it is necessary to create buffers for tokens on two separate prgorams.

Compute cost

bench-report.json is regenerated. The buffer instructions shift by roughly +0.2% to +0.4% from the added dispatch (reclaim_buffer/max_buffers_in_one_instruction 136,501 → 137,046 is the largest); the one- and two-unit drift on the unrelated settle and transfer-authority lines is codegen, not behaviour.

Test Plan

Verify the methodology. In particular, it would be good to verify the library dependency status as described above, because it is a bit awckward.

🤖 Generated with Claude Code

linear-code · 2026-08-26T05:41:41Z

SC-153

socket-security · 2026-08-26T05:41:56Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pinocchio-token-2022@0.4.0
	spl-token-2022-interface@3.1.1
	pinocchio-token@0.6.0 ⏵ 0.7.0

View full report

`CreateBuffer` and `ReclaimBuffer` each took a `token_program` account and rejected anything that wasn't the legacy SPL Token program. They now accept Token-2022 as well and issue all of their CPIs against whichever of the two they were handed, so a buffer can be allocated, initialized and closed under either. Token-2022 encodes the instructions this program issues exactly as the legacy program does, so only the CPI target changes. Two things do differ: - Account data. A Token-2022 account carrying extensions is longer than the base layout, so the legacy reader (exact length, legacy owner) rejects it. `token::read_token_account` dispatches on the validated program and reads by value, which also drops the borrow before `ReclaimBuffer` closes the same account. - Buffer sizing. A buffer now gets the length its mint actually needs: a mint with no extension data keeps the base layout, and anything longer is priced by asking the token program via `GetAccountDataSize`, the way the associated-token-account program does. That keeps the answer authoritative at run time rather than freezing a mint-extension-to-account-extension table into the program. The program account is shared by the whole instruction, so the mints one instruction touches must all live under the same token program; splitting a mixed batch across two instructions is the caller's job. Adds `SettlementError::BufferSizeUnavailable` (35), reachable only defensively: a token program that fails the size query aborts the instruction on its own. `BeginSettle` and `FinalizeSettle` keep rejecting everything but the legacy program; Token-2022 for the settlement pair follows separately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`spl-token-interface` was a dependency of the interface crate for one thing: a 32-byte constant naming a program this code never calls directly. `spl-token-2022-interface` already carries that address in `inline_spl_token`, which exists precisely so a program that has to recognize both doesn't grow a second dependency for the one it only compares against. Both ids now come from there, and the legacy crate leaves the interface crate's dependency graph -- and with it the settlement program's. `instruction::settle` re-exported the same id straight from the legacy crate, so it moves to `token_program` too. That was the second import keeping the dependency alive, not a cosmetic change. The `.so` is byte-identical at 51,056 bytes: the constant was already inlined, so this narrows the dependency graph rather than the program. The program crate keeps `pinocchio-token`. Its state readers are not parameterized over the token program the way 0.7's instruction builders are -- `pinocchio_token_2022::state::Account` hardcodes an owner check against Token-2022 in all of its safe constructors -- so reading a legacy account without it means `from_bytes_unchecked` plus hand-rolled owner and length checks, in exchange for a crate `pinocchio-token-2022` depends on anyway. `test-cli` keeps the legacy crate as well. It talks to no other program, and the two crates' `native_mint` are different addresses, so swapping them there is a change to make deliberately rather than in passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…2-program

should work on interface as well as the program itself. that was almost bad!

The CLI's token resolution now has to know which token program owns a mint, which is a self-contained change with its own tests; it lands separately. All that stays here is the one field `CreateBuffers` gained, pinned to the legacy program, and the workspace entry for the legacy interface the CLI still builds against. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fedgiac

Design review. Overall, I agree it makes sense to use the token slot as a discriminant and only allow to bundle buffer creations for the same token program in a single instruction.

Nit: when evaluating an Anza dependency in the description, don't point at crates.io, whose content can easily be faked. Point to the GitHub repo by Anza with the Cargo.toml showing the right package name.
https://github.com/anza-xyz/pinocchio/blob/main/programs/token-2022/Cargo.toml#L2

fedgiac · 2026-08-31T16:45:01Z

Literally no integration test covers the token 2022 path, which is imho a very bad idea.
I see this is annoying to test properly. We should also try doing something interesting, like adding some random extension. I suppose this could be new files, just to separate the two? Not sure at this point.

Literally no integration test covers the token 2022 path, which is imho a very bad idea.
I see this is annoying to test properly. We should also try doing something interesting, like adding some random extension. I suppose this could be new files, just to separate the two? Not sure at this point.

this was intentional! see Out of scope and #121

Sorry I missed that when reading the description. The approach makes sense. Would it be possible to create a new PR with only the tests for this PR so we can confirm everything works before building on top? It's also easier to think about the macro then.

fedgiac

It makes sense overall. While reviewing this PR I vibed-researched how token2022 and extensions are used, maybe you want to take a look but it doesn't change this PR I'd say.
There should be tests for a few critical cases: mint close and reopen with different extension; mint close and reopen as legacy token; trying to recover a buffer in the two cases before (should be possible according to my vibed tests). Also see comment on tests. The only thing I don't understand at this point in the current code is token_account_len, will look again after the comments are answered; I think there are a lot of tricky details hiding in there and I want to ask before going down the path of reading the token2022 program code.

fedgiac · 2026-09-02T20:05:19Z

Sorry I missed that when reading the description. The approach makes sense. Would it be possible to create a new PR with only the tests for this PR so we can confirm everything works before building on top? It's also easier to think about the macro then.

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

…ol/solana-programs into kaze/sc-153-token-2022-program

fedgiac · 2026-09-04T12:04:33Z

+    /// The base layout is the same under both programs, so one reader's idea of
+    /// its length is the other's too.
+    #[test]
+    fn both_programs_share_the_base_layout_length() {


Nit: this test is testing the test functions themselves and not the program. I like to use the term "sanity checks" in these cases to make sure that it's intentional that the test doesn't need to touch the program.

Suggested change

fn both_programs_share_the_base_layout_length() {

fn sanity_check_both_programs_share_the_base_layout_length() {

fedgiac · 2026-09-04T13:05:18Z

 }

+/// Seed the wrapped-SOL mint account, which `LiteSVM` does not create.
+pub fn create_native_mint(svm: &mut LiteSVM) {


Nit: unused function.

fedgiac · 2026-09-04T13:31:54Z

+        // Extensions are preceded by the account-type marker, which is what
+        // distinguishes a longer account from a mint of the same size.
+        data.push(AccountType::Account as u8);
+        data.extend_from_slice(&[0xab; 16]);


As commented before: let's avoid hand-rolling our own encoding for things that we don't control. What I'm expected to do here as a reviewer is determining that this block of code is equivalent to enabling a token extension and not just adding some arbitrary data bytes to the end of an account (and to certify that the risk of drift is minor). The imho better alternative is actually building a token with an extension using a library.
In any case, it would be a great help to have a link that shows this is the standard way to define extensions so I don't need to redo the independent research you already had to do.

fedgiac · 2026-09-04T13:54:14Z

+//! Token-program validation and token-account reads
+
+use cow_settlement_interface::{
+    token_program::TokenProgram::{self, SplToken},


Nit: I found this a bit confusing because AI likes to generate matches like:

match token_program { SplToken => ... TokenProgram::Token2022 => ...

I think it looks better to always use the full form for both throughout the code.

Suggested change

token_program::TokenProgram::{self, SplToken},

token_program::TokenProgram,

fedgiac · 2026-09-04T14:01:35Z

+    // Early return for SPL token (saves the GetAccountDataSize CPI call)
+    if token_program == SplToken {
+        return Ok(BASE_TOKEN_ACCOUNT_LEN);
+    }
+
+    let token_program = token_program.address();
+    // SPL token provides a function to get the actual required account data size
+    GetAccountDataSize::new(mint).invoke_with_unverified_program(&token_program)?;
+
+    let reported = get_return_data().ok_or(SettlementError::BufferSizeUnavailable)?;
+    if reported.program_id() != &token_program {
+        return Err(SettlementError::BufferSizeUnavailable.into());
+    }
+    let length: [u8; 8] = reported
+        .as_slice()
+        .try_into()
+        .map_err(|_| SettlementError::BufferSizeUnavailable)?;
+    let length = u64::from_le_bytes(length);
+
+    Ok(length)


(A bit of a nit.) The code makes sense as it's written but I struggled a lot to understand it so I'm suggesting a rewriting of it that should make it easier in the future to verify the logic. I searched a lot for ways not to use the length and, surprisingly to me, I couldn't find any

Suggested change

// Early return for SPL token (saves the GetAccountDataSize CPI call)

if token_program == SplToken {

return Ok(BASE_TOKEN_ACCOUNT_LEN);

}

let token_program = token_program.address();

// SPL token provides a function to get the actual required account data size

GetAccountDataSize::new(mint).invoke_with_unverified_program(&token_program)?;

let reported = get_return_data().ok_or(SettlementError::BufferSizeUnavailable)?;

if reported.program_id() != &token_program {

return Err(SettlementError::BufferSizeUnavailable.into());

}

let length: [u8; 8] = reported

.as_slice()

.try_into()

.map_err(|_| SettlementError::BufferSizeUnavailable)?;

let length = u64::from_le_bytes(length);

Ok(length)

match token_program {

// SPL token accounts are always the base length, so skip the CPI.

TokenProgram::SplToken => Ok(BASE_TOKEN_ACCOUNT_LEN),

// Token-2022 accounts vary with the mint's extensions. This mirrors the

// SPL Associated Token Account program's `get_account_len`:

// https://github.com/solana-program/associated-token-account/blob/2dc55ee1009d787eea7e1c401b8f27e6892bff4b/program/src/tools/account.rs#L72-L97

TokenProgram::Token2022 => {

GetAccountDataSize::new(mint)

.invoke_with_unverified_program(&TokenProgram::Token2022.address())?;

get_return_data()

.ok_or(SettlementError::BufferSizeUnavailable.into())

.and_then(|reported| {

if reported.program_id() != &TokenProgram::Token2022.address() {

return Err(SettlementError::BufferSizeUnavailable.into());

}

reported

.as_slice()

.try_into()

.map(u64::from_le_bytes)

.map_err(|_| SettlementError::BufferSizeUnavailable.into())

})

}

}

fedgiac · 2026-09-04T14:10:46Z

+            Self::CloseAuthorityOnly => &[],
+            Self::WithNonTransferable => &[
+                ExtensionType::NonTransferableAccount,
+                ExtensionType::ImmutableOwner,


Why is this needed?

fedgiac · 2026-09-04T14:36:41Z

+/// The extension set a test mint is created with.
+#[derive(Clone, Copy, Debug)]
+pub enum Extensions {
+    CloseAuthorityOnly,
+    /// Non-transferable + CloseAuthority
+    WithNonTransferable,
+    /// Transfer Fee + CloseAuthority
+    WithTransferFee,
+}
+
+impl Extensions {
+    /// The extensions the mint itself is initialized with.
+    fn mint(self) -> &'static [ExtensionType] {
+        match self {
+            Self::CloseAuthorityOnly => &[ExtensionType::MintCloseAuthority],
+            Self::WithNonTransferable => &[
+                ExtensionType::MintCloseAuthority,
+                ExtensionType::NonTransferable,
+            ],
+            Self::WithTransferFee => &[
+                ExtensionType::MintCloseAuthority,
+                ExtensionType::TransferFeeConfig,
+            ],
+        }
+    }
+
+    /// The extensions Token-2022 requires of a token account holding the mint.
+    /// Spelled out rather than derived from [`Self::mint`], so the length a test
+    /// expects is stated independently of the program's own bookkeeping.
+    fn token_account(self) -> &'static [ExtensionType] {
+        match self {
+            Self::CloseAuthorityOnly => &[],
+            Self::WithNonTransferable => &[
+                ExtensionType::NonTransferableAccount,
+                ExtensionType::ImmutableOwner,
+            ],
+            Self::WithTransferFee => &[ExtensionType::TransferFeeAmount],
+        }
+    }
+


Nit: it feels that it would be a better design if Extensions was a vec of ExtensionType, the vec was created in-place in the relevant tests, and mint just returns the elements of the vec.
Then it becomes clear that token_account is a limited reimplementation of ExtensionType::get_required_init_account_extensions with hardcoded values. If you hardcode values, please provide a link for me to verify them.

The caveat: ExtensionType::get_required_init_account_extensions needs #[allow(deprecated)] (and imho deprecating that was bad design; I'm fine with using the deprecated one here). Alternatively, we inline it and vendor required_init_account_extensions (which is private unfortunately), with a link that allows me to verify that it's a 1-to-1 copy for that version.

fedgiac · 2026-09-04T14:38:28Z

+/// Create a Token-2022 mint at `mint`'s address carrying `extensions`, with
+/// `payer` as both its mint authority and its close authority, and return the
+/// address. Taking the keypair rather than generating one lets a test close the
+/// mint and put something else back at the same address.
+pub fn create_mint(
+    svm: &mut LiteSVM,
+    payer: &Keypair,
+    mint: &Keypair,
+    extensions: Extensions,
+) -> Pubkey {


fedgiac · 2026-09-04T14:40:28Z

+    extensions: Extensions,
+) -> Pubkey {
+    let space = ExtensionType::try_calculate_account_len::<Mint>(extensions.mint())
+        .expect("every mint extension used here has a fixed length");


I was super surpised by this. It implies that there are mint extensions with variable length.
This isn't true: this can only fail if the input has repeating extensions.

fedgiac

Nice, end of comments! Looks solid.

fedgiac · 2026-09-04T14:48:38Z

+#[test]
+fn sizes_a_token_2022_buffer_to_the_extensions_its_mint_forces() {
+    let (mut svm, program_id, payer) = common::setup();
+
+    for extensions in [
+        Extensions::CloseAuthorityOnly,
+        Extensions::WithNonTransferable,
+        Extensions::WithTransferFee,
+    ] {


Looks good! Linking to a previous comment: here Vecs would be fine imho.

fedgiac · 2026-09-04T14:50:29Z


+/// Set up a Token-2022 mint with a close authority and its buffer, then close
+/// the mint so `reopen` can claim the address. Returns the mint and its buffer.
+fn buffer_whose_mint_was_reopened(


Nice tests!

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

kaze-cow mentioned this pull request Aug 26, 2026

Verify Token-2022 settlement against the relevant test suite wholistically #121

Open

kaze-cow force-pushed the kaze/sc-153-token-2022-program branch from 3ef114e to aa75ae4 Compare August 28, 2026 07:22

kaze-cow mentioned this pull request Aug 28, 2026

Support Token-2022 in BeginSettle and FinalizeSettle #128

Open

kaze-cow changed the title ~~Support Token-2022 in every token-moving instruction~~ Support Token-2022 in CreateBuffer and ReclaimBuffer Aug 28, 2026

kaze-cow and others added 6 commits August 28, 2026 17:23

Merge remote-tracking branch 'origin/main' into kaze/sc-153-token-202…

50b05b1

…2-program

fixes from final manual review

881178b

switch fully away from legacy spl interface

d690f26

fix inconsistencies in token program support

a056888

should work on interface as well as the program itself. that was almost bad!

kaze-cow self-assigned this Aug 31, 2026

kaze-cow mentioned this pull request Aug 31, 2026

Support Token-2022 in the test CLI #134

Draft

kaze-cow changed the title ~~Support Token-2022 in CreateBuffer and ReclaimBuffer~~ Add Basic Level of Token 2022 Support Aug 31, 2026

Merge branch 'main' into kaze/sc-153-token-2022-program

a25598c

kaze-cow marked this pull request as ready for review August 31, 2026 16:38

kaze-cow requested a review from a team as a code owner August 31, 2026 16:38

fedgiac reviewed Aug 31, 2026

View reviewed changes

kaze-cow added 7 commits September 1, 2026 19:14

switch to using an enum based approach, which seems clean

4ed9541

idl update

5fd2f6a

remove the unnecessary early return which skips the length CPI

7836f89

update documentation and design

421a926

update tests

ce75edf

fix undo changes and lint

88b1c48

fix bench

90a8783

kaze-cow requested a review from fedgiac September 1, 2026 15:39

fedgiac reviewed Sep 2, 2026

View reviewed changes

Update programs/settlement/src/token.rs

1d5ac46

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

kaze-cow and others added 9 commits September 3, 2026 14:50

Update Cargo.toml

08fc979

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

Update programs/settlement/src/reclaim_buffer.rs

b427f49

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

Update programs/settlement/tests/common/token.rs

a091047

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

Update interface/src/token_program.rs

641c08c

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

use new tokenprgoram enum in client instructions

e3ccd22

switch to using tokenProgram in the client caused other changes

1d2106b

remove the check

ada2e5a

remove superfluous test

1194762

Merge branch 'main' into kaze/sc-153-token-2022-program

5a86bce

kaze-cow changed the title ~~Add Basic Level of Token 2022 Support~~ Token2022 suppport for buffers instructions Sep 3, 2026

kaze-cow added 3 commits September 4, 2026 15:59

Merge branch 'kaze/sc-153-token-2022-program' of github.com:cowprotoc…

fbe9396

…ol/solana-programs into kaze/sc-153-token-2022-program

refactor base_layout to use the actual encoder, and rename for clarity

f74498b

update test and spl token mint behavior

2907aaa

kaze-cow requested a review from fedgiac September 4, 2026 07:17

add some tests for wierd edge cases with recreating mints

62776ff

kaze-cow force-pushed the kaze/sc-153-token-2022-program branch from 5db26f2 to 62776ff Compare September 4, 2026 13:12

kaze-cow added 2 commits September 4, 2026 22:14

Merge branch 'main' into kaze/sc-153-token-2022-program

3f1aa2b

fix idl

00312df

fedgiac reviewed Sep 4, 2026

View reviewed changes

Update programs/settlement/tests/common/token_2022.rs

3c8a10c

Co-authored-by: Federico Giacon <58218759+fedgiac@users.noreply.github.com>

	fn both_programs_share_the_base_layout_length() {
	fn sanity_check_both_programs_share_the_base_layout_length() {

	token_program::TokenProgram::{self, SplToken},
	token_program::TokenProgram,

Uh oh!

Conversation

kaze-cow commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes

Library Handling Changes

Out of Scope

Compute cost

Test Plan

Uh oh!

linear-code Bot commented Aug 26, 2026

Uh oh!

socket-security Bot commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fedgiac left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

fedgiac left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

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!

fedgiac 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

kaze-cow commented Aug 26, 2026 •

edited

Loading

socket-security Bot commented Aug 26, 2026 •

edited

Loading