AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 37 Monero

feat(spl): implement Token-2022 transfers

Public commit record

What the developer wrote

Authored by sneurlax

57/100 · Thin
feat(spl): implement Token-2022 transfers
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit adds support for Solana Token-2022 transfers in Stack Wallet. It changes how the wallet detects which token program a token uses, validates sender and recipient token accounts before sending, and switches from a simple transfer instruction to a 'transferChecked' instruction that includes the token's mint and decimal count. The commit also replaces a placeholder address-derivation method with a real Solana Associated Token Account (ATA) derivation. The changes are mostly defensive, but they introduce new logic that relies on RPC responses and string matching on program IDs, which could be a source of bugs or security issues if not fully correct.

Recommended action

Review the program-ID classification logic to ensure it cannot misclassify a malicious or unexpected token program as Token-2022. Verify that the ATA seed ordering matches the Solana Associated Token Account program exactly (seeds should be [owner_pubkey, token_program_id, mint_pubkey], not include a literal 'account' string). Confirm that transferChecked is supported by the underlying solana package for both TokenProgramType values. Consider adding tests for Token-2022 transfers, fallback behavior, and invalid recipient accounts. Audit whether amount.raw.toInt() can overflow or lose precision for tokens with large supplies or small decimals.

Security signals we found

01

Switches to transferChecked, which enforces mint/decimals validation on-chain and is generally safer than unchecked transfer

02

Adds on-chain existence checks for sender and recipient token accounts before building transactions

03

Adds ownership check to reject System Program-owned recipient accounts

04

Replaces placeholder ATA derivation with real PDA derivation, reducing risk of sending to wrong address

05

Queries mint owner at multiple points and falls back to legacy SPL Token program on failure

06

Uses string prefix matching ('startsWith Token') to classify token programs, which is brittle and could misclassify future or custom token programs

07

No explicit handling of Token-2022 extension types (e.g., transfer fee, confidential transfers); only program ID detection is present

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 6/15
Affected reach 8/15
Confidence 5/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.