POST FIAT
Consensus decision brief · 21 Aug 2026
01/18

Post Fiat protocol decision

COBALT

Consensus machinery, governance replay,
and the production decision.

Implemented researchLive authorityCorrect governance

Plain EnglishThe decision here is narrower than “do we like Cobalt?” We need to decide where—if anywhere—it should become authoritative.

Scroll or use arrow keys

01 · Definition

What is Cobalt?

A family of Byzantine agreement protocols for networks where participants do not share one global membership list—and may hold different trust assumptions.

ApplicationGovernance decision or ordered ledger value
Cobalt compositionReliable broadcast · binary agreement · multi-value agreement
Local trustEssential subsets with quorum and fault thresholds
Not a validator scorerNot a trust oracleNot proof that a proposal is wise

Plain EnglishThink of Cobalt as machinery that gets people with different trust lists to agree on the same answer. It does not decide who deserves trust.

01 · Why Ripple proposed it

XRPL's safety depends on who overlaps whom.

Problem

Each server configures a Unique Node List. Insufficient overlap can permit divergent validations.

2018 proposal

Make heterogeneous trust a first-class protocol input instead of assuming nearly identical lists.

Goal

More flexible UNLs, less reliance on coordinated list uniformity, and agreement under arbitrary asynchrony.

Plain EnglishXRPL's original weakness is configuration safety: if two servers trust groups that do not overlap enough, consensus can split.

01 · What XRPL actually shipped

Cobalt did not ship. Operational mitigations did.

Documented record

Signed validator lists

Publishers distribute recommended validators; modern rippled can require a validator to appear on multiple configured lists.

Negative UNL

Consensus temporarily deactivates persistently offline validators and adjusts quorum within tight bounds. This improves liveness, not trust-list decentralization.

What is not documented

No official postmortem

Ripple did not publish a canonical explanation for abandoning Cobalt. Claims about a single definitive reason should be treated as inference.

Engineering inference

XRPL retained a proven consensus path and incrementally addressed availability and list distribution, avoiding the migration, complexity, and new cryptographic machinery of a consensus replacement.

Negative UNL is not “Cobalt lite.” It temporarily discounts unavailable members of the existing trust configuration.

Plain EnglishThe honest answer is that Ripple never published a postmortem. What shipped was a conservative patch set around the existing consensus, not Cobalt.

02 · Post Fiat today

The codebase has two different authority stories.

LIVE AUTHORIZATION

Old-rule signature quorum

  • Distinct ML-DSA-65 authorizations
  • Active registry validates the complete action
  • Delayed activation, replay protection, rollback
Production truth
CONTROLLED COBALT MACHINERY

Agreement + transition research

  • Trust graphs and essential subsets
  • RBC / ABBA / MVBA / DABC
  • Safety witnesses and transition checks
Implemented, not authoritative

The whitepaper and governance docs explicitly say the Cobalt research types do not replace or bypass the live signature boundary.

Plain EnglishToday, signatures authorize governance changes. The Cobalt crate can simulate and verify stronger behavior, but it is not in charge.

02 · Machinery in consensus_cobalt

This is not a stub. It is a substantial protocol lab.

01RBCsame proposal
02ABBAsame bit
03MVBAsame valid value
04DABCordered decision
05Registrytyped activation

Core types

Trust views, essential subsets, proposals, votes, certificates, round state, ratifications, replay records.

Lifecycle

Trust-graph updates, registry transitions, delayed activation, challenge state, rollback and stale-root rejection.

Bindings

Domain-separated links among registry, trust graph, transaction network membership, and block context.

Adversarial harness

Partitions, equivocation, poisoning, stale replay, crash/restart, membership races, parser fuzz and resource DoS.

Plain EnglishThere is real code here. The unanswered engineering question is whether all of this machinery belongs on the production critical path.

02 · What its safety checker proves

Local safety is not enough. Transitions need cross-era overlap.

PER ESSENTIAL SUBSETtS < 2qS − nS2tS < qS
+
OLD ↔ NEW REGISTRY|Qold ∩ Qnew| > B

Every old/new quorum pair must share more than the active Byzantine budget.

Old: A B C D E F GNew: A B H I J K LOnly A · B overlapBoth rows may pass locally while the transition is unsafe.

The bounded cover extractor rejects omitted or stale rows, conflicting views, unsafe deltas, and covers above 64 entries. That is strong controlled evidence—not a public-network readiness claim.

Plain EnglishA new registry can be safe by itself and still be unsafe to enter from the old registry. The transition is the dangerous part.

03 · AgentHub / original Dynamic UNL program

Phase 1 and 2 are complete. Authority transfer is not.

PHASE 1

Foundation pipeline

13 / 13

Evidence collection, pinned inference, deterministic selector, signed list publication, IPFS and ledger anchoring.

