Umbra Privacy SDK — Integration Test

Arcium Multi-Party Computation (MPC)

Your USDC balance is encrypted using Arcium's MPC network — a set of independent nodes that each hold a fragment of the decryption key. No single node can decrypt your balance. A withdrawal requires a quorum of nodes to jointly authorize the computation without any of them ever seeing the plaintext amount. This is the same category of cryptography used by institutional custody providers, applied to on-chain token accounts.

Encrypted Token Accounts (ETAs) — Shared mode

When you register with confidential: true, your ETA is created in Shared mode. The balance is encrypted under both Arcium's key and your own X25519 keypair (derived deterministically from your wallet). This means you can read your own shielded balance locally in the browser — no network round-trip to Arcium required. The Arcium key is still needed to authorize withdrawals, maintaining the security guarantee.

The dual-transaction pattern (handler + callback)

Every shielded operation splits across two on-chain transactions. TX 1 (the handler) is signed by your wallet — it validates inputs, deducts the tokens from your public ATA, and queues the computation with Arcium. TX 2 (the callback) is submitted automatically by the Arcium network after the off-chain MPC round completes — it posts the encrypted result on-chain and finalizes your ETA balance. You never sign TX 2; Arcium handles it. This is why there is a latency window between shielding and seeing your balance update.

Master seed derivation (one-time wallet signature)

When you initialize the Umbra client for the first time, your wallet signs a fixed message. The resulting Ed25519 signature is hashed with Keccak-512 to produce a 64-byte master seed. All Umbra cryptographic keys (your X25519 viewing keypair, Poseidon private keys, nullifiers) are deterministically derived from this seed. The seed is never stored — it is re-derived on demand from the same wallet signature. This means your keys are recoverable from any device just by connecting the same wallet.

Mixer / UTXO model and zero-knowledge proofs (Phase 2)

The mixer extends privacy further. When you deposit into the mixer, the SDK computes a Poseidon hash commitment of (amount, recipient X25519 key, random secret) and inserts it as a leaf in an on-chain indexed Merkle tree. The commitment reveals nothing about its contents. To claim, the recipient's wallet generates a Groth16 zero-knowledge proof that demonstrates knowledge of the secret behind a leaf — without revealing which leaf it is. The nullifier (a deterministic hash of the secret) is recorded on-chain to prevent double-claiming. Anonymity strength scales with tree occupancy: the more leaves, the harder it is to correlate any specific deposit with a claim.