What is BlockDAG

Waterfall is not a chain of blocks. It is a directed acyclic graph of blocks — a BlockDAG. This single design decision is what allows the network to publish many blocks at the same moment instead of one at a time, and it shapes almost everything else in the protocol.

This page explains what that means in practice. For the mechanics of how the network agrees on all of it, see Consensus.

The limit of a single chain

In a classic blockchain every block points to exactly one parent, so the ledger is a straight line. That line is the bottleneck: however many participants are online and however fast their hardware is, the network advances one block per slot. Raising throughput then leaves only two levers — bigger blocks or shorter slots — and both of them push the load onto individual nodes and, past a certain point, onto decentralization itself.

Waterfall keeps blocks and slots at a size ordinary hardware can handle, and adds a third lever: how many blocks may be published in the same slot.

Blocks in parallel

In the Waterfall Shard network, several Verifiers are entitled to produce a block in the same slot. They do so independently and simultaneously — they do not wait for one another, and none of them is "the" block for that slot.

Each block references not one parent, but every tip-block of the DAG its producer knows about. A tip is simply a block that nothing has referenced yet. By linking to all of them, an honest producer folds all the work it has seen into its own block.

Blocks published in parallel across four slots, each referencing all known tips of the previous slot; one spine block per slot forms the linear order — Figure 1: Several blocks are published per slot. Each references all tips it knows of; the spine blocks give the graph a single order.

The result is a graph rather than a line. Nothing is discarded, nothing is orphaned, and no producer's work is wasted because someone else was faster.

From a graph to an order

A ledger still needs a single, agreed sequence of transactions — you cannot execute a graph. Waterfall derives that sequence through spine blocks.

Out of the DAG, the protocol identifies one spine block per slot. The chain of spine blocks is a straight line through the graph, and it fixes the order: everything a spine block references, directly or indirectly, is ordered before it. This step is called linearization, and it does not happen in the Shard network at all — the spine chain is published into the Coordinating network, where committees vote on it and finalize it.

So the two concerns are cleanly separated:

the Shard network produces throughput, in parallel, as a DAG;
the Coordinating network produces order and finality, sequentially, one slot at a time.

Why parallel blocks do not conflict

The usual objection to parallel block production is double-spending: two producers, unaware of each other, both include a conflicting transaction.

In Waterfall this is handled at ordering time rather than at production time. Blocks are not required to be mutually consistent when they are published — they are ordered afterwards by the spine chain, and transactions are executed in that order. A transaction that has already been applied is not applied a second time. Every block that does not conflict is finalized, and conflicts are resolved deterministically by position in the order rather than by discarding blocks.

Producing more than one block in the same Shard slot, on the other hand, is a violation: if such blocks are finalized in the Coordinating network, the Verifier is penalized. See Penalties.

What this means in practice

Throughput scales with the width of the DAG. Adding blocks per slot raises the ceiling directly, without making any single block larger or any single slot shorter. In the private-network test series, 35 blocks per slot at 10,000 transactions per block over 2-second slots reached a peak of 175,000 TPS and 128,333 TPS sustained over 30 seconds — see Private Network Test 29 and the throughput analysis. Those runs were executed inside a single datacenter, so a real distributed network should be expected to deliver less.

Fees fall as the network grows. The base transaction fee depends on how many blocks are published per slot, so a wider DAG spreads demand across more block space. Load that would create a fee spike in a single-chain system is absorbed by width instead. The formula and its parameters are in Economics.

Block space is not a race. With one block per slot, producers compete and losers are orphaned. In a DAG they contribute in parallel, which keeps rewards predictable for ordinary Verifiers and lowers the advantage of unusually fast hardware.

Width is adjusted automatically. Blocks per slot, slot time and the optimal number of Validators are protocol parameters that adapt to load rather than fixed constants — see What Makes Waterfall Unique.

The limit is not the graph itself. As the test series showed, pushing width and slot time together raises the ceiling but also the per-node scheduling and CPU pressure, so node capacity and node count have to grow with it. That is the problem Subnetworks address.