fix(transfer-tokens): native transfer wrongly requires the recipient to co-sign

[NikkiAung]

The bug

The native implementation of tokens/transfer-tokens's transfer_tokens instruction builds the SPL Token Transfer CPI like this:

&token_instruction::transfer(
    token_program.key,
    from_associated_token_account.key,
    to_associated_token_account.key,
    owner.key,
    &[owner.key, recipient.key],   // <- signer_pubkeys
    args.quantity,
)?,

Passing a non-empty signer_pubkeys list tells the SPL Token program the authority account (owner) is a multisig account, and marks owner itself as a non-signer in the CPI's account metas — the listed pubkeys (owner, recipient) are appended as the individual co-signers of that multisig instead. owner here is just a plain wallet, not a multisig account, so this construction is wrong regardless of who calls it.

Concrete effect, confirmed empirically: a transfer only succeeds if the recipient also signs the transaction. Without it, the CPI is rejected at the runtime privilege-check stage before the Token program even runs:

"Ar4ej...'s signer privilege escalated"
"... failed: Cross-program invocation with unauthorized signer or writable account"

This is backwards — a recipient should never need to approve/co-sign to receive tokens sent to them. As shipped, this example teaches a pattern that makes tokens effectively impossible to transfer to any wallet that isn't present to co-sign, which defeats the purpose of the instruction. The existing test suite didn't catch this because it happened to make the recipient a signer for unrelated reasons (its account needed funding to test with).

The anchor and pinocchio implementations of this same example were already correct (signer_pubkeys: &[] in pinocchio, and Anchor's Transfer CPI simply never lists recipient as an authority) — only native had this bug.

Fix

Pass an empty signer_pubkeys list, matching owner's actual role as a plain single-signer authority — the same pattern already used by the anchor and pinocchio versions. Updated the TS instruction builder (ts/instructions/transfer.ts) to take the recipient as a plain Address instead of a TransactionSigner, and updated the test to pass the recipient's address without asking it to sign.

Verification

• Confirmed red/green: reverted just the signer_pubkeys fix (keeping the updated, non-signing-recipient test), rebuilt, and confirmed the transfer tests fail with Cross-program invocation with unauthorized signer or writable account — then reapplied the fix and confirmed all 6 tests pass.
• Full native litesvm suite passes (Create an SPL Token!, Create an NFT!, Mint some tokens to your wallet!, Mint the NFT to your wallet!, Transfer tokens to another wallet!, Transfer NFT to another wallet!).
• cargo fmt -p transfer-tokens-program -- --check and cargo clippy -p transfer-tokens-program --all-targets -- -D warnings both clean.
• tsc --noEmit and repo-wide prettier --check both clean on the touched files.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR corrects the native token-transfer authority model so only the sending owner authorizes the debit.

• Passes an empty multisig signer list to the SPL Token transfer CPI.
• Represents the recipient as a read-only address in the TypeScript instruction builder.
• Updates the transfer test to demonstrate that the recipient need not co-sign.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
tokens/transfer-tokens/native/program/src/instructions/transfer.rs	Removes the erroneous multisig signer list so the ordinary wallet owner remains the sole transfer authority.
tokens/transfer-tokens/native/ts/instructions/transfer.ts	Changes the recipient contract from a writable signer to a read-only address, matching its actual on-chain role.
tokens/transfer-tokens/native/tests/test.ts	Passes only the recipient address, covering successful transfer and ATA creation without recipient authorization.

_{Reviews (2): Last reviewed commit: "docs(transfer-tokens): trim self-explana..." | Re-trigger Greptile}

[NikkiAung]

Hey @dev-jodee — this one's ready for review whenever you have a chance. CI is green and Greptile's automated pass found no blocking issues.

[dev-jodee]

can we remove the comments that are self explanatory

[NikkiAung]

Fixed in d89b110 — trimmed the comment to 2 lines.