Introduction

audience: all

This book proposes a block-building topology for EVM chains built as a composition of mosaik-native organisms. The topology is designed for:

• Anonymity at submission. Authors of transactions and intents cannot be linked to the content they publish by any single party in the pipeline.
• Sealed-bid auctions over order flow. Searchers bid on bundles without learning each other’s offers until a round commits.
• Verifiable co-building across many operators. Candidate blocks are assembled inside TDX-attested committees; no single operator can unilaterally reorder or censor.
• MEV-aware refund accounting. Value captured on a winning block is attributed back to the order-flow providers that contributed to it, under a public-verifiable attestation.
• Cross-chain coordination. Lattices on different chains coexist on the same mosaik universe and can cross-subscribe for cross-chain bundles and shared order-flow markets.

The product of this repository is a design book, not a shipped binary. Follow-on crates — one per organism — will land in later pull requests. Where code samples appear, they are specifications, not library calls you can cargo add today.

Why another topology

The block-building pipeline across EVM chains today is either a handful of centralized monoliths (one builder owns the order flow, the building, the relay, and the refund accounting) or a stitched- together mesh of services from different authors with incompatible trust models, opaque interfaces, and no shared identity story. Flashbots Writings — decentralized building: wat do? names the pattern of decentralization this topology targets: Phase 1 — replicated privacy inside TEE-attested committees, Phase 2 — co-built blocks across permissionless participants, Phase 3 — globally parallel building. The lattice proposed here is a Phase 1 to Phase 2 shape, chosen so every organism in it can decentralize at its own pace without forcing the others.

This book assumes familiarity with the block-building vocabulary (PBS, order flow, bundles, MEV-Share, TDX, relays, sequencers on L2); it does not re-derive them. It does assume the reader is new to mosaik and, if they care about submission-layer anonymity, also to zipnet — links are provided the first time each concept appears.

What a lattice is, in one paragraph

A lattice is one end-to-end block-building deployment for one EVM chain. It is identified by a short, stable, namespaced instance name (e.g. ethereum.mainnet, unichain.mainnet, base.testnet) and composes six mosaik-native organisms under that name:

1. zipnet — anonymous broadcast of sealed transactions and intents (the existing organism; see the zipnet book).
2. unseal — a threshold-decryption committee that unseals zipnet broadcasts for the next organism without revealing cleartext to any single operator.
3. offer — a sealed-bid auction committee where searchers place bundle bids over an unsealed order-flow pool.
4. atelier — a TDX-attested co-building committee that assembles candidate blocks from the unsealed pool and the winning bids.
5. relay — a PBS-style fanout committee that ships header + bid pairs to proposers (or, on L2, to sequencers).
6. tally — a refund accounting committee that attributes MEV captured on the winning block back to the order-flow providers whose transactions and bids contributed to it.

Every organism follows the mosaik pattern zipnet shipped with: a single Config struct that folds every signature-altering input into a deterministic UniqueId; a narrow public surface of one or two primitives; a TicketValidator composition gating bonds; typed Organism::<D>::* free-function constructors that hide raw StreamId / StoreId / GroupId values from integrators. Multiple lattices coexist on the shared universe builder::UNIVERSE; an integrator compiles in a LatticeConfig for each one it cares about and binds with one Arc<Network>.

The full rationale — why six organisms, why this decomposition, why shared universe — is in Designing block-building topologies on mosaik.

What this topology provides

• Unlinkability of transactions to senders up to the trust boundary of the zipnet and unseal committees. See threat model.
• Sealed-bid auctions where searcher bids are invisible to competing searchers and to the builder until the auction commits.
• Multi-operator block assembly where the builder is a committee, not an entity. No single operator controls the winning block.
• Verifiable ordering and attribution via Raft-replicated state machines inside every organism. Every decision — which bundle wins, which transaction got refunded — is a committed command in an auditable log.
• One Arc<Network> across the whole pipeline. Integrators bind every organism they care about off one mosaik endpoint; operators run one process per organism role per host, scheduled however their ops stack prefers.

What it does not provide (yet, or by design)

• Byzantine fault tolerance. Each organism uses mosaik’s crash-fault-tolerant Raft variant. Deliberately compromised committee members can DoS liveness; anonymity, auction integrity, and block validity all retain the properties promised under the organism’s specific trust assumption (any-trust for anonymity, majority-honest for auction commit, t-of-n for unseal).
• A canonical implementation. The proposal is a shape. Operators are expected to implement — or consume implementations of — the organism crates, and teams with different operational preferences can ship distinct implementations of the same organism surface.
• An on-network lattice registry. Lattices are operator-scoped; discovery is a compile-time Config reference, same as zipnet. See topology-intro — A fingerprint convention, not a registry.

Three audiences, three entry points

Every page in this book declares its audience on the first line and respects that audience’s tone. Pick the one that matches you:

• Integrators — external devs (searchers, wallets, rollups) whose agent publishes into or reads from a lattice somebody else operates. Start at Quickstart — submit, bid, read.
• Operators — teams deploying and maintaining a lattice. Start at Lattice overview then Quickstart — stand up a lattice.
• Contributors — engineers extending the topology itself, or standing up a seventh organism that reuses the pattern. Start at Designing block-building topologies on mosaik then Architecture of a lattice.

See Who this book is for for the conventions each audience is held to.

Relationship to existing Flashbots work

• BuilderNet is the closest existing system to the lattice. The atelier organism is a mosaik-native restatement of BuilderNet’s TDX co-building pattern; tally is a restatement of its refund accounting. The lattice generalises by making the other four organisms first-class, composable, and deployable independently.
• Rollup-Boost and L2 TEE block builders map cleanly onto a single-operator lattice with offer and relay swapped for the L2’s sequencer interface. See Cross-lattice coordination.
• Flashnet / zipnet is the submission organism. This proposal does not re-specify it; it consumes it.
• Mosaik is the substrate. This proposal does not re-specify mosaik primitives; it uses them.

Layout of this book

book/src/
  introduction.md              this page
  audiences.md                 tone and conventions per audience
  integrators/                 for external devs binding to a lattice
  operators/                   for teams running a lattice
  contributors/                for engineers extending the topology
  appendix/                    glossary, env vars, metrics