Skip to the tabletop

FREE EXPERT TABLETOP · WORKS OFFLINE

Trace the threat. Bound the claim.

Six fictional Solana protocol incidents. Connect what an attacker or dependency can control to the invariant that protects the system and evidence strong enough to support the conclusion.

Review only; no live system. This casebook makes no transaction, RPC request, wallet prompt, or saved answer.

A REPEATABLE REVIEW PATH

Three questions, one bounded conclusion

01 · CAPABILITYWhat can the attacker control?
Inputs, signers, account addresses, dependencies, or release authority.
02 · INVARIANTWhat must always remain true?
Name the onchain relationship or operational boundary protecting the asset.
03 · EVIDENCEWhat does the evidence prove?
Match each claim to a negative test, chain observation, or operational check.

A test, RPC response, dashboard label, or release note proves only what it actually observes. Keep unknown outcomes visible.

FORMATIVE · UNSCORED · NOT SAVED

Work the incidents

Choose the strongest complete analysis, then read its explanation.

01

ACCOUNT SUBSTITUTION · TOKEN VAULT

A deposit screen shows the right token symbol, but the caller supplies a different mint and token account.

Protected asset: Tokens held in the canonical vault
Submitted inputs: Caller-selected source account, mint, and signer wallet
Visible trap: A matching symbol is not a mint identity

Which threat analysis is strongest? The attacker can change a token symbol, so the user interface should hide unfamiliar names before signing. The attacker can substitute public account inputs; the program must verify token-program owner, expected mint, authority, and canonical vault, then test rejection with balances and receipt unchanged. The attacker can sign for the vault PDA by choosing its address, so changing the PDA label protects the stored tokens.

Choose an analysis before checking.

02

AUTHORIZATION · USER IDENTITY

A claim instruction receives the victim’s public address, but no transaction signature from that victim.

Attacker can do: Submit public addresses and sign with their own wallet
Attacker cannot do: Produce the victim’s private-key signature
Required result: No claim unless the stored authority authorized it

Which invariant and proof fit this boundary? Any account with the victim’s public key is sufficient; include the key in a claim receipt and test its display name. The frontend should compare the connected address before sending; a screenshot of the hidden claim button proves authorization. Require a transaction signer and compare it with stored authority; test missing and mismatched signers and assert claim state remains unchanged.

Choose an analysis before checking.

03

CPI BOUNDARY · PROGRAM SUBSTITUTION

A withdrawal forwards a caller-supplied executable account and a writable token destination.

Attacker controls: Instruction account addresses and ordering
Authority boundary: The caller may sign for its PDA using validated seeds
Protected result: Only the intended token program moves the intended asset

What should the review and negative test require? Accept any executable with similar instruction bytes; CPI privileges guarantee it cannot change balances unexpectedly. Bind the callee to the approved program ID, validate forwarded accounts and PDA seeds, and test a substituted callee with protected state unchanged. Make every account read-only; that alone ensures the intended transfer runs with correct authority.

Choose an analysis before checking.

04

REPLAY · BUSINESS STATE

A valid deposit receipt is submitted again through a fresh transaction with a fresh blockhash.

Attacker has: A valid prior receipt and a new transaction signer
Risk: The same deposit may be credited or claimed twice
Evidence needed: State proves one business transition, not just one signature

Which control and evidence close the loop? Require a new recent blockhash for each transaction; a different signature makes a repeated claim a new valid business event. Disable the button after one browser click; the program does not need a consumed receipt. Use a unique receipt or consumed-state guard; replay and competing-claim tests show at most one commit and no duplicate asset movement.

Choose an analysis before checking.

05

RELEASE CONTROL · UPGRADE AUTHORITY

Local tests pass, but one operator holds the deployed program’s upgrade authority.

Threat actor: A compromised or misused authorized release key
Exposure: Users may invoke changed bytes after review
Claim boundary: Local tests do not identify current deployed code

Which evidence addresses the actual release risk? Inspect the program and ProgramData authority on the intended cluster, then independently match deployed executable bytes to the reviewed release. Rerun local tests; matching output proves the onchain authority and deployed bytes have not changed. Check the frontend label and release note; together they prove the live executable and every authority.

Choose an analysis before checking.

06

RPC DEPENDENCY · UNKNOWN OUTCOME

An indexer says a claim failed, while another provider reports a finalized status for the learner’s signature.

Dependency fault: Stale status or incomplete indexed account data
Decision at risk: A duplicate claim or false completion report
Unknown is valid: Provider disagreement does not prove either answer

What is the bounded next step? Trust the course indexer, mark the claim failed, and invite the learner to sign again immediately. Keep the result unknown; reconcile signature status, execution error, commitment, and resulting state on the same cluster, using another provider as comparison. Treat a null recent-cache response as proof no transaction was submitted or account state changed.

Choose an analysis before checking.

PRIMARY REFERENCES

Check the protocol boundary

Solana Cross Program Invocation — signer and writable privileges, PDA signing, and CPI execution.
Anchor Account Constraints — signer, owner, address, seed, and relationship checks.
Anchor Sealevel Attacks — common account-validation failure modes.
Solana Program Deployment — ProgramData metadata, upgrade authority, and immutability.
Solana getSignatureStatuses — recent-cache scope and optional history search.
Solana getTransaction — signature lookup at a requested commitment.
Solana Production Readiness — RPC dependencies, transaction evidence, and release checks.

This tabletop does not audit a real program or verify any provider, authority, transaction, or release. Protocol and attacker scenarios are fictional.