Transfer Flow Deep Dive

How Alice sends 0.1 SOL to Bob with zero on-chain fingerprints.

Phase 1: Shielding (The Deposit)

When Alice deposits 0.1 SOL into the Shadow Pool, she isn't just sending money; she is "shielding" it. The transaction is public, but the funds are now represented by a cryptographic secret.

Commitment = PoseidonHash(RecipientAddress, Amount, SecretNonce)
  • Identity: Alice uses her Shadow Identity (a Poseidon keypair) to define who can spend the funds.
  • Commitment: A hidden "voucher" is created. Only Alice knows the SecretNonce that links this voucher to her.
  • On-Chain: The Solana program receives the 0.1 SOL and stores the Commitment in a Merkle Tree.
graph LR A[Alice] -- "0.1 SOL" --> P[Solana Program] A -- "Commitment" --> P P -- "Store" --> T[Merkle Tree] style A fill:#09090b,stroke:#a1a1aa,color:#fff style P fill:#18181b,stroke:#10b981,color:#fff style T fill:#18181b,stroke:#06b6d4,color:#fff

Phase 2: Proving Identity (ZK-Proof)

This is the magic part. To send funds to Bob, Alice must prove she "owns" one of the commitments in the pool without revealing which one.

  • Input: Alice provides her PrivateKey, SecretNonce, and a Merkle Path as private inputs.
  • Proving: The Circom circuit verifies that H(H(Key), Amount, Nonce) exists in the tree root.
  • Zero-Knowledge: The output is a Groth16 proof (256 bytes) that says "I know a valid secret for a commitment in this pool" without naming the secret or the commitment index.

Phase 3: The Relayer (Breaking the Link)

In Phase 2, Alice generated a proof. But if Alice sends that proof to Solana herself, her wallet address appears as the Fee Payer. This creates a metadata link. To fix this, we use a Relayer.

  • Anonymity: Alice sends her proof and Bob's address to the Relayer via an encrypted off-chain channel.
  • Gasless Payout: The Relayer pays the Solana transaction fees. Alice's address never touches the blockchain during the payout.
  • Privacy: On-chain, observers only see the Relayer interacting with the Shadow Pool. Alice is invisible.
sequenceDiagram participant Alice participant SDK as Shadow SDK participant Relayer participant Program as Solana Program participant Bob Alice->>SDK: Initiate Transfer to Bob SDK->>SDK: Generate ZK Proof SDK->>SDK: Generate Nullifier SDK->>Relayer: Send Proof + Nullifier + Bob (Off-chain) Note over Relayer: Relayer Pays Gas Fees Relayer->>Program: Proxy Transaction Program->>Program: Verify ZK-Proof & Nullifier Program->>Bob: Release 0.1 SOL

Technical Transparency

On-Chain Verification: ACTIVE

In this version, zero-knowledge proofs are strictly verified on-chain using Solana's optimized alt_bn128 syscalls. The program enforces:

  • Groth16 Verification: Cryptographic proof that the spender owns a commitment in the Merkle Tree.
  • Merkle Root Integrity: The client calculates the new Merkle Root (Poseidon hash) which is verified against the on-chain state.
  • Nullifier Checks: Prevents double-spending by tracking used nullifiers in a bitmap.
  • Performance: Verification consumes approximately 200k Compute Units, allowing it to run within standard transaction limits.

Why it works

By combining ZK-SNARKs with a Relayer network, we achieve two types of privacy:

  • Data Privacy: No one knows *which* deposit is being spent (ZK-Proof).
  • Metadata Privacy: No one knows *who* triggered the withdrawal (Relayer).

Total SOL Transferred: 0.1 SOL
Signer Linkability: 0% (Relayed)
Privacy Level: Absolute Shadow