Testing & Security

# Run the full test suite
pnpm test

# Test categories:
├── crypto/poseidon    — hash consistency, field boundaries, circomlibjs compat
├── crypto/keccak      — commitment generation, recipient hashing
├── note               — creation, commitment, nullifier derivation
├── merkle-tree        — insert, proof, root, capacity bounds
├── prover             — deposit/withdraw/transfer proof generation
├── tx/deposit         — transaction builder output validation
├── tx/withdraw        — nullifier PDA derivation, proof embedding
├── tx/transfer        — 1-input 2-output value conservation
├── pda                — deterministic address derivation
├── tree-state         — on-chain sync, incremental leaf fetching
├── note-store         — memory and file backend persistence
├── voucher            — parse, validate, legacy format detection
└── utils              — field conversion, byte formatting

// 1. Commitment uniqueness
// Two different notes MUST produce different commitments
assert(computeCommitment(noteA) !== computeCommitment(noteB))

// 2. Nullifier determinism
// Same secret + commitment ALWAYS produces the same nullifier
assert(computeNullifier(s, c) === computeNullifier(s, c))

// 3. Nullifier unlinkability
// Different secrets produce different nullifiers for same commitment
assert(computeNullifier(s1, c) !== computeNullifier(s2, c))

// 4. Value conservation (transfer circuit)
// input.amount === output1.amount + output2.amount
// Enforced inside the Groth16 circuit — prover cannot cheat

// 5. Merkle inclusion
// A valid proof must reference a root in the 100-entry history buffer
// Stale roots are rejected on-chain

// 6. Field boundary
// All values must be < BN254_PRIME
// Overflow would break proof soundness

// The wallet SHA-256 hashes WASM and zkey files before proving
// This prevents supply-chain attacks where a malicious circuit
// could generate valid-looking proofs that leak secrets

// Expected hashes are pinned in the application
// Any mismatch aborts proof generation immediately

// Verification happens client-side before every proof:
// 1. Fetch circuit file (WASM or zkey)
// 2. Compute SHA-256 digest
// 3. Compare against pinned expected hash
// 4. Abort if mismatch — do NOT generate proof

// The Solana program performs these checks:
// 1. Groth16 proof verification via alt_bn128 precompile
// 2. Nullifier PDA existence check (double-spend prevention)
// 3. Merkle root membership in 100-entry history buffer
// 4. Token balance sufficiency for deposits
// 5. Fee calculation and vault transfer

// If ANY check fails, the entire transaction reverts
// No partial execution — atomic by Solana's runtime guarantee

// Desktop wallet (Tauri) performs OFAC screening before transactions
// Integration via TRM Labs API — address-only, no KYC, no identity

// Risk categories: LOW | MEDIUM | HIGH | UNKNOWN
// Block categories: sanctions, OFAC, terrorist financing,
//   darknet, ransomware, stolen funds, child exploitation, mixers

// CRITICAL: Fails closed on ANY API error
// If TRM is unreachable, the transaction is blocked by default
// This is a deliberate safety choice — never transact blind