The six organisms

audience: contributors

This page is the index: six short specs, one per organism, each giving enough shape for a crate author to start writing code and a reviewer to challenge the surface. Each spec ends with a link to the organism’s own detailed page, where the state machine, wire types, and invariants are laid out in full.

Per-organism deep dives:

• zipnet — anonymous submission
• unseal — threshold decryption
• offer — sealed-bid auction
• atelier — TDX co-building
• relay — PBS fanout
• tally — refund accounting

Every organism follows the same template:

• Role. One sentence on what it does in the lattice.
• Public surface. The one or two public primitives it exposes.
• ACL. The TicketValidator composition that gates bonds.
• State machine hook. The decision the Raft log actually commits.
• Trust assumption. What the adversary must achieve to break the organism’s guarantee.
• Reads from / Writes to. The organisms immediately upstream and downstream in the lattice.

Reading order matches the data flow: submission → unsealing → auction → building → relay → tally.

zipnet (submission)

Role. Anonymous, authenticated broadcast of sealed transactions and intents. The existing organism — this proposal consumes it unchanged.

Public surface.

• Submit<Tx> — ticket-gated write stream. External wallets and searchers send sealed envelopes here.
• Broadcasts — append-only collection of finalized round broadcast vectors.
• LiveRoundCell — current round header so submitters know what to seal for.
• ClientRegistry, ServerRegistry — public X25519 bundles.

See zipnet book — architecture for the full surface. Lattice-specific wrapping: zipnet spec.

ACL. TDX attestation on the committee (in the v2 TDX path); ticket-gated client admission via ClientBundle.

State machine hook. CommitteeMachine::apply(SubmitAggregate) and apply(SubmitPartial) finalize a round’s broadcast vector per the ZIPNet paper’s Algorithm 3. See the zipnet book’s committee-state-machine page.

Trust assumption. Any-trust on anonymity (one honest committee server suffices). Majority-honest on liveness (v1; v2 relaxes).

Reads from. Integrators (external wallets/searchers). Writes to. unseal (subscribes to Broadcasts).

unseal (threshold decryption)

Role. Recover cleartext of a zipnet round’s broadcast vector by collecting t of n threshold-decryption shares from the unseal committee, without any single committee member learning the cleartext.

Public surface.

• UnsealedPool — append-only collection of UnsealedRound { slot, cleartext } entries, keyed by slot. The cleartext is the decrypted broadcast vector for that slot; every downstream organism reads from this collection.
• ShareRegistry — public PKs for every unseal committee member. Integrators that need to verify a share’s authenticity read this.

An internal share-gossip stream runs on a derived private network keyed off UNSEAL_ROOT.derive("private").

ACL. TDX attestation required on every committee member (.require_ticket(Tdx::new().require_mrtd(unseal_mrtd))). The share registry is writable only by committee members; the UnsealedPool is readable by any peer that holds a ticket from the lattice operator.

State machine hook. UnsealMachine::apply(SubmitShare) tracks shares per slot; when t shares arrive, the state machine combines them in apply, pushes the resulting cleartext to UnsealedPool, and discards the shares. No share is ever materialised outside the committee’s in-memory set during combination.

Trust assumption. t-of-n threshold: fewer than t colluding committee members learn nothing; t or more colluding members can decrypt at will. Picking t is a per-lattice parameter that folds into the organism’s Config fingerprint.

Reads from. zipnet::Broadcasts. Writes to. Consumed by offer, atelier, and any integrator authorised to see unsealed order flow.

Full spec. unseal.

Why not fold into zipnet

Zipnet’s committee is any-trust; unseal’s is t-of-n threshold. Different trust shapes, different admission policies, different rotation cadences. Keeping them as one organism would have forced the strictest trust model on both.

offer (sealed-bid bundle auction)

Role. Run a sealed-bid auction, per slot, over bundles that searchers submit against the unsealed order-flow pool.

Public surface.

• Bid<Bundle> — ticket-gated write stream. Searchers publish sealed bids keyed to a specific slot S. Sealing uses the same unseal-style threshold encryption so that competing searchers do not learn each other’s bids until the auction commits.
• AuctionOutcome — append-only collection of { slot, winner, bundle } committed once per slot. Integrators and downstream organisms read from this.
• SearcherRegistry — public searcher bundles with their auction- encryption public keys.

ACL. Ticket-gated on the Bid<Bundle> stream: only attested searchers admitted. AuctionOutcome is world-readable by lattice ticket holders.

State machine hook. OfferMachine::apply(OpenAuction), apply(SubmitBid), apply(CloseAuction) — the committee commits a round-opening at slot boundary, accumulates sealed bids during the round window, and commits the winner at close time. The bid decryption is a threshold combine inside apply, same pattern as unseal.

Trust assumption. Majority-honest committee. A malicious majority can pick a non-max-bid winner; anonymity of losing bids holds under threshold assumption.

Reads from. unseal::UnsealedPool (so the auction winner binds to a specific unsealed slot). Writes to. atelier (subscribes to AuctionOutcome).

Full spec. offer.

Why not fold into atelier

offer runs a cryptographic sealed-bid auction; atelier runs a TDX-attested block-assembly protocol. Those are different kinds of computation with different operational cadences. A single Group would force searchers who only care about bidding to bond into a TDX-gated committee they don’t need to trust.

atelier (TDX co-building)

Role. Assemble a candidate block per slot, inside a TDX- attested committee of co-builders, from the unseal cleartext pool and the offer winning bundle. Commit the candidate block body as the lattice’s proposal for that slot.

Public surface.

