Consensus

Waterfall splits the job of a consensus protocol in two. One network produces transaction throughput in parallel; a second one decides the order and makes it final. Both are Proof-of-Stake, both are driven by the same set of Validators, and neither works without the other.

This page describes how they fit together. For the data structure they operate on, read What is BlockDAG first.

Two networks, one Validator

Figure 1: Coordinating and Shard networks (left panel) and the structure of a node (right panel).

A staked participant is a Validator, and it is present in both networks at once through two parts:

Part	Lives in	Does
Coordinator	Coordinating network	Holds the stake, proposes blocks and votes in committees. Earns minted rewards.
Verifier	Shard network	Produces BlockDAG blocks with transactions in them. Earns transaction fees and tips.

One node can run many Validators. A single withdrawal address controls deactivation and the withdrawal of stake and rewards for both parts of a Validator.

Becoming a Validator requires a stake of 32,000 WATER.

The Coordinating network also keeps the register of Validators — who is staked, who is active, and who is entitled to do what in which slot.

Slots, epochs, eras

Time is divided into slots, slots are grouped into epochs, and epochs into eras.

At the beginning of each epoch the Coordinating network assigns roles for the slots in it: which Verifiers may produce blocks, which Coordinators sit on which committee, and which Coordinator leads each slot. Assignment is a shuffle seeded by block hashes, so roles are known only shortly in advance and cannot be steered by the participants.

That seed has a subtle failure mode: if the network is idle and no blocks carry transactions, there is no fresh hash and the next shuffle becomes predictable. The protocol closes it by letting a Verifier publish an empty block in such an epoch purely to generate a new hash.

Eras are the coarsest unit and matter mainly for validator state: a penalized Validator is suspended for the current and the next era.

A slot in the Shard network

Every Verifier assigned to the slot produces its block independently and simultaneously with the others, referencing all tip-blocks of the DAG it knows about. There is no competition for the slot and no orphaning — see What is BlockDAG.

Before the leader publishes, participants of the previous slot exchange their view of the DAG with one another. The leader uses that shared view to publish an optimal block, rather than a block based only on what it happened to receive itself. This is the proposer recommendation step, and it is what makes the optimistic consensus reliable when propagation is uneven.

A slot in the Coordinating network

The Coordinating network advances one block per slot and turns the graph into a ledger.

The slot leader proposes a block. Among other things it carries the up-to-date chain of spine blocks taken from the Shard network — the proposed linear order of the DAG.
Several committees, whose members are Coordinators, vote on that proposal. A committee member's vote covers four things:
- the latest up-to-date chain of spine blocks in the DAG,
- the source block in the Coordinating network,
- the target block in the Coordinating network,
- and timeliness — voting late is worth less.
The leader of a following slot includes those votes in its block.
Once enough votes accumulate, the order is finalized. Every block of the DAG covered by the finalized spine chain is final, and its transactions are settled in that order.

Because linearization and finalization both happen in the Coordinating network, throughput in the Shard network can be scaled without weakening the security of the ledger.

Who gets paid, and for what

Voting and the inclusion of votes are treated as equally necessary, so rewards go to all three contributions:

each committee member that casts a valid vote;
the slot leader, for a proposal that a committee member supported;
the slot leader, for including that vote in its block.

The committee member's reward is four equal parts, one for each of the four things voted on above. The timeliness part decays sharply: voting one slot late halves it, two slots late reduces it threefold.

Coordinator rewards are newly minted coins, accrued every epoch and sized by the principle of Minimum Necessary Issuance — the amount depends on how much is staked network-wide rather than on a fixed schedule. Verifiers, in turn, are paid out of transaction fees and tips.

Full formulas are in Economics.

What is penalized

Penalties are calibrated to exceed any gain an attack could produce, and are applied automatically for:

a Coordinator missing a series of committee votes;
a Coordinator signing conflicting messages, such as double voting;
a Coordinator failing to produce a valid block in its Coordinating slot;
a Coordinator producing more than one block in the same Coordinating slot;
a Verifier producing more than one block in the same Shard slot, where those blocks get finalized;
a Coordinator submitting invalid proof of any of the above.

No separate consensus round is needed to punish: a whistleblower records the proof in its own block when its turn comes, and all Coordinators decide from the coordinating ledger alone. Penalties accumulate — three blocks where one was due doubles the penalty.

A Validator whose balance falls below 50% of the initial stake permanently loses the right to produce and verify blocks; rewards earned do not count towards that threshold. Short of it, a penalized Validator is suspended for the current and next era, which gives an operator time to fix equipment without losing the stake. See Penalties.

Validator lifecycle

A Coordinator moves through an explicit set of states, visible in the node status output:

Status	Meaning
`pending_initialized`	First deposit processed, but not enough funds yet, or not yet the end of the first epoch, to enter the activation queue.
`pending_queued`	Waiting in the activation queue; the activation epoch keeps shifting until it reaches the front.
`active_ongoing`	Attesting normally, no exit initiated.
`active_exiting`	Still active, voluntary exit requested.
`active_slashed`	Still active, slashed and scheduled to exit.
`exited_unslashed`	Reached a regular exit epoch without being slashed; no longer attests, cannot withdraw yet.
`exited_slashed`	Reached exit after being slashed; a longer withdrawal period applies.
`withdrawal_possible`	Exited and permitted to move funds.
`withdrawal_done`	Funds moved.

Activation and exit are epoch-bounded and require finalization, which is why joining and leaving the validator set is never instant.