Hybrid TEE + ZK settlement

Components

• Enclave keypair and attestation report: generated inside the Trusted Execution Environment and verified by each counterparty before submission.
• Matching engine inside the enclave: decrypts orders, validates nonces against state, and matches counterparties according to settlement rules.
• Stealth-address escrow: notes are locked to per-settlement stealth addresses with dual spending conditions (stealth-derived key or original-owner timeout path) enforced by the zero-knowledge circuit.
• Zero-knowledge prover inside the enclave: generates the succinct proof of correct matching and monotonic state transition.
• On-chain state commitment contract and verifier: stores state roots and checks each settlement proof.
• Announcement contract: publishes the ephemeral stealth-address keys atomically with settlement acceptance.
• Off-chain encrypted state blobs and key management: persist state across enclave restarts; replication covers enclave-node failure.

Protocol

1. operator The enclave generates a keypair, publishes an attestation report, and exposes the public key so counterparties can verify the report and encrypt orders.
2. user Each counterparty encrypts its order (asset, amount, conditions, nonce) to the enclave public key and submits it on-chain or through a direct channel.
3. operator The enclave decrypts orders, validates nonces against state to prevent rollback, and matches counterparties according to the settlement rules.
4. contract Notes are locked to per-settlement stealth addresses with the zero-knowledge circuit enforcing dual spending conditions (stealth-derived key or original-owner timeout).
5. prover The enclave generates a zero-knowledge proof attesting that orders were valid, matching followed the protocol, state transition is monotonic, and output commitments are correct.
6. contract The on-chain verifier checks the proof; on success the enclave atomically publishes the ephemeral stealth-address keys to the announcement contract.
7. user Recipients scan the announcement contract, derive their spending keys, and claim their notes. If the enclave fails before revealing keys, original owners reclaim after the timeout.

Guarantees & threat model

Guarantees:

• Counterparties, amounts, and matching logic are hidden from network observers; inside the enclave the operator can see plaintext under contractual terms.
• Atomic settlement: the zero-knowledge proof guarantees correct execution on-chain regardless of enclave integrity, so financial correctness is independent of hardware trust.
• Rollback safety: nonce monotonicity is enforced inside the circuit and anchored to an on-chain state root.
• Liveness floor: the timeout refund circuit ensures original owners can reclaim locked notes if the enclave goes offline.
• Auditability: viewing keys can disclose scoped data to regulators without exposing the full state.

Threat model:

• Soundness of the zero-knowledge proof system and correctness of the on-chain verifier.
• Attestation integrity: counterparties must verify the hardware signature, the code measurement, and the revocation status before encrypting orders.
• Semi-honest enclave operator: a fully malicious operator can leak plaintext, reorder, delay, or drop messages, but cannot alter settlement outcomes because the proof is verified on-chain.
• Side-channel attacks on the underlying hardware (Spectre-family, cache-timing) can leak partial data even when attestation succeeds.
• Metadata leakage: packet sizes, timing, and connection patterns can reveal trade magnitudes and enable front-running; padding and constant-time processing are required.
• Supply-chain tampering on the hardware is out of scope for the protocol and must be handled at sourcing time.

Trade-offs

• Privacy depends on enclave integrity while financial correctness does not; this is the core design trade-off versus client-side zero-knowledge proving, which provides both at the cost of latency.
• Cross-chain atomicity is timeout-based rather than cryptographic. One leg can succeed while the other fails, and timeout refunds provide safety but not true atomicity. Same-network settlement remains the cleanest atomic-DvP path.
• Performance overhead of roughly 10 to 50 percent versus native execution, plus enclave memory limits that constrain batch sizes on some hardware.
• Multiple enclave nodes with replicated encrypted state are required to avoid a single point of failure; otherwise one crash locks all in-flight settlements until the timeout path triggers.
• Common anti-patterns (plaintext inputs or outputs, missing nonce monotonicity, shared encryption keys, in-memory-only state) silently weaken the guarantees and must be explicitly guarded against.

Example

A bank in Frankfurt wants to sell euro-denominated corporate bonds to a bank in Singapore for stablecoins, with both assets living on shielded pools on the same L1. Both banks verify the enclave's attestation report and encrypt their orders to the enclave public key. The enclave decrypts, validates nonces, confirms the compliance attestations, and matches the orders. Notes are locked to stealth addresses with a 24-hour timeout refund. The enclave generates a zero-knowledge proof of correct matching and submits it on-chain; once the proof verifies, the enclave publishes the ephemeral keys to the announcement contract. The buying bank derives the spending key for the bond notes and the selling bank derives the key for the stablecoin notes. If the enclave crashes between matching and proof submission, both banks reclaim their original notes through the timeout circuit.

See also