Skip to main content

Threat Model and Trust Assumptions

OXN's confidentiality guarantees rest on hardware-attested TEEs. This page states exactly what that means: what attackers OXN defends against, what attackers it does not, and how remote attestation makes the defense verifiable.

Not every threat model needs OXN. Not every threat model that needs OXN is well-served by any confidential chain. Read this before you decide.

The trust anchor: Intel SGX + remote attestation​

OXN's confidentiality assumes:

  1. Intel SGX correctly implements memory isolation. The CPU protects enclave memory from the operating system, the hypervisor, and every other process on the machine.
  2. Intel's attestation service is honest. When an enclave produces an attestation quote saying "I am running code X on a genuine Intel CPU", that quote can be verified against Intel's public keys.
  3. The specific enclave binary is the code you expect. The attestation quote includes a measurement of the code loaded into the enclave. Verifiers compare this against a published expected measurement.

None of these are novel assumptions unique to OXN. They are the standard SGX threat model that Intel, Microsoft, Google, and many others have built products on.

Attacks OXN defends against​

A malicious node operator. The node runs OXN. The operator wants to read the contents of your transactions or state. Defended. The enclave decrypts inputs and stores outputs only inside protected memory. The operator sees ciphertext.

A malicious cloud provider. The node is running in AWS / Azure / GCP. The cloud provider wants to snapshot memory or otherwise inspect execution. Defended. SGX protects against hypervisor-level attacks, including memory snapshots.

A malicious RPC provider. The public RPC endpoint you talk to is malicious. It wants to read your transaction contents in flight. Defended. Calldata is encrypted end-to-end from your client to the enclave — the RPC provider only sees the encrypted envelope.

A passive network observer. Someone is watching traffic on the wire. Defended. Same encryption applies; traffic past the outer CBOR envelope is opaque.

An indexer or block explorer. Any party reading the chain's public data. Defended for encrypted content. They see transaction metadata (from / to / gas / status) but not calldata, return data, event contents, or storage.

Attacks OXN does NOT defend against​

Read these carefully. If any of them applies to your threat model, you need something beyond OXN.

A compromised Intel CPU or SGX vulnerability. OXN trusts SGX. If Intel or a researcher publishes a zero-day that breaks SGX isolation (there have been several over the years — Foreshadow, Plundervolt, ÆPIC, etc.), confidentiality can be broken until the fix ships. Every TEE-based chain has this risk.

Side channels. SGX does not defend against timing, cache, or power side channels within the CPU package. Sophisticated attackers with local access to a validator machine may extract information by observing execution patterns. Contracts should avoid data-dependent branches where possible — see Confidentiality Pitfalls.

A compromised client. If malware on your laptop reads your private key or process memory, no chain can protect you. OXN's guarantees begin at the encrypted transaction envelope; anything upstream is your responsibility.

Metadata analysis. Even with encrypted contents, the pattern of who calls what contract when is public. If you're the only entity that calls a specific contract at 3am UTC, that pattern reveals information regardless of encryption.

Correctness bugs in contracts. OXN does not verify that your Solidity is correct, safe, or free of logic bugs. Every EVM security issue that exists on Ethereum also exists on OXN. Confidentiality does not substitute for an audit.

Compelled disclosure. If a court orders you to reveal a transaction's contents, and you have the session key, you can reveal it. OXN does not provide plausible deniability.

How verification works: remote attestation​

The claim "your call executed inside a real SGX enclave running the OXN runtime" is verifiable, not just assumed.

The chain distributes the enclave's public key together with an attestation quote. The quote is a signed statement produced by the CPU that says:

  • I am a genuine Intel SGX CPU with these specific microcode versions.
  • I loaded and am running code with this measurement (a hash of the enclave binary).
  • Here is the public key that this specific enclave instance controls.

Clients (or SDKs) verify the quote against Intel's Provisioning Certification Service. Only if verification passes does the client use the enclave's public key to encrypt calldata.

Concretely: when a wrapped provider is first initialized, it fetches and validates an attestation quote before it ever encrypts anything. If validation fails, encryption fails and the SDK reports an error.

What this means for your app​

If your app handles genuine secrets (private keys, credentials, hidden game state, unrevealed bids) OXN's threat model is designed for you. The economic and technical friction to breaking SGX exceeds most application-level threats.

If your app is targeted by nation-state adversaries with capacity to invest in SGX-level attacks, OXN alone is not enough. Consider layering ZK proofs, multi-party computation, or off-chain enclaves you control.

If your app just wants "some privacy" without a specific threat model, OXN gives you a huge upgrade over public EVM at essentially no development cost. Most apps are in this category.

Next steps​