COMPLETE
PHASE 2

Validator shadow replay

11 / 11

Frozen inputs, commit/reveal, independent sidecars, on-chain participation and withholding hardening.

COMPLETE
PHASE 3A

Content authority

0 / 3

Converged validator results become the list content while the foundation still signs and publishes.

NOT STARTED
PHASE 3B

Publication authority

0 / 3

Ledger-held registry; old rules ratify new; remove the single signing key and canonical URL.

DESIGN-GATED

Byte-identical replay proves reproducible execution. It does not prove the scoring policy is correct, robust, or superior to deterministic rules.

Plain EnglishWe have proven that validators can reproduce the foundation's answer. We have not handed them the power to make that answer canonical.

04 · Where the programs meet

Replay produces the packet. Cobalt can authorize the packet.

OBSERVEEvidence snapshot
REPLAYModel + manifest
COMPILEDeterministic policy
BINDExact packet root
RATIFYCobalt / quorum cert
ACTIVATETyped registry update

Clean interface

Cobalt never interprets prose or reruns the model. It agrees on one hash-bound, schema-valid transition packet after deterministic conformance checks.

Critical separation

The replay layer answers “what was proposed?” The agreement layer answers “did the current authority approve this exact proposal?” Neither answers “is it wise?”

Plain EnglishThe clean integration is hash-to-hash: AgentHub constructs an exact proposal, and the consensus layer either certifies that exact proposal or rejects it.

05 · Concrete benefit I

Cobalt makes heterogeneous trust checkable.

01

Non-uniform trust is explicit

Validators can declare different essential subsets instead of relying on near-identical publisher lists.

02

Safety assumptions become machine inputs

Thresholds, fault budgets, linkedness, covers, and intersection witnesses are validated before activation.

03

Unsafe membership deltas fail closed

A transition can be rejected even when both the old and new configurations look safe in isolation.

04

Asynchronous agreement target

The paper targets safety without timing assumptions and probabilistic progress under its fault and trust assumptions.

Plain EnglishThe actual safety gain is that trust assumptions stop living in operator folklore and become inputs the protocol can check.

05 · Concrete benefit II

Cobalt can remove a publisher-shaped root of trust.

XRPL-STYLE LIST GOVERNANCE
SIGNED LIST PUBLISHER
V1V2V3V4

Servers still choose configuration, but publisher compromise or social coordination can influence the recommended topology.

RATIFIED TRANSITION GOVERNANCE
V1V2V3V4
PACKET ROOT + CERTIFICATE

Old rules collectively authorize the exact new registry after transition-safety checks.

The gain is constitutional: validator membership becomes ledger-verifiable protocol state rather than a signed web artifact.

Plain EnglishThis is the decentralization win: no single website or signing key gets to quietly redefine the validator set.

06 · Cobalt attack surface

Formal agreement does not make the trust graph true.

GRAPH POISONING

Adversaries manipulate declared trust edges or evidence used to construct them.

CORRELATED OPERATORS

Five validators may be one cloud, owner, key ceremony, or legal coercion domain.

SYBIL INFILTRATION

Admission mistakes let one actor occupy multiple essential subsets.

OLD-SET ENTRENCHMENT

“Old rules approve new” can let incumbents block legitimate rotation indefinitely.

CHECKER BUG

A defect in cover extraction or transition arithmetic becomes a constitutional vulnerability.

KEY COMPROMISE

Agreement among compromised identities is still valid agreement.

Cobalt can prove agreement under encoded assumptions. It cannot prove operator independence, honest evidence, competent policy, or resistance to off-chain capture.

Plain EnglishCobalt cannot tell us that five validators are secretly the same operator. Bad real-world trust data still produces a bad trust graph.

06 · Operational attack surface

The default failure mode may be safer—but it is still a halt.

Availabilitymessage amplification

RBC + repeated binary agreement creates more messages, state, and verification work than a simple threshold certificate.

Randomnesscoin withholding or bias

A production common coin or signed beacon adds availability, implementation, and key-management dependencies.

Governancechallenge / cover griefing

Attackers can force oversized covers, repeated challenges, or transition deadlock. Fail-closed preserves safety while freezing change.

Migrationmixed-version ambiguity

Partial rollout, replay bugs, or state divergence at the authority boundary can strand the network between constitutions.

FORK RISKHALT / COMPLEXITY RISK

Plain EnglishWe may turn a simple governance action into a much heavier distributed protocol. A safe halt is still an outage.

07 · Comparable deployments

No credible production chain was found running MacBrough Cobalt.

SystemProduction?RelationshipCritical difference
Cobalt paperNo identified chainExact protocol family

DABC for non-uniform trust

Post FiatControlled onlyCobalt machinery

Live authority remains signature quorum

Stellar SCPYesFederated Byzantine agreement

