Extended Chain · System Cross-Section

Sealed. Ordered. Settled.

A trading network in three layers: orders encrypted into attested hardware, sequenced by Byzantine consensus every thirty milliseconds, and settled with STARK cryptography on-chain. Scroll to follow one order all the way down.

follow the order

Layer 01 · TEE Confidentiality

Your order leaves the browser already encrypted.

Before a single byte is sent, the app verifies it is talking to genuine sealed hardware — an AWS Nitro Enclave whose identity is signed by the silicon itself and pinned to our release key. Only then is the order sealed to a key that exists nowhere outside that enclave. The load balancer, the host machine, the operator: all of them relay ciphertext they cannot open.

Cipher HPKE · X25519 · HKDF-SHA256 · ChaCha20-Poly1305 (RFC 9180)
Domain "extended-chain/enclave-submission/v1"
Wire [u16 len][encapped key · 32 B][ciphertext]
Attestation COSE_Sign1 · ES384 · 8444a1013822a059… signed by the AWS Nitro Security Module, verified in your browser against the AWS root
Release pin PCR8  0d7633d5def8fbb4…e3455fda the enclave image's signing-certificate measurement — if it isn't ours, the app refuses to send

What can't be read can't be traded against.

Nearly every form of MEV — sandwiching, front-running, selective delay — begins with the same advantage: someone sees your order before it executes. On a public mempool your intention is broadcast to the world; on a conventional exchange it's visible to the operator. Here that window never opens. Your order crosses the wire, the load balancer, and the operator's own machines as ciphertext, and becomes readable only inside attested hardware — at the moment it is already being sequenced.

Sandwich attack

needsto read your buy while it's pending, then insert a buy in front of it and a sell behind it

herethere is no pending plaintext to read — the order is ciphertext until it is sequenced, and ordering is by arrival time — there is no way to buy a place in the queue

Operator front-running

needsan operator who can watch its own customers' order flow

hereplaintext exists only inside the enclave, and attestation proves the code that sees it is the published build — not a modified one that leaks

Selective censorship

needsto pick your order out of the flow and quietly delay it

hereevery sealed order is an identical opaque blob to the host — it cannot distinguish yours, so it cannot single yours out

Priority-fee auction

needsa fee market that sells the right to jump the queue

herethere is none — arrival order is execution order, and a bot with a bigger fee buys nothing

Timestamp games

needsa block proposer bending time to trip stops and expiries

hereblock time is itself consensus — a proposer whose timestamp strays from the validators' clocks is voted down

Confidentiality closes the information edge. Fair ordering — one layer down — closes the positional one. Together they reduce to a simple guarantee: your order executes where it arrived.

{ "market": "BTC/USDC",
  "side":   "buy",
  "qty":    "0.250",
  "price":  "97,140.00",
  "tif":    "GTC" }

Illustration only — in the real app, sealing runs RFC-9180 HPKE inside WebAssembly, after attestation verifies.

Follow one order through the machine

Browsersigned, then sealed — plaintext never leaves
Load balancerTLS terminates here; all it holds is an opaque blob
Hostthe operator's machine relays ciphertext it cannot open
Enclaveattested hardware opens the order — first plaintext since your browser
Consensussequenced by arrival; ⅔+ of the voting power signs the block
Blockcommitted under one state root — public, final, verifiable

order · plaintextleaves your device

Layer 02 · Distributed Consensus

The network agrees — every thirty milliseconds.

Decrypted orders are sequenced by Byzantine fault-tolerant consensus. A block closes about every 30 ms, and it exists only once validators holding more than two-thirds of the voting power have signed it. Ordering is by arrival time — refined by deterministic protocol phases (cancels land first, resting quotes before takers), and never by fee. Every validator re-executes every block and must arrive at the same state root, bit for bit. Even the clock is consensus: a proposer that bends its timestamp is voted down.

execute propose validate vote commit

the proposer runs every trade and computes the state root

scroll to drive the cycle — the live network completes it every ≈ 30 ms

