Cosmos: A Network of Distributed Ledgers

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

1. Claim 01 · Paper model

   A hub is not a master

   The paper describes zones, each with its own validators, and a hub that moves packets between them. The hub does not re-execute the zone. Sovereignty is the point.

2. Claim 02 · Paper model

   Tendermint is the default engine, not the definition

   Zones need fast finality so a packet has a committed source. The paper picks a Byzantine engine for that reason. Another engine with real finality could fit the shape.

3. Claim 03 · Paper model

   IBC is a packet, not a wrapped token story

   A proof that a packet was committed on a source chain is verified by the destination's light client. The asset that then appears is an application of that packet. The paper's core is the proof path.

4. Claim 04 · Paper model

   Light clients are the trust cut

   You do not trust the hub's validators to tell you what a zone did. You check a light-client proof. If a zone's validator set is captured, the proofs from that zone are captured. Isolation is a feature.

5. Claim 05 · Paper model

   The 2016 paper predates the live hub

   The Cosmos Hub, the ATOM distribution and the later interchain security option are subsequent. Interchain security in particular relaxes the 'each zone brings its own validators' picture and should be labelled as later.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

1. 01 A hub is not a master

   Observation

   What the study says

   The paper describes zones, each with its own validators, and a hub that moves packets between them. The hub does not re-execute the zone. Sovereignty is the point.

   Model

   What has to hold

   Application logic treats incoming packets as claims from a named chain, not as local truth.

   Falsifier

   What would retire it

   Does this zone have its own validator set?

2. 02 Tendermint is the default engine, not the definition

   Observation

   What the study says

   Zones need fast finality so a packet has a committed source. The paper picks a Byzantine engine for that reason. Another engine with real finality could fit the shape.

   Model

   What has to hold

   Each zone has finality. A probabilistic chain needs extra confirmations before a packet is safe to prove.

   Falsifier

   What would retire it

   What finality does the source need before a packet may be proven?

3. 03 IBC is a packet, not a wrapped token story

   Observation

   What the study says

   A proof that a packet was committed on a source chain is verified by the destination's light client. The asset that then appears is an application of that packet. The paper's core is the proof path.

   Model

   What has to hold

   Light clients on the destination track validator-set changes of the source.

   Falsifier

   What would retire it

   What finality does the source need before a packet may be proven?

4. 04 Light clients are the trust cut

   Observation

   What the study says

   You do not trust the hub's validators to tell you what a zone did. You check a light-client proof. If a zone's validator set is captured, the proofs from that zone are captured. Isolation is a feature.

   Model

   What has to hold

   Light clients on the destination track validator-set changes of the source.

   Falsifier

   What would retire it

   Does this zone have its own validator set?

5. 05 The 2016 paper predates the live hub

   Observation

   What the study says

   The Cosmos Hub, the ATOM distribution and the later interchain security option are subsequent. Interchain security in particular relaxes the 'each zone brings its own validators' picture and should be labelled as later.

   Model

   What has to hold

   Each zone has finality. A probabilistic chain needs extra confirmations before a packet is safe to prove.

   Falsifier

   What would retire it

   Does this zone have its own validator set?

03 Sequence

One action, as an operating tape

1. 01A zone commits a packet at some height under its own consensus.
2. 02A relayer, which can be anyone, carries the packet and a light-client proof to the destination.
3. 03The destination verifies the proof against the source validator set it has been tracking.
4. 04The destination application mints, unlocks, or otherwise acts. That policy is local.
5. 05A timeout packet can return if the destination never acknowledged, so the source is not left assuming success.

04 Load-bearing

The argument, and where a pitch drops it

1. Sovereignty means you can fail alone

   The cut

   A zone with a weak validator set can be double-spent even while the hub is healthy. The paper prefers that outcome to a world where one validator set must execute every application. Products that cannot tolerate a neighbour failing should not cite this sovereignty as if it were shared security.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   Sovereignty means a zone can fail on its own. The hub does not lend it security.

2. Relayers are not trusted, and they are not free

   The cut

   Anyone may carry a packet. Someone must bother. A path with no relayer is a proof that exists and a message that does not arrive. The paper's liveness includes this labour.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   A peg to an external chain reintroduces the custodian or bridge assumption the paper is trying to narrow.

3. Light-client updates are the quiet assumption

   The cut

   The destination must know the source's current validator set. Updating that set is itself a verified step. Skip it, and the destination is checking proofs against a dead committee, which is how forged packets get in.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   The paper is not a map of the current Cosmos token or any particular zone's status.

05 Register

What has to be true

• Model · Not re-measured

  Each zone has finality. A probabilistic chain needs extra confirmations before a packet is safe to prove.

• Model · Not re-measured

  Light clients on the destination track validator-set changes of the source.

• Model · Not re-measured

  Relayers exist for the paths users care about.

• Model · Not re-measured

  Application logic treats incoming packets as claims from a named chain, not as local truth.

06 Divergence

What happened after the paper

The Cosmos Hub and IBC launched, and hundreds of zones connected. Interchain security and similar later designs let a zone borrow another chain's validators, which is a real change to the 2016 sovereignty default. Say which model you are looking at.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

1. Kill test 1Does this zone have its own validator set?
2. Kill test 2What finality does the source need before a packet may be proven?
3. Kill test 3Who relays, and what happens if they stop?
4. Kill test 4How does the destination track the source validator set?
5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

09 Lexicon

Terms, opened into the record

Zone

An application chain with its own consensus, connected by packets rather than by shared execution.

Hub

A chain specialised in moving packets among zones. It is a route, not an owner.

Light client

A verifier that checks a chain's headers and validator set without replaying every transaction.

Packet

A committed message plus a proof, which the destination checks before acting.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

11 Related

The next papers, as theses

• Tendermint · 2014

  Tendermint: Consensus without Mining

  A practical Byzantine-fault-tolerant state machine for a known validator set, with instant finality on commit. It became the consensus engine under Cosmos SDK chains. The 2014 note is the origin, not the current CometBFT specification.

• Polkadot · 2016

  Polkadot: Vision for a heterogeneous multi-chain framework

  Wood's 2016 vision paper: a relay chain that provides shared security and a queue of cross-chain messages, with parachains that keep their own state transition. It is a vision paper. The live protocol has a specification of its own.

• THORChain · 2020

  THORChain: a decentralised liquidity protocol

  THORChain's design for continuous liquidity pools that cross native chains. Nodes bond capital, observe external chains, and sign outbound transactions as a threshold set. It is a liquidity network, not a wrapped-asset bridge run by a single custodian.