ONYXdevnet

Why sealed-bid batching kills front-running

ONYX bets are committed as a hash, revealed after the window closes, and matched in one deterministic batch at a single uniform price. There is nothing to observe before the match, and nothing to gain from ordering — this page shows the mechanism and the real devnet transactions that prove it.

1 · The problem: a visible order is an invitation

illustration — not live data

On a public book, a pending order sits in plain sight before it executes. A searcher who sees a large order can buy in front of it and sell right after — the classic sandwich. The victim pays the spread the attacker created.

The attack needs exactly two things: seeing the order before it executes, and being able to get in line around it. Remove either and the sandwich is dead.

2 · How ONYX removes both — on L1, no new trust

shipped · devnet
  1. open_market_sealed

    Market opens in a commit phase with fixed commit and reveal windows.

  2. submit_sealed_order

    Only a 32-byte keccak-256 commitment plus locked collateral lands on-chain. Side, size, and limit price are not derivable from any on-chain state. Nothing to see.

  3. reveal_order

    After the commit window closes, each bettor reveals; the program recomputes the hash and rejects any mismatch.

  4. run_batch_match

    Permissionless. All revealed orders clear in one pass at a single uniform price. Nothing to get in line around.

Order-independent by construction

Take the same three revealed orders — A₁ buys 100 @ 70, A₂ buys 200 @ 60, B₁ sells 90 @ 50 — and feed them to the matcher in any order. The program's own unit test (matching::tests::order_independence) asserts the result is bit-exact identical:

[ A₁, A₂, B₁ ]→clears at 50 · fills 30 / 60 / 90
[ B₁, A₁, A₂ ]→clears at 50 · fills 30 / 60 / 90
[ A₂, B₁, A₁ ]→clears at 50 · fills 30 / 60 / 90

Same price, same fills, every permutation. When submission order cannot change your outcome, being first — the entire business model of front-running and copy-trading — is worth nothing.

3 · Proven on devnet, not claimed

public RPC · verify without trusting this UI

One full sealed-order lifecycle on market 2VGU78vk…kHdHG4. Every signature is real; open it on the explorer or run solana confirm -v <sig> --url devnet — none of it needs this UI to be trusted.

4 · What about TEEs? Roadmap, not shipped

de-risk spike · held back

A MagicBlock ephemeral-rollup / TEE execution path (sealed orders matched inside an attested enclave, ~10ms latency) was proven end-to-end as a de-risk spike — including a live DCAP-verified attestation — and then deliberately not built into this product. Everything above runs on plain Solana L1 devnet, because moving matching into a TEE would reintroduce a hardware and operator trust dependency this design exists to avoid. The spike is logged in BUILD_STATE.md; it is roadmap material, not part of what you just verified.