Quorum slices; not Cobalt's RBC/ABBA/MVBA/DABC stack

MobileCoinYesSCP-derived FBA

Related non-uniform trust lineage, not Cobalt

XRPLYesUNL-based consensus

Cobalt proposed, never adopted

A release named “Cobalt” is not evidence of the Cobalt consensus protocol. Exact implementation claims require protocol-level confirmation.

Plain EnglishWe would be early. Related protocols exist in production, but that is not the same as having a battle-tested Cobalt deployment to copy.

08 · Alternative

Can Post Fiat simply copy XRPL consensus?

YESas a conservative operational model/NOas a shortcut to inherited safety

Valid if we admit the trust model

Signed multi-publisher lists, conservative overlap, Negative-UNL-style availability handling, and social governance are coherent for a permissioned or curated network.

Invalid as cargo cult

Safety depends on Post Fiat's actual topology, thresholds, churn, key model, and implementation. Rust certified ordering is not rippled; copying parameters does not copy the proof.

This path is simpler and lower-risk, but it requires revising any whitepaper claim that membership evolution is protocol-ratified rather than publisher- or committee-governed.

Plain EnglishWe can keep an XRPL-style model, but then we should say plainly that membership remains curated rather than protocol-governed.

09 · Governance replay interface

The model should be a proposer—not a voter.

REPLAYABLE MACHINEEvidence → model → proposed policy

Produces citations, scores, rationale, manifest and exact hashes.

DETERMINISTIC GUARDSchema → compile → simulate → compare

Rejects invalid, unsafe, non-actionable, or non-reproducible packets.

AUTHORITY CHOICE
With Cobalt

Old trust graph ratifies and safely transitions registry state.

Without Cobalt

Current ML-DSA quorum ratifies; publisher or ledger action distributes the result.

Replay makes a governance decision inspectable. Ratification makes it authorized. Deterministic rules make it executable. These are three separate properties.

Plain EnglishThe model proposes. Deterministic code checks. Validators authorize. Combining those jobs is how an AI mistake becomes a consensus mistake.

10 · Decision matrix

Full Cobalt is not the only way to decentralize authority.

OptionSafety clarityComplexityPublisher removalTime to credible testnet
A · Current pathKnown signature quorumLowNoFastest
B · XRPL-styleTopology-dependentLow–mediumPartial, multi-publisherFast
D · Full CobaltStrongest encoded heterogeneous-trust targetVery highYesSlowest

Key test: if a simple quorum certificate plus the existing cross-registry safety witness satisfies the constitutional requirement, full RBC/ABBA/MVBA/DABC adds risk without enough marginal benefit.

Plain EnglishThe default engineering choice should be the smallest mechanism that removes the publisher trust root and passes the same safety checks.

Recommendation

Do not replace transaction consensus.
Earn Cobalt at the governance boundary.

NOW

Ship the minimal authority bridge

Phase 3A content convergence → typed packet root → current ML-DSA old-rule quorum certificate → deterministic transition-safety check.

COMPARE

Run two ratifiers in shadow

Replay identical governance packets through the minimal QC path and the full Cobalt path. Measure divergence, latency, traffic, restart behavior and operator burden.

GATE

Activate only after hostile proof

Formal spec/model check, deterministic simulation, multi-node partitions, mixed-version migration, common-coin review, external audit and rollback rehearsal.

PRODUCTION POSITIONCobalt is a candidate governance ratifier—not yet the chain's consensus authority.

Plain EnglishOur recommendation is not “no Cobalt.” It is “prove Cobalt adds enough value before we put it in the chain's constitutional path.”

EVIDENCE INDEX

Sources for this decision brief

Cobalt and XRPL

  1. Ethan MacBrough, “Cobalt: BFT Governance in Open Networks” (2018)
  2. Ripple, “Continued Decentralization & the XRP Ledger Consensus Protocol” (2018)
  3. XRPL documentation: Unique Node Lists
  4. XRPL documentation: Negative UNL
  5. XRPL: rippled 1.6.0 and Negative UNL
  6. XRPLF: multi-publisher validator-list threshold

Post Fiat implementation

  1. Post Fiat L1 whitepaper: certified ordering, Cobalt and replay boundaries
  2. Cobalt governance boundary
  3. Cobalt implementation map
  4. Rust consensus_cobalt crate

AgentHub governance program

  1. AgentHub blockchain status, 19 Aug 2026
  2. Dynamic UNL current roadmap
  3. Phase 3 research charter
  4. Machine governance evolution specification

Related deployed protocols

  1. Stellar Consensus Protocol documentation
  2. stellar-core implementation
  3. MobileCoin source and consensus lineage

Research cutoff: 21 August 2026. “Why Cobalt did not ship” is explicitly presented as inference because no official XRPL postmortem was found. Post Fiat implementation claims reflect the audited local branches named above.