Skip to content

LibraryConsensus2018Design paperCorpus record

Chainweb: A Proof-of-Work Parallel-Chain Architecture for Massive Throughput

Kadena. Will Martino, Monica Quaintance, Stuart Popejoy.

Kadena's public parallel-chain design. Many proof-of-work chains advance together, and each block commits to peer-chain headers, so a confirmation is a braid rather than a single chain. This is not the 2016 private-chain note already in the historic library.

The historic library already includes Kadena's 2016 private-chain consensus note. Chainweb is the later public design.

Chainweb braids many proof-of-work chains so that each block commits to its peers' previous headers. The claim is that the braid gives throughput and makes a deep reorg on one chain visible to the others.

The five-minute read

One chain's hash rate is a ceiling

Kadena's paper does not abandon proof of work. It runs many chains, each with its own blocks, so work happens in parallel.

Cross-links are the braid

A block on one chain includes hashes of recent blocks on neighbouring chains. To rewrite one chain deeply, an attacker has to keep those neighbours consistent too.

The graph is fixed at a layer

The paper describes a topology, often thought of as a Petersen graph in the public explanation, of which chains reference which. The topology is a parameter with a security meaning.

Pact is the language beside the braid

Human-readable contracts sit on this chain web. The consensus paper and the language paper answer different questions. Throughput does not make a contract correct.

Confirmation is a braid depth

A transaction is not confirmed because its own chain buried it. Neighbouring chains have to have had a chance to cite that height. Wallets that only watch one chain are under-confirming.

One action, walked through

  1. Miners on each chain attempt proof of work for the next block, including peer-chain hashes in the header they are hashing.
  2. A valid block advances one chain and freezes a view of its neighbours at the cited heights.
  3. A transaction is included on the chain that holds the relevant accounts.
  4. As neighbouring chains cite that block and are themselves cited, the cost of reversing it grows with the whole braid, not with one chain's subsequent blocks.
  5. A cross-chain call, if the product uses one, waits until the cited height is what the protocol treats as settled.

The argument, unpacked

Parallel proof of work is still proof of work

Energy is not removed. It is spread. The paper's argument is about how much hash rate an attacker needs to unwind the braid compared with a single chain. It is not an argument that hashing became cheap or green.

The topology decides the security multiplier

If chains only cite one neighbour, a local rewrite is easier than if each chain is tied to many. Quoting 'twenty chains means twenty times safer' without the graph is bad arithmetic. The paper's claim follows the cross-link structure.

Load does not balance itself

A hot contract on one chain does not automatically spill onto the others. Sharding of state has to be designed in the accounts. A single-chain traffic jam inside a braid is still a jam.

What has to be true

  • Hash rate is distributed across chains roughly as the security argument expects. An idle chain is a weak link in the braid.
  • Peers' headers are available. A cross-link to a header nobody can fetch is not a commitment.
  • Miners include the cross-links the protocol requires. A client that ignores missing links is not following the paper.
  • Confirmation logic in wallets waits for braid depth, not for one chain's depth alone.

What happened after the paper

Kadena ran a public Chainweb with Pact contracts. The number of chains and the exact topology are parameters of the deployed network. The 2018 paper is the braiding argument. Measured throughput and miner distribution are facts about the deployment, and they move.

What to check before you use the idea

  • Which chains cite which, and how deep must a citation be before a wallet accepts it?
  • Is hash rate actually present on every chain in the braid?
  • What does a user do when one chain is congested and the others are idle?
  • Is Pact's contract model being cited, or the consensus braid? They are not the same document.

Terms

Braid
The structure formed when parallel chains commit to each other's recent headers.
Cross-link
A hash of a peer chain's block, placed in this chain's header, so the two histories constrain each other.
Braid depth
How far neighbouring chains have advanced since a block, which is the paper's notion of confirmation.
Pact
Kadena's contract language. It runs on the braid. It is not the consensus proof.

The problem the paper names

One proof-of-work chain confirms slowly if you wait for depth, and it does not get more throughput by adding miners — it gets more energy per block. Chainweb's proposal is to run many chains and braid them so that depth on the braid is what a recipient waits for.

What the design proposes

  • A fixed graph of chains. Each new block includes hashes of peer blocks.
  • Reorg resistance is argued on the braid, because changing one chain requires changing its peers.
  • Throughput is intended to scale with the number of chains, under the paper's assumptions.

How the mechanism is specified

  • Miners may work on different chains. The braiding is what stops the system becoming twenty unrelated ledgers.
  • Cross-chain transfers have to be defined on top of the peer references. They are not free.
  • Pact, Kadena's contract language, is a related document, not this consensus paper.

What this page does not treat as proven

  • The historic PDF Kadena-ConsensusWhitePaper-Aug2016.pdf is the earlier private-chain note. Do not mix the citations.
  • The paper's scaling picture is not a live benchmark.
  • A fixed chain graph is a parameter. Changing it is a migration, which the paper does not do for you.

Why a venture studio still reads it

Parallel chains are easy to draw and hard to braid. Chainweb is the reference we point at when a pitch says 'twenty chains' and has not said what each block commits to besides its own parent.

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.