add pinocchio token-2022 mint-close-authority example#624
Conversation
Greptile SummaryThis PR adds a Pinocchio port of the Token-2022
Confidence Score: 5/5Safe to merge — the new Pinocchio example is self-contained, all three CPI payloads are correctly serialized, and the bankrun test exercises the full on-chain TLV layout. The hand-serialized Token-2022 instructions use the right byte counts, the hardcoded program-ID makes CPI targets unforgeable, and the test independently validates each field of the resulting mint account. No logic errors or missing checks found. No files require special attention. Important Files Changed
Sequence Diagram%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Client as Client (TS test)
participant P as Pinocchio Program
participant Sys as System Program
participant T22 as Token-2022 Program
Client->>P: CreateMint(decimals)
Note over P: parse CreateTokenArgs
P->>Sys: "CreateAccount(payer→mint, 202 bytes, owner=Token-2022)"
Sys-->>P: ok
P->>T22: InitializeMintCloseAuthority(variant 25, mint, close_authority)
T22-->>P: ok
P->>T22: InitializeMint(variant 0, mint, mint_authority, freeze_authority)
T22-->>P: ok
P-->>Client: ProgramResult::Ok
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant Client as Client (TS test)
participant P as Pinocchio Program
participant Sys as System Program
participant T22 as Token-2022 Program
Client->>P: CreateMint(decimals)
Note over P: parse CreateTokenArgs
P->>Sys: "CreateAccount(payer→mint, 202 bytes, owner=Token-2022)"
Sys-->>P: ok
P->>T22: InitializeMintCloseAuthority(variant 25, mint, close_authority)
T22-->>P: ok
P->>T22: InitializeMint(variant 0, mint, mint_authority, freeze_authority)
T22-->>P: ok
P-->>Client: ProgramResult::Ok
Reviews (3): Last reviewed commit: "test: strengthen token-2022 mint-close-a..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| it("Creates a Token-2022 mint with a close authority", async () => { | ||
| const decimals = 9; | ||
| const mintKeypair = Keypair.generate(); | ||
|
|
||
| const data = Buffer.from(borsh.serialize(CreateTokenArgsSchema, { token_decimals: decimals })); | ||
|
|
||
| const ix = new TransactionInstruction({ | ||
| programId: PROGRAM_ID, | ||
| keys: [ | ||
| { pubkey: mintKeypair.publicKey, isSigner: true, isWritable: true }, // mint account | ||
| { pubkey: payer.publicKey, isSigner: false, isWritable: false }, // mint authority | ||
| { pubkey: payer.publicKey, isSigner: false, isWritable: false }, // close authority | ||
| { pubkey: payer.publicKey, isSigner: true, isWritable: true }, // payer | ||
| { pubkey: SYSVAR_RENT_PUBKEY, isSigner: false, isWritable: false }, // rent sysvar | ||
| { pubkey: SystemProgram.programId, isSigner: false, isWritable: false }, // system program | ||
| { pubkey: TOKEN_2022_PROGRAM_ID, isSigner: false, isWritable: false }, // Token-2022 program | ||
| ], | ||
| data, | ||
| }); | ||
|
|
||
| const tx = new Transaction(); | ||
| tx.feePayer = payer.publicKey; | ||
| tx.recentBlockhash = context.lastBlockhash; | ||
| tx.add(ix); | ||
| tx.sign(payer, mintKeypair); | ||
| await client.processTransaction(tx); | ||
|
|
||
| const mintAccount = await client.getAccount(mintKeypair.publicKey); | ||
| if (mintAccount === null) throw new Error("Mint account not found"); | ||
| const mintData = Buffer.from(mintAccount.data); | ||
|
|
||
| // Owned by Token-2022, and sized for exactly one extension. | ||
| assert.deepEqual(mintAccount.owner.toBytes(), TOKEN_2022_PROGRAM_ID.toBytes()); | ||
| assert.equal(mintData.length, EXTENDED_MINT_SIZE); | ||
|
|
||
| // Base mint fields were initialized. | ||
| assert.equal(mintData[DECIMALS_OFFSET], decimals); | ||
|
|
||
| // The extension header marks this as a Mint carrying MintCloseAuthority. | ||
| assert.equal(mintData[ACCOUNT_TYPE_OFFSET], ACCOUNT_TYPE_MINT); | ||
| assert.equal(mintData.readUInt16LE(TLV_TYPE_OFFSET), MINT_CLOSE_AUTHORITY_EXTENSION); | ||
|
|
||
| // The configured close authority was stored in the extension. | ||
| const storedCloseAuthority = mintData.subarray(TLV_VALUE_OFFSET, TLV_VALUE_OFFSET + 32); | ||
| assert.deepEqual(new Uint8Array(storedCloseAuthority), payer.publicKey.toBytes()); | ||
|
|
||
| console.log("Mint address:", mintKeypair.publicKey.toBase58()); | ||
| }); |
There was a problem hiding this comment.
The test uses payer.publicKey for the mint authority, close authority, and payer simultaneously. This means the test cannot verify that the close authority stored in the TLV is correctly sourced from account index 2 (close authority) rather than index 1 (mint authority) or the payer — all three are identical addresses. A bug that swapped accounts 1 and 2 would go undetected. Using a distinct keypair for at least the close authority would make the assertion at line 87 meaningful.
There was a problem hiding this comment.
Good catch — fixed in 1b2f802. The test now generates a distinct closeAuthority keypair for account index 2, so the stored-authority assertion genuinely verifies the close authority is sourced from index 2 rather than the mint authority/payer (which remain payer).
| const TLV_TYPE_OFFSET = 166; // u16 LE, 3 == MintCloseAuthority | ||
| const TLV_VALUE_OFFSET = 170; // 32-byte close authority pubkey | ||
| const DECIMALS_OFFSET = 44; // in the base mint layout | ||
| const MINT_CLOSE_AUTHORITY_EXTENSION = 3; |
There was a problem hiding this comment.
The test validates TLV_TYPE_OFFSET (type = 3) and TLV_VALUE_OFFSET (close authority bytes), but never reads the 2-byte TLV length at offset 168 (TLV_TYPE_OFFSET + 2). Adding assert.equal(mintData.readUInt16LE(168), 32) would fully exercise the on-chain TLV header and catch any future change where Token-2022 alters the MintCloseAuthority value size.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Agreed — added assert.equal(mintData.readUInt16LE(168), 32) (TLV_LENGTH_OFFSET) in 1b2f802 so the 2-byte TLV length header is exercised explicitly.
| let [mint_account, mint_authority, close_authority, payer, rent_sysvar, _system_program, _token_program] = | ||
| accounts | ||
| else { | ||
| return Err(ProgramError::NotEnoughAccountKeys); | ||
| }; |
There was a problem hiding this comment.
_token_program (account index 6) is accepted and silently forwarded to all three CPIs as the callee program, but its address is never compared against TOKEN_2022_PROGRAM_ID. A caller that passes a spoofed program at index 6 would cause the CPIs to target an arbitrary program. For an educational example this is a known trade-off, but adding even a one-line equality check would demonstrate the secure pattern to learners.
There was a problem hiding this comment.
The premise here isn't quite accurate: _token_program (index 6) is not forwarded to the CPIs as the callee. Each InstructionView sets program_id: &TOKEN_2022_PROGRAM_ID — the hard-coded constant — and the account isn't even passed in the invoke infos slices (&[mint_account] / &[mint_account, rent_sysvar]). So a spoofed account at index 6 has no effect; the CPIs always target the real Token-2022 program by construction. Index 6 is present only to mirror the native example's account layout. No equality check is needed here since dispatch is already pinned to the constant.
There was a problem hiding this comment.
You're completely right — I was wrong. Both InstructionView structs hardcode program_id: &TOKEN_2022_PROGRAM_ID, and _token_program doesn't appear in either invoke accounts slice. A spoofed account at index 6 is entirely inert. Apologies for the noise.
Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.
|
Hi @Perelyn-sama — thanks again for merging my previous pinocchio examples! This one adds the |
Use a distinct close-authority keypair so the stored-authority check verifies sourcing from account index 2, and assert the TLV length field (32) explicitly.
MarkFeder
force-pushed
the
tokens-token-2022-mint-close-authority-pinocchio
branch
from
1b2f802 to
6a49f60
Compare
1 participant
Adds a Pinocchio port of the
tokens/token-2022/mint-close-authorityexample, alongside the existinganchorandnativeversions.What it does
A single instruction creates an SPL Token-2022 mint carrying the
MintCloseAuthorityextension, so a designated authority can later close the mint and reclaim its rent.Notes
Token-2022 has no Pinocchio wrapper crate (
pinocchio-tokentargets the legacy SPL Token program), so the Token-2022 instructions are built by hand and CPI'd:CreateAccountfor the mint, sized to202bytes (baseAccountlength 165 + account-type byte + oneMintCloseAuthorityTLV entry) and owned by the Token-2022 program.InitializeMintCloseAuthority(variant25) — must run before the mint is initialized.InitializeMint(variant0).The bankrun test asserts the resulting mint is owned by Token-2022, is exactly 202 bytes, has the correct decimals, and that the extension header (account type
Mint, TLV typeMintCloseAuthority) and stored close authority were written correctly.