Skip to main content

Architecture Overview

OXN is a single L1 chain composed of two cooperating layers: a consensus layer that agrees on the order of transactions and secures native token balances, and an execution layer that runs Solidity contracts inside SGX enclaves. Users normally interact only with the execution layer — everything else is transparent.

The one-picture summary​

┌─────────────────────────────────────────────────────────────────┐
│                            OXN L1                                │
│                                                                  │
│   ┌──────────────────────────────────────────────────────────┐  │
│   │ Execution Layer  —  EVM inside SGX enclave               │  │
│   │                                                          │  │
│   │   • Runs Solidity contracts                              │  │
│   │   • Encrypted contract storage / calldata / return data  │  │
│   │   • Holds  0x… (EVM)  balances                           │  │
│   │   • Serves standard eth_* JSON-RPC + OXN-specific ext.   │  │
│   │   • Distributes enclave attestation quotes to clients    │  │
│   └────────────────────────┬─────────────────────────────────┘  │
│                            │                                     │
│              deposits ▲    │    ▼ withdraws                     │
│                            │                                     │
│   ┌────────────────────────┴─────────────────────────────────┐  │
│   │ Consensus Layer  —  BFT consensus                        │  │
│   │                                                          │  │
│   │   • Orders and finalizes blocks                          │  │
│   │   • Holds  oxn1… (native)  balances                      │  │
│   │   • Runs validator staking (mainnet)                     │  │
│   │   • Manages enclave key rotation                         │  │
│   └──────────────────────────────────────────────────────────┘  │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Both layers run on every validator. The layers are not separate networks — they are two roles of the same L1.

The execution layer (EVM inside SGX)​

This is where your Solidity contracts run.

Every validator loads the EVM inside an Intel SGX enclave. When your transaction arrives, the enclave:

  1. Verifies the transaction signature (standard EIP-155 rules — nothing OXN-specific here)
  2. Decrypts the encrypted calldata (if the client sent an encrypted envelope)
  3. Reads and writes storage through the enclave's per-contract encryption keys
  4. Executes the EVM bytecode
  5. Encrypts the return data back to the caller's session key
  6. Emits event logs (also encrypted with the caller's session key)

Because every step after signature verification happens inside the enclave, the node operator and everyone else outside the enclave cannot see the calldata, return data, storage contents, or event contents. See Confidentiality Model for the exhaustive list.

The execution layer holds balances at EVM addresses (0x…), and speaks standard Ethereum JSON-RPC on port https://rpc.bout.network. Wallets, ethers.js, viem, Hardhat, Foundry — all connect here.

The consensus layer​

This is what actually agrees that a block is a block. It runs a Byzantine Fault Tolerant (BFT) consensus algorithm — validators propose blocks, vote on them, and a block becomes final the moment it collects enough votes. No probabilistic finality, no reorgs.

The consensus layer:

  • Orders transactions — decides which transaction runs before which
  • Finalizes blocks — a block is either final or not; there is no "safe / justified / finalized" distinction as on Ethereum
  • Holds native balances — accounts identified by oxn1… bech32 addresses live here
  • Manages validator staking on mainnet (not open in the current testnet phase)
  • Distributes enclave key material — long-lived enclave keys are rotated and backed up across validators using a distributed key management protocol

Most dApp developers never interact with the consensus layer directly. It is exposed through the wallet's "deposit" and "withdraw" flow, and (later) through validator operations.

How the layers exchange value​

Native tokens live on the consensus layer at oxn1… addresses. EVM contracts live on the execution layer and can only work with balances at 0x… addresses. To use funds inside EVM contracts, users deposit them from the consensus layer to the execution layer. To move value back to a native address (for example, to stake in the future), users withdraw.

The Web Wallet has both directions in its UI. Programmatically, deposit is a consensus-layer transaction that credits an EVM address; withdraw is the reverse.

For the specific address formats and how the two are related, see Accounts & Addresses.

Where TEE enforcement sits​

The SGX enclave protects only the execution layer, not consensus. This is deliberate:

  • Consensus needs to be publicly auditable. Anyone should be able to verify that a block was finalized correctly, that validators voted honestly, that the ordering rules were followed. Encrypting consensus would defeat this.
  • Execution needs to be private. Your contract's state and inputs are what matters to hide.

The result: transaction ordering, validator identities, staking flows, and native balances are all public. Contract execution — the thing that actually matters for confidentiality — happens inside the enclave.

What "one L1" actually means​

OXN is not a rollup. The execution layer does not post proofs or data to any other chain. It relies on the consensus layer for finality, and the consensus layer relies only on its own validator set. Both layers are part of the same sovereign network.

OXN is not a bridge or sidechain. No trusted intermediary sits between the two layers. They are two roles of the same nodes.

OXN is not a multi-chain setup. Deposits and withdrawals move value between address formats within the same chain, not between different chains. Your OXN never leaves OXN unless you use an external bridge (see Bridges — not yet available).

Next steps​