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

feat(spl): Solana token (SPL) sending scaffolding

Public commit record

What the developer wrote

Authored by sneurlax

57/100 · Thin
feat(spl): Solana token (SPL) sending scaffolding
✓ 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 the first working code for sending Solana token (SPL) transfers inside Stack Wallet. It replaces a mock placeholder with real transaction building, signing, and broadcasting. The change is normal feature work, but it contains a known-incomplete helper for deriving recipient token addresses: the function falls back to returning the recipient's main wallet address instead of the correct associated token account, and the code itself admits this is a placeholder. If that fallback path is ever used, tokens could be sent to an address that does not actually hold the SPL token, risking loss of funds. The commit also exposes a wallet's signing keypair to a child token wallet, which is expected for this design but increases the attack surface if the token-wallet code is ever compromised.

Recommended action

Review and complete the ATA derivation helper before enabling this in production; replace the owner-pubkey fallback with a proper findProgramAddress implementation and validate the derived ATA on-chain. Add overflow checks for amount.toInt(), implement real fee estimation, and consider stricter handling of unconfirmed transactions. Audit the keypair-sharing boundary between SolanaWallet and SolanaTokenWallet.

Security signals we found

01

Placeholder ATA derivation returns owner public key instead of the correct associated token account (documented in code comments).

02

Token sub-wallet obtains parent SolanaWallet signing keypair via getKeyPair().

03

Hard-coded fee estimate (5000 lamports) instead of on-chain simulation.

04

Amount conversion uses .toInt() without overflow checks.

05

Transaction confirmation polling treats timeout as a warning rather than a failure, returning the txid anyway.

06

No rate limiting or retry backoff beyond a fixed 2-second poll loop.

Risk score

Why this scored 33/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 4/15
Affected reach 6/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.