Threat model

audience: contributors

This chapter states the trust assumptions the coalition layer adds over the builder and zipnet trust models, and describes how per-component trust composes when members (lattices and standalone organisms), composite organisms, and modules are referenced under one CoalitionConfig.

It does not re-derive per-organism trust shapes inside a lattice; those live in builder threat model. It does not re- derive trust shapes for standalone organisms; those live in each organism’s own book. The coalition layer inherits them unchanged. Primitive-level mechanics the trust arguments below lean on — Raft-based majority-honest agreement (mosaik — Raft consensus), peer bonds (mosaik — Bonds & Peer Connections), state-sync for catch-up (mosaik — State Sync & Replay), and deterministic hashing (mosaik — Determinism & Hashing) — are specified upstream and referenced inline where they bite.

Goals and non-goals at the coalition layer

Goals.

• Trust is strictly compositional. A property of a single member is not weakened by that member being referenced in a coalition. Referencing is ambient; it does not open new channels into the member.
• Composite-organism commits are independently auditable against the member commits they fold in. A consumer that trusts the spanned members can verify a composite organism’s commit without trusting the composite organism’s committee, up to the composite organism’s own majority-honest bound.
• Coalition identity is a naming convenience. Code treating a CoalitionConfig fingerprint as authority is misusing it.
• Modules do not gate. Atlas, Almanac, and Chronicle are services a coalition offers; none is on any member’s critical path for admission or operation. A compromised module can mislead consumers but cannot compel a member.

Non-goals.

• Cross-coalition confidentiality. Two coalitions coexisting on the shared universe do not get any additional confidentiality over “two services on the shared universe” already get. Mosaik’s ACL and tickets are the only gates.
• Cross-member atomic integrity. Ruled out at the composition layer. See atomicity.
• Protection against a malicious coalition operator. A coalition operator can publish a CoalitionConfig referencing any member whose stable id they know, including members whose operators have not consented to the reference. The reference has no technical consequence for the member’s integrity or confidentiality; it is a social or legal matter between operators. The blueprint surfaces the observability required to flag the misuse; it does not prevent it.
• Protection against deferred-primitives drift. A future proposal promoting a deferred primitive (enforcement, taxation, judiciary) requires its own threat model. The current model assumes opt-in composition only.

The composite organism’s trust composition

Every composite organism’s trust shape is determined by two inputs:

1. The composite organism’s own committee assumption. Usually majority-honest for integrity, possibly TDX-attested for confidentiality of the cleartext it processes.
2. The worst-case assumption across the spanned members’ public surfaces it reads. If the composite organism reads cleartext from each spanned lattice’s unseal::UnsealedPool and a signed feed from an oracle organism, it inherits the t-of-n threshold of every spanned unseal committee and the signing-quorum assumption of the oracle organism.

The composed assumption is the conjunction: the composite organism’s guarantee holds while every component’s assumption holds simultaneously. Breaking any one component can at most degrade the composite organism’s output per the weakest component’s failure mode.

Crucially, the composite organism’s trust shape does not include any coalition that references it. A malicious coalition operator cannot weaken a composite organism they merely reference; they can only stop referencing it in their next CoalitionConfig.

Example: the intents composite organism

An intents composite organism reads cleartext from three lattices’ UnsealedPools and commits a per-target- lattice routed-intents commit under a TDX-attested, majority-honest committee.

• Confidentiality of cross-chain intents to external observers: holds while every spanned lattice’s zipnet any-trust assumption and unseal t-of-n threshold assumption hold and the composite organism’s TDX image is attested.
• Integrity of the routed commit: holds while the composite organism’s majority-honest committee assumption holds.
• Availability of routing: holds while at least one of the spanned lattices reaches UnsealedPool for the target slot and a composite-organism majority commits.

Example: the shared-ledger composite organism

A ledger composite organism reads each spanned lattice’s tally::Refunds and commits an aggregated SharedRefunds under a majority-honest committee.

• Faithfulness of the aggregated attribution: holds while every spanned lattice’s tally majority-honest assumption and the composite organism’s own majority-honest assumption hold. A malicious lattice tally majority can poison the aggregated commit; the on-chain settlement contract receiving SharedAttestations is the final check.
• Non-duplication of refunds: holds while the aggregation rule is implemented correctly and state- machine-deterministic.

Module trust shapes

Each of the five modules has its own trust shape, summarised here and specified in basic services.

Atlas trust

• Faithfulness of MemberCard contents: holds while the Atlas committee is majority-honest. A compromised Atlas can publish incorrect endpoint hints or stale TDX Measurements pins. Integrators are expected to cross-check with per-member operators’ own handshake pages; Atlas is a convenience, not a certificate.
• Confidentiality: N/A; Atlas is public by design.

Almanac trust

• Monotonicity of ticks: holds while the Almanac committee is majority-honest. A compromised Almanac can skip ticks or delay them, but cannot un-commit previously committed ticks.
• observed_at timestamp vectors are advisory. A compromised committee can publish ticks with implausible timestamps; consumers should treat the per-member vector as a correlation hint, not a cryptographic timestamp. The vector shape does let consumers compositionally detect single-member clock skew (outlier entries in an otherwise-clustered vector); this is an observability aid, not a security guarantee.

Chronicle trust

• Tamper-evidence of past entries: holds while at least one of:

  • (a) the on-chain anchor path is uncompromised — the Chronicle committee periodically commits a blake3 digest of the entry stream to the anchor contract declared in ChronicleConfig.content; or
  • (b) at least one honest ex-member’s signed archive survives — every ChronicleEntry carries per-member signatures in addition to the quorum signature, so an honest ex-member’s archive is a cryptographic witness against forgery.

  Retroactive rewriting requires compromising both paths.

