LibraryInteroperability2016Design paperCorpus record
Cosmos: A Network of Distributed Ledgers
Cosmos. Jae Kwon and Ethan Buchman.
The Cosmos paper: independent zones running a BFT consensus, connected by a hub, speaking a packet protocol that later became IBC. Unlike Polkadot's shared-security vision, zones here are sovereign. They choose their own validator sets.
Cosmos separates an application from its consensus, then connects many such applications with a packet protocol that does not pretend they share one validator set.
The five-minute read
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.
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.
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.
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.
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.
One action, walked through
- A zone commits a packet at some height under its own consensus.
- A relayer, which can be anyone, carries the packet and a light-client proof to the destination.
- The destination verifies the proof against the source validator set it has been tracking.
- The destination application mints, unlocks, or otherwise acts. That policy is local.
- A timeout packet can return if the destination never acknowledged, so the source is not left assuming success.
The argument, unpacked
Sovereignty means you can fail alone
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.
Relayers are not trusted, and they are not free
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.
Light-client updates are the quiet assumption
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.
What has to be true
- Each zone has finality. A probabilistic chain needs extra confirmations before a packet is safe to prove.
- Light clients on the destination track validator-set changes of the source.
- Relayers exist for the paths users care about.
- Application logic treats incoming packets as claims from a named chain, not as local truth.
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.
What to check before you use the idea
- Does this zone have its own validator set?
- What finality does the source need before a packet may be proven?
- Who relays, and what happens if they stop?
- How does the destination track the source validator set?
Terms
- 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.
The problem the paper names
Applications forced onto one chain share its governance and its fee market whether they want to or not. Applications on unrelated chains cannot move value without a trusted custodian. Cosmos proposes a standard packet format and a hub so zones can connect without becoming the same chain.
What the design proposes
- Tendermint-style BFT is the default consensus. A zone may be different if it speaks the packet protocol.
- The hub is a zone whose job is routing, not the owner of every application's rules.
- Sovereignty is explicit: a zone's validator set can halt or fork that zone without a relay-chain vote.
How the mechanism is specified
- Light-client proofs are how one zone checks another's header before accepting a packet.
- Peg zones, in the paper, are the intended door to chains that do not speak the protocol natively.
- IBC as shipped has its own specification. Cite that spec for implementation claims, and this paper for the architecture.
What this page does not treat as proven
- Sovereignty means a zone can fail on its own. The hub does not lend it security.
- A peg to an external chain reintroduces the custodian or bridge assumption the paper is trying to narrow.
- The paper is not a map of the current Cosmos token or any particular zone's status.
Why a venture studio still reads it
Use Cosmos when a venture wants several ledgers and is willing to say that they do not share security. Use Polkadot's paper when they are not willing to say that. The distinction is the design choice, not a ranking.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.