Resolution: binary or scalar at 0 to 100% (tick = 0.01%). Longs are paid the
outcome fraction per unit, shorts the remainder. HIP-4 settleFraction semantics, exactly.
creator slots remaining—
Creation is permissionless within a granted allowance.
Reactor grants creator slots to a limited set of projects (dev accounts get 100).
REPLICATE HIP-4 mirror live Hyperliquid outcome markets, 1:1
Fetches outcomeMeta from the HIP-4 info API. Titles & provenance
(hip4:<id>) are copied precisely; already-replicated markets are skipped.
ENGINE SEQ
—
MARKETS
—
OPEN ORDERS
—
ACCOUNTS
—
ESCROWED
—
STATE ROOT recomputable by anyone from the WAL
—
keccak-256 merkle root over every (account, balance) leaf, committed onchain
at the engine sequence shown. Forced exits verify membership proofs against it.
SETTLEMENT
chain—
escrow—
collateraltUSDC (6dp)
exit pathrequestExit → proof → forcedWithdraw
COMMITMENT HISTORY state roots observed this session
—
ACTIVITY all markets
no trades yet
A self-custodial matching engine for permissionless outcome markets.
Exchange-grade order matching runs offchain in microseconds. Collateral stays in an onchain escrow
you can always exit. List any market, or clone a live Hyperliquid market and settle it identically.
Robinhood Chaincustody and state-root commitments settle onchain, live on testnet.
HIP-4 Mirrorclone any live Hyperliquid outcome market one to one.
Pooled Maker Liquiditya shared MakerVault quotes both sides, real depth on day one.
Web app
Simulator
Gateway
MakerVault
ENGINE
Sequencer
Matching core
WAL
Keeper
Hyperliquid
Bridge
ONCHAIN
Escrow
Oracle
State root
THE PATH OF AN ORDER deterministic end to end, the animated dot is one order
SIGN
ed25519 session key
SEQUENCE
strict arrival order
MATCH
price-time, µs-class
LOG (WAL)
public, replayable
STATE ROOT
keccak merkle
ESCROW
onchain
Because matching is a pure function of the ordered log, anyone can download the
log, replay it in the open-source engine, and recompute the state root byte-for-byte. The operator
cannot lie about balances. A wrong root is provably wrong.
PRICING
Buy 10 YES at 52.00%you escrow 520
YES 52%
48% NO
Counterparty (backs NO) escrows480
Pot backing the pair1,000 = 100%
If it resolves YES → you receive1,000
If it resolves NO → you receive0
Every position is fully collateralized: the two sides
together escrow exactly 100% per unit, so the venue is never short a payout. Scalar markets settle
anywhere in between, longs get the outcome fraction, shorts the rest. This is HIP-4
settleFraction semantics, exactly, which is why HIP-4 markets replicate 1:1.
WHY MATCHING IS FAST
1
Single-writer, lock-free core
One thread owns the book; no locks, no contention. A flat price ladder + intrusive
FIFO queues give O(1) best-price and price-time priority. 12M ops/s, 41ns p50 on one core.
2
Event-sourced & deterministic
The engine is a pure state machine over an append-only log. Crash recovery = replay;
hot-standby = replay-behind. The same property is what makes it verifiable.
3
Signatures are the only real cost
At scale, verifying ed25519 dominates, not matching. Verification is horizontally
scalable, so throughput grows with cores while the core stays a single fast writer.
⚡
Chain does only what chains are good at
Custody + periodic commitments. No per-order gas, no block-time latency on the hot path.
Runs on Robinhood Chain, HyperEVM, or any EVM chain behind one adapter.
CUSTODY
↓
Deposit into escrow
Collateral sits in an onchain contract, credited to your engine account through the
public log. The venue never holds your keys.
✎
Operator commits a state root
A keccak merkle root over every (account, balance) is posted onchain periodically,
recomputable by anyone from the log.
✓
Forced exit if it misbehaves
If the operator halts or censors, requestExit → proof → forcedWithdraw pays your
proven balance straight from escrow against the last root. No permission needed.
PERMISSIONLESS MARKETS
＋
A market is just a signed command
A question, an order book, and a resolution source. No listing committee, no governance
vote, creating one is an entry in the log like any order.
◧
Open or limited, operator's choice
Run it fully open (anyone creates) or in limited mode, where creator slots are
granted to a curated set of projects. Either way it's a WAL command, fully auditable.
⟳
Replicate HIP-4, 1:1
Mirror any live Hyperliquid outcome market from the Create page, exact title,
provenance stamped hip4:<id>, settlement mirrored from the HIP-4 oracle.
operator controls, load generation runs locally against the gateway
LOCKED
ADMIN KEY
PERMISSIONLESS MODE who may create markets
Limited: creation consumes granted creator slots (the "limited projects"
model). Fully open: any account may create markets with no quota. This is an operator
command written to the WAL like any other.
Pays longs the outcome %, shorts the rest, then closes the book.
HIP-4 markets auto-resolve from Hyperliquid via the keeper. This is the manual override.
STRESS TEST local load, measures real signed TPS
LIVE THROUGHPUT idle
TPS (NOW)
—
PEAK TPS
—
TOTAL ACKED
—
FILLS
—
MARKETS MADE
—
Signed throughput, generated in-process — every command is ed25519-signed
by a local session and verified by the gateway, so this is realistic production load, not a
synthetic ceiling. Client signing + server verification share this machine; a dedicated
load box and verify cores go higher. Conns = 0 ·
rejects (no-fill IOC / quota / risk) = 0 ·
elapsed 0s.
BENCHMARK RESULTS measured, M1 Max, click a row for the method
LAYER
THROUGHPUT
LATENCY p50
BOUND BY
Matching core
raw order book, no I/O
12.3Mops/s
41ns
CPU / cache
details ›
Full pipeline, unsigned
TCP + sequencer + WAL
236kcmds/s
—
network + syscalls
details ›
Signed, end to end
ed25519 per command, production path
~95kcmds/s
—
signature verify
details ›
Three layers of the same system. The core is the engine's ceiling; strip crypto and
you measure the network path; add crypto and you get the production number. Signature verification
is horizontally scalable, the ceiling isn't the engine.
—
Profile
not connected
COLLATERAL
balance—
reserved (resting orders)—
free—
Dev session: the shim holds this account's ed25519 session key and signs every
order. Production: wallet connect + EIP-712-authorized session keys, deposits via the escrow
contract.
POSITIONS
none
OPEN ORDERS all markets
none
REACTOR
Permission to predict.
✓Binary outcome markets, now on Robinhood Chain
✓Supports permissionless deployments
✓HIP-4 compatible, 1-click market mirroring
✓Ultra-high-performance matching engine
Connect account
Sign a session authorization with your wallet. The session signs every order with an ed25519
session key bound to your address, the same connect flow as parlays.live.