Multi-operator coalitions

audience: operators

A multi-operator coalition is one whose referenced lattices, standalone organisms, or composite organisms are operated by different teams. The blueprint does not make multi-operator composition special: a CoalitionConfig references member stable ids regardless of who runs them. Coordination patterns succeed or fail based on a few out-of-band agreements, catalogued below.

A multi-operator coalition provides a shared handshake and a coordination channel; nothing more.

The blueprint minimum

The coalition operator needs the stable id of each referenced member. Any operator holding those ids can publish a CoalitionConfig including those members; there is no technical gate on referencing, and the CoalitionConfig does not require the per-member operator’s signature.

This is intentional. A stable-id reference is not a claim of authority over the member. A per-member operator objecting to a coalition reference has no technical recourse, and the reference also has no technical consequence: every organism committee member still needs tickets from each per-member operator to bond into those members’ public surfaces. The distinction — a coalition as a shared handshake without authority over its members — is the point Buterin draws on a different surface in DAOs are not corporations (2022): decentralisation is worth paying for where it buys censorship-resistance and unpredictability- resistance, not where it imitates corporate hierarchy. A coalition in this blueprint is a coordination layer in the first sense, not an instrument of control in the second.

What a multi-operator coalition agreement should cover

Documented even when trust between operators is high.

Notification cadence

Member retirements (stable-id bumps). The per- member operator notifies the coalition operator at least one business day ahead of a retirement.
Content-hash bumps that matter to organisms pinning content (TDX Measurements rotations on TDX-gated surfaces). Coordinate with any organism operator whose pinning policy is affected.
Ticket rotations. When a per-member operator rotates their ticket-issuance root, organism committee members need new tickets before cutover.
Retention changes. A member shortening retention of a public surface a composite organism subscribes to breaks organism replay. Notify the coalition operator and the organism operator.

Ticket issuance for organism committee members

The organism committee reads each spanned member’s public surfaces and so requires per-member tickets. Agreements should cover:

Who issues. Each per-member operator issues tickets for organism committee members, exactly as for any integrator.
Under what policy. Organisms usually need read- only tickets on specific surfaces (for a lattice: UnsealedPool, tally::Refunds; for an oracle organism: its feed stream). Scope accordingly.
Rotation schedule. Tickets expire. A rotation cadence matching the per-member operator’s standard schedule is acceptable; unannounced rotations are not.

Optional coalition-scoped ticket issuer

A multi-operator coalition may ship a coalition-scoped ticket issuer (see ticket issuance). Components — organisms, modules, even external integrators — decide per-component whether to recognise its tickets. No component is required to. A multi-operator coalition agreement can document which components plan to recognise the coalition issuer, but recognition itself is always in each component’s own TicketValidator composition.

Organism governance

When multiple members contribute inputs to one organism, the organism is itself a governance concern. Agreements cover:

Who runs the committee? Often the coalition operator; sometimes a subset of the per-member operators; occasionally a separate team. Organism identity is coalition-independent: the same committee serves every coalition that references it.
Who decides on Config bumps? The organism operator, informed by the affected per-member operators and by referencing coalitions.
Conflict resolution. The escalation path when the organism commits a record one per-member operator disputes (an attribution split, a cross-feed correlation).

None of this is in-protocol; all of it is contract. The coalition does not arbitrate.

Publishing a multi-operator coalition

The handshake page makes multi-operator coalition visible:

Per-member links. Each LatticeConfig or OrganismRef reference includes a link to the corresponding per-member operator’s handshake page. Composite-organism references additionally link to the organism operator’s handshake.
Operator roll call. A table listing each operator and the roles it holds (lattice, standalone organism, composite organism, module, ticket issuer, coalition).
Multi-operator coalition change channel. Typically a shared channel across all participating operators rather than the coalition operator’s individual channel, so that member-side changes are visible to every participant in-flight.

What multi-operator coalition does not change

Mosaik-level security. Each member’s ACL is unchanged. Each organism’s ACL is unchanged.
Atomicity. No cross-member atomic commit. Multi-operator coalition does not provide it; no contract can.
Integrator ergonomics. Integrators still compile one CoalitionConfig; a multi-operator coalition is indistinguishable from a single-operator coalition at the handle API.

A healthy multi-operator-coalition checklist

Each referenced per-member operator has been notified.
Each referenced organism operator has been notified.
Ticket issuance for organism committee members is documented per member.
The change channel covers member retirements, content-hash bumps, ticket rotations, and organism config changes.
The handshake page lists every operator and their role.
The coalition’s modules and any referenced organisms have a documented stall / degradation policy consistent with each spanned member’s expected availability.

ai on mosaik