Senddy Docs
Open App

Attestation Model

How off-chain proof verification works with trusted execution environments.

Why attestation?#

Verifying zero-knowledge proofs on-chain is expensive. Each proof verification can cost significant gas. Senddy uses an attestation model to move proof verification off-chain while maintaining security guarantees.

Instead of verifying proofs in the smart contract, an attestor running in a trusted execution environment verifies the proof and signs an attestation. The smart contract only needs to verify the attestor's signature — which is cheap.

How it works#

1. Client generates a proof#

The user's device generates a zero-knowledge proof (shield or spend) using the Noir/UltraHonk proving system compiled to WebAssembly.

2. Client sends proof to attestor#

The proof and its public inputs are sent to the attestor service via HTTPS.

3. Attestor verifies in secure enclave#

The request is forwarded to a hardware-isolated trusted execution environment (TEE) — a secure enclave that is completely isolated from the host system.

Inside the enclave:

  • The proof is verified using the UltraHonk verifier
  • The enclave maintains the canonical Poseidon2 Merkle tree and derives tip transition roots (anchorRoot / stateRootBefore / newRoot)
  • If valid, the enclave signs an attestation using a hardware security module (HSM)

4. Attestation returned to client#

The signed attestation is returned to the client, which includes it in the on-chain transaction.

5. Smart contract verifies signature#

The pool contract checks that the attestation was signed by the registered attestor address (cheap ecrecover), that the proof’s anchorRoot is a known tip (isKnownRoot), and — when the tx emits new commitments — that the tip advances from stateRootBefore to enclave-derived newRoot in the same transaction.

Security properties#

Enclave isolation#

The attestor runs in a hardware-isolated enclave with:

  • No persistent storage — Cannot store or leak data between runs
  • No network access — Communicates only through a minimal, controlled channel to the host
  • Cryptographic attestation — The cloud provider provides a signed measurement of the enclave's code, so you can verify exactly what software is running
  • No shell access — Not even the operator can access the running environment

HSM key isolation#

The attestor's signing key is managed by a hardware security module with a key policy that restricts usage to the specific enclave instance. Even the infrastructure operator cannot use the key outside the enclave.

Trust model#

The trust assumption is:

  • The TEE is secure — The enclave provides integrity and isolation
  • The attestor code is correct — The code running in the enclave is open source and can be audited
  • The HSM is secure — The signing key cannot be extracted

If the TEE or HSM assumptions fail, an invalid proof can be attested and the pool may pay. Separately, a compromised gateway (courier) can no longer invent a new on-chain-known fake root: the pool only accepts tips advanced atomically with real commitment emissions (Phase A). Authenticated L2 finality (Phase B) is still required before treating the courier path as fully closed.