• Candidates — append-only collection of { slot, block_body, builder_attestation } committed once per slot. The attestation is a collective signature from the TDX committee covering the block body. Integrators (proposers, sequencers, analytics) read from this.
• Hint<Template> — ticket-gated write stream for co-builder operators to submit partial block templates during the assembly window. Internal to the atelier committee in effect (the ticket is atelier.member) but lives on UNIVERSE.

Internal plumbing — per-slot bundle simulation gossip, fee-sorting traffic — runs on a derived private network keyed off ATELIER_ROOT.derive("private").

ACL. TDX attestation required on every committee member (.require_ticket(Tdx::new().require_mrtd(atelier_mrtd))). The co-builder-contributed Hint<Template> stream is ticket-gated on atelier.member.

State machine hook. AtelierMachine::apply(OpenSlot), apply(SubmitHint), apply(SealCandidate) — per-slot state transitions that accumulate hints, pick the final ordering from unseal + offer + hint input, and seal the block body. The TDX quote on each committee member’s PeerEntry is what makes the resulting commit attestable off-lattice.

Trust assumption. TDX attestation (hardware root of trust) plus majority-honest committee. A minority of compromised TDX images is insufficient to break block-body integrity; a majority can commit an arbitrary block.

Reads from. unseal::UnsealedPool, offer::AuctionOutcome. Writes to. relay (subscribes to Candidates).

Full spec. atelier.

Why this is a restatement of BuilderNet

The atelier organism is a mosaik-native restatement of the BuilderNet co-building pattern: TDX-attested builders contributing to one candidate block per slot, refund accounting tracked in a peer collection. Differences:

• Identity — BuilderNet’s node identity is a BuilderHub registration; atelier’s is a content + intent addressed GroupId derived from the lattice fingerprint.
• Composition — atelier does not own order-flow ingestion or refund accounting; those are zipnet + unseal + tally.
• Substrate — BuilderNet uses bespoke peer-to-peer wiring; atelier uses mosaik Groups and Collections.

An operator familiar with BuilderNet can map BuilderNet’s roles onto the lattice by reading atelier as the building node and tally as the refund role.

relay (PBS fanout)

Role. Ship candidate block headers + bids from atelier to the proposer (on L1) or sequencer (on L2) and commit the proposer acknowledgement.

Public surface.

• AcceptedHeaders — append-only collection of { slot, header, bid, proposer_ack } committed once per slot when the proposer acknowledges a header. Integrators read from this to follow proposer-side acceptance.
• Ship<Header> — ticket-gated write stream on which relay committee members publish the header they’ve sent to their assigned proposer. Internal to the committee.

ACL. Ticket-gated on relay.member for the write stream. AcceptedHeaders is world-readable by lattice ticket holders.

State machine hook. RelayMachine::apply(RecordSend), apply(RecordAck), apply(RecordTimeout) — per-slot tracking of which relay member sent what header to whom, and whether the proposer acknowledged.

Trust assumption. A single honest committee member suffices for liveness on L1 (any-trust on liveness). Integrity of AcceptedHeaders is majority-honest: a malicious majority can commit a lie about a proposer ack.

Reads from. atelier::Candidates. Writes to. tally (subscribes to AcceptedHeaders).

Full spec. relay.

Why relay is not folded into atelier

Relay liveness is proposer-side connectivity, which is a different failure domain from TDX-builder compute. Folding them would force the TDX image to hold proposer socket state, which expands the TCB unnecessarily. The commit that actually matters for downstream refund accounting is “a proposer accepted this header”, which is a different fact from “the TDX committee signed this block”. Both facts want their own log.

tally (refund accounting)

Role. Attribute MEV captured on a winning block back to the order-flow providers and searchers whose input contributed to it; commit the attribution as a public-verifiable record; stream refund attestations integrators can prove against on-chain settlement layers.

Public surface.

• Refunds — append-only collection of { slot, recipients[], amounts[], evidence } committed once per slot after the on-chain inclusion of the winning block is observed. Evidence is the set of references back to zipnet, unseal, offer, atelier, relay commits that justify the attribution.
• Attestations — ECDSA-signed attestations from tally committee members over each Refunds entry. Integrators that want to claim a refund on-chain present an Attestation to the chain’s settlement contract.

ACL. Tally committee is ticket-gated. Refunds is world-readable by lattice ticket holders; Attestations is world-readable unconditionally (they are meant to be carried to on-chain settlement).

State machine hook. TallyMachine::apply(ObserveInclusion), apply(ComputeAttribution), apply(CommitRefund) — per-slot state transitions triggered by the on-chain inclusion of an atelier block. Attribution is a deterministic function of the commits across the other five organisms.

Trust assumption. Majority-honest tally committee. A malicious majority can mis-attribute; the on-chain settlement contract is the ultimate arbiter and can reject malformed attestations.

Reads from. relay::AcceptedHeaders, an on-chain inclusion watcher, atelier::Candidates, offer::AuctionOutcome, zipnet::Broadcasts. Writes to. Integrators (searchers, wallets) and on-chain settlement contracts.

Full spec. tally.

Why tally is the last organism

The refund / attribution commit is deliberately the last non-reversible step in the pipeline. By the time tally commits, every upstream organism has committed its piece, the winning block is on-chain, and the attribution is a pure function of public state. If earlier organisms had written tally’s data, any failure upstream would have to be rolled back in tally — re-introducing cross-organism atomicity we explicitly rejected.

Summary table

See composition.md for the flow diagrams and the apply order; threat-model.md for how the per-organism trust assumptions compose.