Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Overview — an MEV-searcher AI bot on testnet-1a

audience: ai

This is the first of three Part II examples, walked through seven chapters. The example: an AI-policy MEV searcher bound to a Flashbots-operated instance of the builder (6e3v) block-building lattice, named testnet-1a. The searcher lives in its own small coalition, searcher-α, which references testnet-1a as a member.

The goal is not to specify a production searcher. It is to walk one concrete composition, from cold start to autonomous renewal, end to end — so that every mosaik surface named in Part I is exercised in a setting a reader can reproduce. Each chapter adds one surface; none invents a new primitive. Parallel examples for the provider side (web2) and the publisher side (oracle) exercise the same rungs against different compositions.

Market makers get a named variant at the end of each chapter where the pattern diverges. The MEV- searcher path is primary; market-makers share almost all the mechanics and differ only in what they read, what they submit, and on which reputation and settlement surfaces they bond.

What is assumed

  • The 6e3v lattice is shipped. The builder book specifies six organisms (zipnet, unseal, offer, atelier, relay, tally) composed into one end-to-end block-building pipeline for one EVM chain. We do not re-derive that composition; we bind against it.
  • Flashbots operates an instance. The instance is named testnet-1a. Its LatticeConfig stable id is published in Flashbots’ release notes and is reproduced in setup; it folds the Flashbots operator’s ACL, its per-organism TDX Measurements where TDX is gated, and its shared clock and retention policies.
  • Readers understand Part I. The four agent shapes, the four emergent-coordination patterns, the TDX/non-TDX split on what Config hash-binds, and the self-replication and self-modification cycle from ai/sustainability.md are load-bearing. Part II does not re-explain them.
  • No implementation crates yet. Code blocks are rust,ignore specifications; their shapes match the book’s crate plan (coalition, coalition-compute, the pinned builder crate exposing LatticeConfig). Everything compiles in the reader’s head; nothing compiles in cargo.

The searcher’s shape

  • Coalition. searcher-α — the searcher’s own CoalitionConfig. Its COA_LATTICES field references testnet-1a’s stable id; it ships zero basic services in the minimal version (setup), optionally adding Compute and Chronicle in inference and sustainability.
  • Primary member. One shape-2 standalone organism — the searcher agent itself, as the AI policy wrapped in a narrow public surface. Its Config folds a model-family digest, a decoding seed, a mission-statement hash, and the searcher’s admission policy. When its inference runs in TDX, Config.content also folds the image post-hash.
  • Secondary members. A feed organism (see wrapping) and, from chapter 5 onward, an accuracy-reputation organism and a candidate-strategy experimenter (sustainability).
  • Bindings across coalitions. searcher-α’s ticket composition bonds against testnet-1a’s read-side organisms (tally::Refunds, offer order flow where permitted) and against its sealed- submission pipeline (zipnet::seal). Some of these bonds are pinned to specific TDX Measurements the Flashbots operator publishes for testnet-1a; see binding.

What runs where

ComponentOperatorTDX?
testnet-1a latticeFlashbotsVaries per organism
testnet-1a.zipnet sealed submissionFlashbotsTDX Measurements pinned
testnet-1a.unseal committeeFlashbotsTDX Measurements pinned
testnet-1a.tally refund accountingFlashbotsAttested-read-only
searcher-α.searcher agent organismSearcher teamTDX optional; required for confidential strategies
searcher-α.feed.binance-depth (example)Searcher teamTDX optional
searcher-α.accuracy-reputationSearcher team (or a shared reputation organism)TDX optional
searcher-α.compute (when shipped)Searcher teamDelegates to provider MR_TD

The table is read by every subsequent chapter. When an endpoint reads “TDX Measurements pinned”, the searcher’s TicketValidator requires a matching measurement — which, by the TDX arm of the convergence mechanism (ai/sustainability.md), means the searcher is agreeing to run (or to bond against) a shared runtime policy.

Chapter-by-chapter contract

  1. Setup and shape — dependencies, CoalitionConfig for searcher-α, the stable id of testnet-1a, TDX posture.
  2. Binding to the Flashbots lattice — the handshake, the searcher’s TicketValidator composition, first smoke-test against testnet-1a’s public surfaces.
  3. Reading the market — on-mosaik surfaces — tally::Refunds, offer order flow, cross- lattice subscriptions where available.
  4. Wrapping non-mosaik feeds — mempool, CEX depth, on-chain events lifted into mosaik Streams as feed organisms.
  5. Inference on Compute — running the searcher’s policy via the Compute basic service, TDX-gated when confidential, top-up and experiment-scheduling loops.
  6. Sealed submission and settlement — bundle construction, zipnet → unseal → offer pipeline, settlement evidence pointers, refund attribution.
  7. Reputation, retirement, successor chain — accuracy-reputation bonding, autonomous renewal through staging-promote-publish, operator- side exit guarantee.

Every chapter closes with a market-maker variant note where the pattern diverges. Where it does not diverge, the note is omitted.

Register and non-goals

  • Register. audience: ai — research-monograph, pattern-forward, code-forward where a shape is load-bearing. Part II stays adjacent to ai/quickstart.md and ai/compute.md in density and tone; it exhibits the thesis rather than restating it.
  • Non-goal. Part II is not a searcher design guide. One concrete strategy — atomic two-venue DEX arbitrage — is walked in inference to keep the example concrete and exercise every mosaik surface the thesis names. Production searchers compose many more (inventory management, liquidations, cross- domain arb, MEV-share order flow, block-lookahead simulation); those questions stay out of scope. Where the substrate touches them, we name the boundary and stop.
  • Non-goal. Part II does not enumerate every Flashbots testnet-1a operator policy. Specific rate limits, ACL cadences, and refund shares are the operator’s publication; we pin only the shape of the handshake and the measurement sets the searcher must verify.
  • Non-goal. Part II is not a comparison with existing MEV-Share or relay integrations. The book treats the mosaik-native composition on its own terms; prior art sits in the builder book.

Cross-references