FOR THE SKEPTIC

How it actually works.

It reads the contracts, then it reads the chain. When the chain does something new, frontier AI studies it once and writes down what it means. A deterministic engine applies that understanding to every matching transaction. Cost scales with what is new — not with how big the chain gets.

The scope, exactly

One continuous window of Sui mainnet: 2026-07-19, 13:01–23:37 UTC — 1,000,000 eligible user transactions, frozen and replayed.

eligible transactions1,000,000
carrying a full end-to-end reading897,004 — 92.19% of the 973,045 classifiable (26,955 excluded: empty, nothing executed, or contradicted) · 89.70% of the entire million
distinct senders101,334
exact transaction shapes19,630
accepted whole-transaction patterns1,173 across 54 behaviors
contract studies642 written from deployed bytecode · 114 already serving this proof
sponsored (gas paid by someone else)248,486

Coverage is a census, not an accuracy score. Rows the system cannot fully classify stay visibly partial rather than silently filled — that discipline is the product, not a caveat.

Why it scales

A million transactions collapse into 19,630 exact shapes. Understanding is authored once per novelty and reused across the whole cohort — one authored paragraph explains 165,204 order cancellations. Replaying the entire million from frozen evidence takes 87.102 seconds on average (84.255–89.053 across five runs, idle host, all 1,000,000 transactions). Falling model prices make the library cheaper to extend, not obsolete.

The root artifact

Before a contract's transactions are explained, its exact deployed revision gets a study written from the bytecode itself — 642 written so far, 114 already serving this proof, the rest shipping as the store grows. Verbatim:

DeepBook: DeepBook order-book account and owner maintenance

This revision is an owner-facing control surface for a DeepBook order-book account. It holds funds in a `BalanceManager`, obtains owner authorization from the transaction sender, routes trading and cancellation actions to a pool, and exposes a quote-only path plus a quote-side flash-loan lifecycle. The package is an adapter and account-management layer around the order-book venue, not the venue itself.

The owner deposit path accepts a typed coin, verifies that the sender owns the balance manager, converts the coin into the manager's typed balance, and records the deposit. The resulting value remains in manager custody until a later trade, settlement, or withdrawal uses it. The deposit event is emitted before the owner check in bytecode order, but transaction atomicity removes it if the check fails.

The withdrawal path uses the same owner proof and removes the manager's complete recorded balance for the requested asset, returning it as a coin and emitting a withdrawal event. This function does not choose an external recipient; the returned coin becomes a transaction result whose later handling determines who ultimately receives it. An ownership failure or balance-access failure leaves the manager unchanged.

0xcaf6ba059d539a97646d47f0b9ddf843e138d215e2a12ca1f4585d386f7aec3a

What the current proof does not claim

No temporal generalization beyond the window. No entity resolution — an address is never a person. No profit claims without their own evidence. Dollar figures are estimates from declared third-party prices, never part of an asserted sentence. Live ingestion, full history and other chains are the destination, not the demo.

Want the deeper cut — evidence formats, replay determinism, the authoring gates?

Ask us anything → bartosz@research.tech