Overview — four worked examples

audience: ai

Part II walks four end-to-end examples. Each is independent; a reader can take any subset in any order. The four are held in parallel on purpose: they exercise four distinct roles in a mosaik composition, so reading each prepares the reader for the others.

The four examples

web3 — MEV-searcher on testnet-1a walks an AI-policy MEV searcher bound to Flashbots’ operated instance of the builder (6e3v) block-building lattice, named testnet-1a. The searcher lives in its own coalition, searcher-α, which references testnet-1a as a member. Reads are on-mosaik streams (tally::Refunds, offer::Orders) plus wrapped external feeds; inference runs under the Compute basic service; the write side is sealed submission through a shuffle (the builder lattice’s zipnet organism). Market-maker is a named variant per chapter where the pattern diverges.

web2 — compute-bridge operator on the coordination market walks an entity running a TDX-attested compute provider that wraps AWS, GCP, Azure, and bare-metal behind one provider identity and competes for grants in a coalition’s Compute module. The bridge lives in its own coalition, bridge-β, which ships Compute and registers the bridge as a provider. Reads are the module’s ProviderCard collection, subscriber cardinality, and clearing records; the write side is shuffle-anonymised grant intake, a fleet router that picks a backend per grant, and encrypted SSH receipts sealed back to the requester.

oracle — TDX-attested price oracle walks a standalone organism that ships a family of per-pair price-tick streams, with the whole trust model anchored on a declared TDX Measurements set. The oracle lives in its own coalition, oracle-γ, which packages the standalone organism for retirement and (optionally) audit via Chronicle. Reads are upstream CEX and on-chain feeds terminated inside the enclave; there is no Compute involvement; the write side is continuous commits to one Stream<PriceTick> per supported token pair, signed by a key derived from MR_TD. Consumers that admit the oracle’s Measurements in their TicketValidator inherit the oracle’s prices by construction.

signer — generic threshold-signature organism walks an organism that produces t-of-n threshold signatures over submitted messages. The committee is itself a market of providers at varying attestation levels — software, TDX-local, TDX-remote-attested, bidirectional RA-TLS, and TDX-plus-reproducible-build — competing on attestation, capacity, and fee per partial signature. Consumers gate admission on the aggregate attestation level the outcome carries; providers below a consumer’s floor are ignored without being expelled. Design inspired by zipnet, inverted from decryption to signing.

Why these four

The four examples cover four distinct roles a mosaik participant can hold:

Consumer of a lattice plus a coordination market (web3) — the searcher reads the block-building lattice, requests Compute from a coalition module, and submits sealed bundles that settle through the lattice.
Provider in a coordination market (web2) — the bridge registers as a provider in the Compute module, competes on rate and TDX posture, and fulfils grants with encrypted receipts.
Publisher of a data surface under an attestation anchor (oracle) — the oracle exposes per-pair streams and reduces its trust story to a single Measurements set.
Committee organism hosting a provider market (signer) — the signer’s committee is itself a market of providers at varying attestation levels, and the organism’s output is a threshold signature consumers gate admission against.

The four are adjacent enough to share the rung structure below but distinct enough to exercise orthogonal parts of the composition.

Parallel chapter structure

Each example runs through seven chapters. Chapter names match rung for rung (sometimes inverted for the publisher side):

Rung	web3	web2	oracle	signer
1	Setup and shape	Setup and shape	Setup and shape	Setup and shape
2	Binding to the Flashbots lattice	Binding to the Compute market	Binding consumers	Binding consumers
3	Reading the market	Reading the market	Reading price sources	Reading the provider market
4	Wrapping non-mosaik feeds	Wrapping backends	Wrapping source feeds	Wrapping attestation surfaces
5	Inference on Compute	Provisioning on demand	Aggregation in the enclave	Partial-signing in the committee
6	Sealed submission and settlement	Sealed receipts and settlement	Stream publication	Aggregate and publish
7	Reputation, retirement, successor chain	Reputation, retirement, successor chain	Rotation, retirement, successor chain	Committee rotation, key refresh, successor chain

Two pairings are worth noting across web3 and web2: rung 5 is the chapter where each side’s resource-acquisition clears (the searcher’s inference loop for web3, the bridge’s provisioning step for web2), and rung 6 is the write side (sealed bundle for web3, encrypted SSH receipt for web2), both shuffle-anonymised. The oracle re-reads those same rungs against a different shape: rung 5 is in-enclave aggregation (no Compute involvement, no scheduling), and rung 6 is continuous signed stream commits rather than occasional sealed submissions. Signer inverts the oracle: rung 5 is partial-signing inside a committee of providers at varying attestation levels, and rung 6 is threshold aggregation plus a public outcome commit consumers admit on the aggregate attestation.

What all four examples assume

Readers know Part I. The four agent shapes, the four emergent-coordination patterns, the TDX/non- TDX split, and the self-replication and self- modification cycle from ai/sustainability.md are load-bearing. Part II does not re-explain them.

Backing crates. The web2 walkthrough is backed by examples/compute-bridge/, a minimum-compile skeleton that cargo tests today. The signer walkthrough is backed by examples/signer/, which exposes Config, SignatureScheme, AttestationLevel, ProviderCard, SignatureRequest, and SignatureOutcome with tests over every identity derivation; no committee state machine. The web3 and oracle walkthroughs are rust,ignore specifications; backing crates are follow-on PRs.

Shared universe. All four examples live on the same mosaik NetworkId (builder::UNIVERSE). searcher-α, bridge-β, oracle-γ, and signer-δ are independent coalitions; no example asserts cross-coalition atomicity.

Anchored in mosaik. Every rust,ignore block in the four examples imports from coalition::*. The coalition crate specifies the data shapes those imports resolve to — CoalitionConfig, OrganismConfig, OrganismRef, the five basic-service configs, retirement primitives — and re-exports mosaik::UniqueId as the canonical identity type across every fingerprint the examples name. The crate depends on mosaik = "0.3"; every consensus-critical value flows through the same identity primitives a mosaik Stream, Group, Collection, or TicketValidator already consumes. Source at crates/coalition/.

Non-goals (shared)

None of the four is a production design guide. Trading-strategy questions for web3, pricing or backend-selection questions for web2, feed-selection or commercial questions for the oracle, and cryptography choices (BLS vs. FROST, DKG implementation, nonce-commit cadences) for signer are out of scope; where the substrate touches those questions, the boundary is named and the chapter stops. None enumerates the full operator policy (Flashbots’ testnet-1a rate limits and ACL cadences, any compute-bridge’s cloud sub-account limits, any oracle operator’s upstream contracts with exchanges, any signer operator’s DCAP-endpoint agreements). None compares the mosaik-native composition to prior art; that ground is the builder book and existing cloud-compute marketplaces for web2/web3, existing oracle networks (Chainlink, Pyth, Chronicle) for the oracle, and the zipnet book, FROST RFCs, and threshold-signature research for signer.

Where to read next

From the top: continue with web3 — Overview, then web2 — Overview, then oracle — Overview, then signer — Overview.
Interested only in the provider side: skip to web2 — Overview.
Interested only in the consumer / agent side: read web3 — Overview.
Interested only in the publisher side with a pure-TDX trust model: read oracle — Overview.
Interested only in threshold signatures with variable attestation levels: read signer — Overview.

ai on mosaik