#12,847,203 block height · one block ≈ 30 ms
  • ConsensusTendermint-family BFT · safe with up to ⅓ of voting power Byzantine
  • Throughput150,000+ tx/s measured under load
  • Fairnessordered by arrival time · deterministic phases (cancels → resting → takers) · never by fee
  • Determinismindependent re-execution → identical state roots
  • Clock boundblock timestamps are validated against every validator's own clock

The enclave keeps secrets. It doesn't get a vote.

Trusted hardware is easy to over-trust. Here, its authority ends at confidentiality: enclaves keep orders unreadable until they are sequenced — and nothing more. Fairness and correctness are enforced the old, hard way: independent machines checking each other's work. Every validator re-executes every block, and a single bit of disagreement in the state root means the block never existed. If every TEE on earth failed tomorrow, no balance could be forged, no trade rewritten, no funds moved. The failure would cost privacy — never correctness.

The enclave guarantees

  • orders stay unreadable until sequenced
  • the code touching plaintext is the published build — proven by attestation
  • nothing else — by design

Consensus guarantees

  • ordering — by arrival, agreed by ⅔+ of voting power
  • correctness — every block independently re-executed, roots matched bit for bit
  • fund safety & liveness — through up to ⅓ Byzantine power
  • even the clock

A broken enclave can leak a secret. It cannot mint a balance.

Layer 03 · Onchain Settlement

Settlement is mathematics, not trust.

Every order is signed on the STARK curve over Poseidon hashes — the native cryptography of Starknet. Funds enter and leave through the on-chain bridge, and keys never leave their owner. What consensus finalizes, the ledger records — and the contracts verify: every change to a user's on-chain state is validated by smart-contract logic and zero-knowledge proofs. A second, independent line of defense, beneath the validators themselves.

Signature STARK-curve ECDSA over Poseidon hashes
Domain Perpetuals · v0 · SN_SEPOLIA (rev 1)
Tx identity keccak-256 of the signed envelope — computed by you, confirmed by the chain
Custody user-held keys · deposits & withdrawals via the Starknet bridge
State root ab14ac61756d60ff…9d6d5898  ✓ agreed by quorum one root per block — the whole exchange state, committed as a single hash

Defense in depth: even a rogue network can't reach your funds.

The validator set is layer two of your protection, not the last. On-chain, the smart contracts hold their own line: no state transition is accepted without the proofs that justify it. If every validator conspired tomorrow, the contracts would still refuse to move a single token without its owner's signature, still refuse any update that breaks solvency, and still honor your exit. Trust the network for speed — you don't have to trust it with custody.

validate refuse escape

every state change arrives with the owner's signature and a solvency proof — the contract checks both before anything moves

assets ≥ liabilities

scroll to drive the gate — three guarantees, one contract

Authentication nothing moves without the owner's STARK-curve signature checked by the contract itself — validators cannot forge it, and neither can we. Self-custody as a hard requirement, not a promise.
Escape hatch a forced-withdrawal path lives in the contract if the network halts or censors, you exit on-chain against the last proven state — permission from no one.
Solvency every operation must leave the protocol solvent state updates carry proof that assets cover liabilities — an update that would break solvency is unexecutable, so insolvency cannot be hidden or deferred.

order settled · final


Foundation · Open source from day one

Don't take our word for any of this.

Everything above is checkable only because the code is public — from day one, not after the audit, not once it's convenient. The enclave measurement your browser pins is just a hash; it means something because anyone can take the source, run the same reproducible build, and arrive at the same number. The contracts that hold custody are guarantees because anyone can read them. Closed source would collapse all three layers into promises. Open source turns them into checks — attestation without source is a black box with a serial number.

read build verify

the full network — enclave, engine, contracts — public and clonable from the first block

public repository

scroll to run the check yourself — that is the entire point

Enclave build the enclave image from source → your PCR8 must equal ours the attestation your browser verifies is only as honest as your ability to reproduce it. If the hashes differ, walk away — that is the system working.
Contracts custody, solvency, escape hatch — readable line by line audits are the floor; your own eyes are the ceiling. The logic that guards funds is exactly the logic you can read.
Network consensus, matching, cryptography — the whole node, clonable and runnable verify blocks independently, recompute state roots, check our math from the outside.

trust math you can read