add pinocchio pda-mint-authority example

[MarkFeder]

Adds a Pinocchio port of the tokens/pda-mint-authority example, alongside the existing anchor and native versions.

What it does

A program-derived address — not a wallet — is the mint and freeze authority for every NFT this program creates. Three instructions, dispatched by a leading discriminator byte (matching the native MyInstruction enum):

• Init (0) — creates the mint-authority PDA ([b"mint_authority"]), signed by its own seeds, and persists the canonical bump in the account.
• Create (1) — creates a 0-decimal SPL mint whose authority is the PDA, then attaches a Metaplex metadata account via a hand-rolled CreateMetadataAccountV3 CPI. The metadata CPI is authorized with the PDA's seeds via invoke_signed.
• Mint (2) — creates the payer's associated token account (idempotent), mints the single token, then creates the master edition via a hand-rolled CreateMasterEditionV3 CPI (max_supply = Some(1)). Both the MintTo and master-edition CPIs are signed by the PDA.

The new building block here versus the other token examples is PDA-as-signer: Init, the metadata CPI, the MintTo, and the master-edition CPI all sign as the PDA using pinocchio::cpi::{Seed, Signer} and invoke_signed, rather than relying on a wallet signature. The bump recorded by Init is read back from the PDA account to rebuild the signer seeds without re-deriving the address on-chain.

Tests

tests/test.ts runs under solana-bankrun, loading the program plus the Token Metadata program (dumped from mainnet into tests/fixtures by prepare.mjs). Three cases:

• Init asserts the PDA account is owned by the program and stores the expected bump.
• Create asserts the mint is owned by the Token program and the metadata account is owned by Token Metadata and contains the NFT name.
• Mint asserts the ATA holds exactly 1 token and the master edition account exists and is owned by Token Metadata (proving the PDA-signed CreateMasterEditionV3 CPI succeeded).

[greptile-apps]

Greptile Summary

Adds a Pinocchio implementation of the PDA mint-authority NFT example.

• Implements Init, Create, and Mint instructions with PDA-signed system, token, associated-token, and Metaplex CPIs.
• Adds LiteSVM integration tests, fixture preparation, package configuration, and workspace registration.
• Updates Init to require the canonical mint-authority PDA and bump.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the persistent cluster mutation and non-canonical bump acceptance reported previously are both fixed in the current code.

Important Files Changed

Filename	Overview
tokens/pda-mint-authority/pinocchio/program/src/instructions/init.rs	Creates the mint-authority PDA only after validating the supplied account and bump against the canonical derivation.
tokens/pda-mint-authority/pinocchio/program/src/instructions/create.rs	Creates and initializes the NFT mint and invokes Token Metadata with the persisted PDA signer seeds.
tokens/pda-mint-authority/pinocchio/program/src/instructions/mint.rs	Creates the payer ATA, mints one token, and creates its master edition using PDA-authorized CPIs.
tokens/pda-mint-authority/pinocchio/prepare.mjs	Downloads the Token Metadata fixture with a command-scoped mainnet flag and no persistent CLI configuration mutation.
tokens/pda-mint-authority/pinocchio/tests/test.ts	Exercises Init, Create, and Mint and validates the resulting PDA, mint, metadata, token balance, and master edition accounts.

Sequence Diagram

sequenceDiagram
  participant Client
  participant Program as Pinocchio Program
  participant PDA as Mint Authority PDA
  participant Token as SPL Token Program
  participant Metadata as Token Metadata Program

  Client->>Program: Init(canonical bump)
  Program->>Program: Derive and validate canonical PDA
  Program->>PDA: Create account using PDA signer seeds
  Program->>PDA: Store canonical bump

  Client->>Program: Create(mint and metadata accounts)
  Program->>Token: Create and initialize 0-decimal mint
  Program->>Metadata: CreateMetadataAccountV3 (PDA-signed)

  Client->>Program: Mint(payer ATA and edition accounts)
  Program->>Token: Create ATA idempotently
  Program->>Token: MintTo 1 token (PDA-signed)
  Program->>Metadata: CreateMasterEditionV3 (PDA-signed)

Loading

_{Reviews (10): Last reviewed commit: "pda-mint-authority pinocchio: prettier f..." | Re-trigger Greptile}

[greptile-apps]

solana config set -um is never reverted

pnpm install runs this script as a postinstall hook, permanently redirecting the developer's Solana CLI cluster to mainnet. A developer who normally works against devnet or localnet will silently end up with a wrong cluster config after installing. Saving the current cluster with solana config get json_rpc_url, pointing to mainnet only for the dump, then restoring it afterward would avoid the side-effect.

[MarkFeder]

