Architecture

High-level overview of how Senddy works under the hood.

System Overview#

Senddy is a privacy-preserving payment system built on zero-knowledge proofs, smart contracts, and a trusted execution environment. Here's how the pieces fit together.

Components#

Client (Browser/Mobile)#

The user's device handles:

• Key derivation — Senddy keys are derived from an EIP-712 signature, no seed phrase needed
• Note management — Tracking which private "notes" belong to you via the sync engine
• Proof generation — Zero-knowledge proofs are generated client-side in 2-5 seconds using WebAssembly
• Memo encryption — Encrypted using X25519 ECDH + XChaCha20-Poly1305

Smart Contracts (Base)#

The on-chain contracts include:

• Pool Contract — The main contract that holds all funds and processes deposits, shields, spends, and withdrawals
• Verifier Contracts — Verify zero-knowledge proofs for shield and spend operations
• Yield Strategy — Manages yield generation by deploying funds to trusted DeFi lending protocols

Attestor Service#

The attestor verifies ZK proofs off-chain in a hardware-isolated trusted execution environment (TEE):

• Runs in a secure enclave — isolated, tamper-proof, no persistent storage
• Verifies proofs using the UltraHonk verifier
• Signs attestations via a hardware security module (HSM) — the signing key never leaves the enclave

Data Indexer#

Indexes on-chain events for efficient querying:

• Commitments, nullifiers, deposits, withdrawals
• Pool state and asset statistics
• Daily aggregated data

Relayer Network#

Enables gasless transactions:

• Users never need ETH for gas
• Transaction fees are embedded in the ZK circuit
• Relayed via a third-party relayer network for reliable execution

Transaction Flow#

Deposit and Shield#

1. User deposits USDC into the pool contract (public transaction)
2. Client generates a shield proof — proves the deposit converts to valid private notes
3. Attestor verifies the proof in the secure enclave
4. Attestor signs an attestation
5. The shield transaction is submitted on-chain with the attestation
6. Private notes (commitments) are added to the Merkle tree

Private Transfer (Spend)#

1. Client selects notes to spend and constructs new output notes
2. Client generates a spend proof — proves:
   • The input notes exist in the Merkle tree
   • The user knows the secret keys for those notes
   • The input and output values balance (conservation)
   • The nullifiers are correctly derived
3. Attestor verifies the proof and signs an attestation
4. The spend transaction is submitted on-chain
5. Input note nullifiers are recorded (preventing double-spend)
6. New output note commitments are added to the Merkle tree

Withdrawal#

Same as a spend, but one of the output notes is a "withdrawal" that sends USDC to a public Ethereum address.

Key Design Decisions#

• Universal setup — Our proving system uses a universal trusted setup, meaning the same setup ceremony works for any circuit. No per-circuit trusted setup required, and the system can be upgraded without new ceremonies.
• Attestation-based verification — Proofs are verified off-chain in a TEE rather than on-chain, reducing gas costs dramatically
• UTXO model — Like Bitcoin/Zcash, not account-based. Each "note" is a discrete value that can be spent atomically
• Client-side proving — Proofs are generated on the user's device, so no server ever sees transaction details
• Gasless transactions — Fees are embedded in the ZK circuit and paid from the user's private balance