Verify it yourself

The whole point of moving the loop on-chain is that you don’t have to take any of this on faith. Every number on this site is re-derivable from a public RPC, by you, without asking us for anything.

Run it with an empty .env

Every read this project depends on is keyless. No private key, no API key, no account:

pnpm install
pnpm build:contracts   # compiles the vendored DreamDEX interface + the agent
pnpm test:contracts    # the risk-gate and adapter suites
pnpm discover          # every live Event Contract window, from chain logs
pnpm preflight         # verifies every on-chain read the agent makes
pnpm web               # this site, at localhost:3000

discover reads MarketCreated logs directly, so it works even when the venue’s indexer is down. This site uses that same keyless path — the SDK requires a private key at construction, and a public web server must not hold one.

What preflight proves

The official DreamDEX template flags one struct as unconfirmed: “the one struct to double-check against the live ABI before you rely on it is OrderBookLevel.”

Checking that the values merely look plausible is not enough — if price and quantity were transposed, both are plausible uint256 and both can land inside a valid range. The discriminator is monotonicity, so that is what gets asserted:

ok   every level has 0 < price < 1e6 and quantity >= 0
ok   price arrays are monotonic by side — field 0 really is price, not quantity
ok   best bid 331000 < best ask 357000 — book is not crossed
ok   OrderBookLevel layout CONFIRMED: (price, quantity)

Bid prices must descend and ask prices must ascend. That only holds if field 0 is really price. Quantities have no reason to be ordered, and observably are not.

Rebuild the evidence

pnpm index    # chain logs → results/receipts.jsonl
pnpm verify   # re-derive every published number from a public RPC

verify never trusts the file it reads. For every row claiming an order, it fetches that transaction from the chain and checks the agent really sent it and the decoded arguments really match what was published. It asserts that a row claiming a gate pass carries an order and a row claiming a rejection does not, and that no row claims more agreeing validators than the subcommittee that actually ran.

It exits non-zero on any mismatch, and writes results/RESULTS.md in the same pass — so a number in the results file that this script cannot re-derive cannot exist.

Running the keeper and seeding agents

These are the two live operations that keep the board moving. Both default to DRY_RUN, so you can watch them talk to the chain and act as if they made decisions before letting them make real ones:

pnpm seed    # deploy the personality agents (DRY_RUN=true by default)
pnpm keeper  # poke agents, expire stale requests, redeem settled positions

The keeper makes no decisions and holds no authority — it only calls the permissionless functions on agents it doesn’t own, so anyone can run one and get identical behavior. Set DRY_RUN=false in .env to let a run post real transactions.

What gets published

decisions attempted and completed end to end
consensus rate, with every timeout and disagreement listed
gate rejections, broken down by rule
latency as median and p95, measured from block timestamps
every DreamDEX transaction hash
realized P&L, including the losses

Counts and percentiles only — never “fast”, never “reliable”. A curated record would defeat the entire point of building it this way.

Nothing is hardcoded, so nothing can be quietly stale. No asset list, no cadence list, no pool addresses, no market ids. If the venue lists something new it shows up here on its own — and if the venue stops running something, it disappears. What you see is what the chain says.