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 citizens (lattices and standalone organisms), confluences, 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.

Goals and non-goals at the coalition layer

Goals.

• Trust is strictly compositional. A property of a single citizen is not weakened by that citizen being referenced in a coalition. Referencing is ambient; it does not open new channels into the citizen.
• Confluence commits are independently auditable against the citizen commits they fold in. A consumer that trusts the spanned citizens can verify a confluence’s commit without trusting the confluence’s committee, up to the confluence’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 citizen’s critical path for admission or operation. A compromised module can mislead consumers but cannot compel a citizen.

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-citizen 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 citizen whose stable id they know, including citizens whose operators have not consented to the reference. The reference has no technical consequence for the citizen’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 heavy-coalition drift. A future proposal promoting a heavy-coalition primitive (enforcement, taxation, judiciary) requires its own threat model. The current model assumes light-coalition only.

The confluence’s trust composition

Every confluence’s trust shape is determined by two inputs:

1. The confluence’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 citizens’ public surfaces it reads. If the confluence 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 confluence’s guarantee holds while every component’s assumption holds simultaneously. Breaking any one component can at most degrade the confluence’s output per the weakest component’s failure mode.

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

Example: the intents confluence

An intents confluence 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 confluence’s TDX image is attested.
• Integrity of the routed commit: holds while the confluence’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 confluence majority commits.

Example: the shared-ledger confluence

A ledger confluence 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 confluence’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 four modules has its own trust shape, summarised here and specified in basic services.

Atlas trust

• Faithfulness of CitizenCard contents: holds while the Atlas committee is majority-honest. A compromised Atlas can publish incorrect endpoint hints or stale MR_TD pins. Integrators are expected to cross-check with per-citizen 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 MR_TD. 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.

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 confluence’s MR_TD if TDX-gated.
• Publish every coalition-commissioned standalone organism’s MR_TD that is TDX-gated. If the organism is operated by a different team, that team publishes its own MR_TD and the coalition operator re-publishes for convenience.
• Document the set of citizens and confluences referenced, including a pointer to each per-citizen operator’s and per-confluence operator’s handshake page.
• State explicitly which modules the coalition ships and which it does not. Silence is ambiguous.
• Notify integrators when a referenced citizen’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 citizen’s or referenced confluence’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-citizen atomic outcomes. Atomicity is not a primitive; a compromised module cannot force two citizens to jointly commit something they did not independently commit.
• Cannot compel citizens. 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 MR_TD pins, or fabricate membership. Dashboards relying on Atlas see degraded accuracy; the citizens themselves are unaffected.
• DoS the module tier. A committee that loses majority stops producing new commits. Referenced citizens and their own pipelines are unaffected.
• Publish a misleading CoalitionConfig. A coalition operator can publish a CoalitionConfig that references citizens or confluences 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 confluence, 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-citizen confluence-operator adds one responsibility:

• Cross-citizen dependency reporting. When a referenced citizen’s stable id or content hash bumps, the confluence operator files an advisory to any coalition operators referencing the confluence 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.
• confluences — 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.