• Completeness of recent entries: majority-honest. A compromised committee can omit entries from being committed; it cannot forge them without being detected, but it can DoS provenance.

Compute trust

• Scheduling integrity. Holds while the Compute committee is majority-honest. A compromised committee can grant a request to a provider who never runs the image, grant to a wrong provider, or omit grants altogether. It cannot forge a provider’s usage attestation (those are provider-signed) nor steal a requester’s settlement evidence (settlements live off-protocol).
• Image-hash honesty. A grant commits a specific image post-hash; a TDX-gated grant additionally commits the expected TDX Measurements. The requester verifies the provider is actually running the committed image at workload startup; a provider running a different image fails attestation and the workload aborts.
• Non-collusion between scheduler and provider. Out of scope. The Compute module commits the match; if the scheduler and a malicious provider collude, the requester’s only recourse is observing that the workload’s outputs never appear and routing to a different provider next time. A reputation organism scoring provider delivery closes the loop.

Randomness trust

• Scheduling and commit integrity. Holds while the Randomness committee is majority-honest. A compromised committee can skip rounds, delay commits past their target tick, or grant a round to a provider whose card it should have rejected. It cannot forge a beacon value that verifies against an honest provider’s declared public key.
• Unbiasability inheritance. The beacon’s unbiasability is inherited from the provider’s declared scheme. A coalition admitting a weak scheme (a plain VRF alone) is offering randomness that a malicious provider can bias by withholding unfavourable draws. A coalition admitting only threshold-BLS (t-of-n ≥ 3-of-5) or TDX-attested schemes inherits those schemes’ unbiasability arguments.
• Challenge path. Suspected bias goes on Chronicle (a signed entry naming the round and the challenger’s evidence); consumers unpin the provider in their own validator. The module has no built-in challenge stream.
• Non-collusion between scheduler and provider. Out of scope, same as Compute. If the scheduler and a malicious beacon provider collude, the bias is detectable only by consumers’ own cross- verification. A reputation organism scoring provider honesty closes the loop.

Ticket issuance trust

• Issuance correctness: trust shape inherited from mosaik’s TicketValidator composition. This blueprint introduces no new primitives. A component that recognises the coalition-scoped issuance root trusts the issuer’s ACL composition; a component that does not recognise it is unaffected.

Coalition operator responsibilities

Coalition operators carry a narrow set of responsibilities.

Must do:

• Publish the CoalitionConfig struct (and the derived fingerprint) as the handshake.
• Publish every module’s and every coalition-run composite organism’s TDX Measurements if TDX-gated.
• Publish every coalition-commissioned standalone organism’s TDX Measurements that is TDX-gated. If the organism is operated by a different team, that team publishes its own TDX Measurements and the coalition operator re-publishes for convenience.
• Document the set of members and composite organisms referenced, including a pointer to each per-member operator’s and per-composite-organism operator’s handshake page.
• State explicitly which modules the coalition ships and which it does not. Silence is ambiguous.
• Notify integrators when a referenced member’s stable id bumps and publish the updated CoalitionConfig promptly.

What a compromised coalition cannot do

Regardless of how many modules a coalition operator runs maliciously:

• Cannot change a referenced member’s or referenced composite organism’s commits. Each component’s commit log is authoritative in its own Groups. A compromised module cannot forge a commit belonging to another component.
• Cannot mint money. Same argument as builder: on- chain settlement contracts enforce the evidence carried in attestations.
• Cannot produce cross-member atomic outcomes. Atomicity is not a primitive; a compromised module cannot force two members to jointly commit something they did not independently commit.
• Cannot compel members. A compromised Atlas cannot force dashboards to trust it; a compromised Chronicle cannot rewrite what honest replayers and external anchors have already recorded.

What a compromised coalition can do

Conservatively:

• Poison module commits. A majority-compromised module can publish incorrect records. Integrators reading those commits observe the misbehaviour in public and can object, migrate, or appeal to on-chain settlement.
• Mislead Atlas consumers. A compromised Atlas can publish wrong endpoint hints, stale TDX Measurements pins, or fabricate membership. Dashboards relying on Atlas see degraded accuracy; the members themselves are unaffected.
• DoS the module tier. A committee that loses majority stops producing new commits. Referenced members and their own pipelines are unaffected.
• Publish a misleading CoalitionConfig. A coalition operator can publish a CoalitionConfig that references members or composite organisms the integrator did not expect. Integrators guard against this by compiling in the CoalitionConfig explicitly and auditing its contents — a misleading fingerprint is a visible artefact.
• Stop publishing Chronicle entries. The absence of an entry is observable; a coalition that goes silent loses trust even if it cannot rewrite the past.

Compositional table

The decomposition is the point. A coalition that misbehaves at one tier degrades the guarantee dependent on that tier; it does not collapse everything.

Operator responsibilities recap

Every operator running a committee member in any composite organism, module, or standalone organism is responsible for the same set of obligations a lattice-organism operator is (running the attested image, protecting committee-admission secrets, rotating on schedule, reporting anomalies).

Cross-member composite-organism operators add one responsibility:

• Cross-member dependency reporting. When a referenced member’s stable id or content hash bumps, the composite-organism operator files an advisory to any coalition operators referencing the composite organism and to integrators so updates propagate with a known cadence, not silently. If any referencing coalition ships a Chronicle, that advisory lands in the next Chronicle entry.

Cross-references

• builder threat model — per-lattice trust shapes this layer composes over.
• composite organisms — the organism the compositional trust statements above are about.
• basic services — trust shapes for Atlas, Almanac, Chronicle.
• ticket issuance — the optional issuance root.
• composition — the subscription graph these trust statements travel along.
• atomicity — the one thing that does not compose.