Good catch — fixed in 1cfe23d. prepare.mjs now dumps the program with a per-command solana program dump -um … instead of solana config set -um, so pnpm install no longer mutates the developer's global Solana CLI cluster.

[greptile-apps]

Non-canonical bump is accepted without validation

The bump is taken directly from instruction data and passed to derive_address with Some(bump), which computes a PDA for whatever bump value was supplied rather than requiring the canonical one. A caller who deliberately (or accidentally) provides a non-canonical bump will create the mint-authority account at a different address than findProgramAddressSync would derive client-side. Downstream clients that recompute the PDA without knowing which bump was stored will then resolve a different address and be unable to interact with the mints this program created. Since pinocchio_pubkey::derive_address with bump: None finds the canonical bump on-chain, using it here would prevent this class of error.

[MarkFeder]

Leaving this as-is, for two reasons:

1. Consistency with the established pinocchio pattern. This is exactly what the already-merged tokens/escrow/pinocchio does (make_offer.rs): take the bump from instruction data, then derive_address(&[seed], Some(bump), program_id) and reject the tx unless the supplied account equals that PDA. Every pinocchio example in the repo follows this; matching it keeps the teaching examples uniform.

2. Toolchain constraint. Deriving the canonical bump on-chain needs find_program_address/create_program_address, whose off-target implementation in solana-address is gated behind the curve25519 feature. CI lint runs cargo clippy -- -D warnings on the host target (no --target sbf), so referencing it there fails to compile unless we pull in the curve25519 dependency — which the lightweight pinocchio stack intentionally avoids. derive_address (from pinocchio-pubkey) is the host-compatible primitive, and it only derives for a given bump.

On safety: the supplied mint-authority account is validated against derive_address(Some(bump)), and create/mint re-derive the signer seeds from the bump persisted in that account, so the program is internally consistent. A client that deliberately passes a non-canonical bump only affects its own address derivation; the test (and any normal client) sources the bump from findProgramAddressSync, which always returns the canonical one.

[MarkFeder]

@Perelyn-sama @dev-jodee — rebased onto latest main (picks up the ASM sbpf/Solana pin from #625), CI is now fully green. Ready for review whenever you have a chance 🙏

[dev-jodee]

Will require changes based on #624 final version

[MarkFeder]

Applied the kit + litesvm template from #624 here as well. The test now builds and signs transactions with @solana/kit and runs them on litesvm, so @solana/web3.js and solana-bankrun are dropped entirely. Pinned @solana/kit to ^6.10.0 (litesvm's kit major) for a single kit in the tree, and bumped typescript/tsconfig (es2022 + dom, @types/node) so the suite is type-clean under tsc --noEmit. Verified locally: cargo build-sbf + ts-mocha → 3 passing, plus tsc --noEmit and biome clean. Commit is signed.

[MarkFeder]

Applied the same refinements @dev-jodee asked for on #624 (now merged):

• program: rent is computed with Rent::get()?.try_minimum_balance(..)? in both the Init (PDA account) and Create (mint) instructions (the integer-math workaround was only needed to dodge the f64 opcode the old bankrun VM rejected; litesvm runs the real syscall).
• test: the token, associated-token and system program ids now come from the official @solana-program/token / @solana-program/system packages, and the minted amount is read with getTokenDecoder().decode(...).amount instead of a raw byte offset. Token Metadata has no official @solana-program client, so its id stays hand-rolled.
• tsconfig: moduleResolution: bundler for the packages' subpath exports.

cargo build-sbf + ts-mocha → 3 passing; tsc, biome, fmt and clippy clean; frozen-lockfile OK. Commit is signed.

[dev-jodee]

Still want this one. Heads up though — #656 changed the ground rules: pinocchio is 0.11 (workspace deps), and tests are mocha+tsx with @solana/kit + litesvm 1.x now. tokens/token-2022/non-transferable/pinocchio shows the current pattern, AGENTS.md has the rest. Rebase when you get a chance and I'll review.

[MarkFeder]

@dev-jodee #624 is merged, so I've rebased this onto latest main (resolves the conflict) and migrated the program to pinocchio 0.11 to match — it dropped the pinocchio-pubkey crate, so PDAs are now derived on-chain with Address::find_program_address (via solana-address's curve25519 feature, the same pattern the merged block-list example uses).

That migration also resolves the earlier non-canonical-bump comment: init now derives the canonical bump on-chain and rejects any mismatch, so a non-canonical bump can no longer create the account at a different address. (The toolchain constraint I'd cited for keeping the old approach no longer applies on 0.11.)

Host cargo clippy -D warnings and cargo fmt --check are clean. Ready for another look.