Attestation Model

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 Merkle tree state is checked to ensure consistency
• 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. This is a single ecrecover call — far cheaper than verifying the full ZK proof on-chain.

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 any of these assumptions are violated, the worst case is that an invalid proof could be attested. However, the pool contract maintains additional invariants (nullifier uniqueness, Merkle root validity) that prevent the most critical attacks even if the attestor is compromised.