# Attestation Model

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

Source: https://www.senddy.com/docs/technical/attestation
Last modified: 2026-08-01T23:49:54.000Z

---

## 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.