Skip to main content


Before diving deeper into the consensus algorithm's inner workings, you should familiarize yourself with the following terms.

Epochs and Slots

The IOTA protocol divides time into non-overlapping slots of fixed duration slotDurationSeconds, set to 10 seconds. Slots are indexed with the slot index s=0,1,2,3,...s = 0, 1, 2, 3,.... The slotTime interval of fixed duration. The protocol divides time into non-overlapping slots. For each slot, nodes generate a slot commitment which encapsulates all accepted blocks and transactions issued within this time interval. indexed with 00 is a unique slot that commences at negative infinity and concludes at the genesis timestamp genesisUnixTime. Every 2^slotsPerEpochExponent sequential slots are grouped into epochs, which are enumerated with the epochA specific time period during which a dedicated committee is responsible for driving consensus. Epoch consists of multiple slots. index e=0,1,2,3,...e = 0, 1, 2, 3,....

Using slots primarily aims to generate commitments for short time intervals. Generating commitments in a timely manner allows nodes to keep in Random Access Memory (RAM) only data of bounded size.

Slot commitments improve the convergence of the overall consensus and let nodes know whether they need to synchronize their views on the Tangle. In addition, slot commitments facilitate data locality: understanding where a block belongs makes tasks such as block lookups, eviction, and pruning more straightforward. Furthermore, finalization occurs on the slot commitment level.

The committee members are fixed within a given epoch, and their voting weights remain constant. However, at the epoch boundary, reconfiguration becomes possible, leading to potential changes in the composition of the committee and adjustments in their voting weights.

Epoch Committee

For an epochA specific time period during which a dedicated committee is responsible for driving consensus. Epoch consists of multiple slots., a fixed subset of validators is responsible for achieving agreement about blocks and transactions issued during the epoch. This set has the size committeeTotalSeats (between 25 and 50). The selected set of validators is called the epoch committee.

A committee member is expected to issue validation blocks every frequencyValidationBlock seconds (set to either 0.5 or 1) and to follow the tip selection algorithm for selecting tips to be referenced by the validation blocksValidation Blocks is a special type of blocks that are issued by members of the Validator Committee. These block allows to reach consensus in the network..

Total committee

Denote the total committee for epoch ee as Ctotal(e)\mathcal{C}_{total}(e). Denote the voting weight of a node ii at epoch ee as Wi(e)W_i(e). Note that Wi(e)>0W_i(e)>0 if and only if ii is a committee member in epoch ee, i.e., iCtotal(e)i\in \mathcal{C}_{total}(e).


In the first version of the protocol, all committee members have the same weight, specifically if Wi(e)>0W_i(e)>0, then Wi(e)=1W_i(e)=1. This will be changed in future updates of the protocol.

The total committee is determined for slot commitment chains. Specifically, two nodes that adopt the same slot commitment chainA chain created by a sequence of slot commitments. It is used to determine eligible blocks and finality. before an epoch ee starts perceive the same total committee for epoch ee.

To support the dynamic availabilityThe ability of the system to continue to accept or confirm transactions despite arbitrary number of validators crashing. of the protocol and timely generate slot commitments, only actively participating committee members are considered when determining which blocks and transactions are accepted.

Online committee

At time instant tt at epoch ee, a node perceives the online committee Conline(t)Ctotal(e)\mathcal{C}_{online}(t)\subset \mathcal{C}_{total}(e), as a subset of the committee that consists of committee members who have issued at least one block with the timestamp within (t-activityWindow, t].


The online committee is a subjective notion determined by each node locally based on its perception of the Tangle. The block in the above definition must commit to the slot commitment chain a node adopts. The protocol parameter activityWindow is set to 10 seconds.

Total weight

Denote the total weight of the total committee at epochA specific time period during which a dedicated committee is responsible for driving consensus. Epoch consists of multiple slots. ee as:


Online weight

Denote the online weight of the online committee at moment tt at epoch ee as:


Wtotal(e)W_{total}(e) is constant for the whole epoch ee, whereas Wonline(t)W_{online}(t) can be changed based on the perception of a node at the moment tt.

In the following, the time instant index tt and epoch index ee are omitted in notation to simplify the discussion.

About Blocks and the Tangle

The basic unit data structureA data structure is a way of organizing data so that it can be efficiently and effectively used. The Tangle uses a variety of data structures, including blocks, payloads, transactions, and commitments, to store and process data. in IOTA 2.0 is called a block. The collection of all blocks is called the Tangle. Since blocks contain references to previously issued blocks, the Tangle is a directed acyclic graph (DAG).

For the notation of this article, a block is denoted as bb, and a specific content of the block is referred to using the following fields

Name of the fieldDescription
b.Txb.TxThe payload of block bb
b.SlotCommitmentIDb.SlotCommitmentIDThe slot commitment included to block bb
b.IssuerIDb.IssuerIDThe ID of the issuer of block bb
b.Referencesb.ReferencesThe references to the previously issued blocks
b.IssuingTimeb.IssuingTimeThe timestamp of block bb

Table: Fields of a block.

Block Fields

Some fields in the block structure have been omitted to simply this article.

Supplementary Definitions

Block approves block

A block bb approves a block cc if there is a sequence of blocks b1=b,b2,,bt=cb_1=b,b_2,\ldots,b_t=c such that bib_i directly references bi+1b_{i+1}, i.e. bi+1bi.Referencesb_{i+1}\in b_i.References.

Cones of a block

Past cone of a block

For block bb, the set of blocks that bb approves is the past cone of bb.

Future cone of a block

For block bb, the set of blocks that approve bb, is the future cone of bb.


In the following example, the past coneThe set of messages that are directly or indirectly referenced by a given message is termed its past cone. of block xx is highlighted in red, encompassing all the blocks reachable from xx by following the directed edges. Similarly, the future cone is highlighted in blue.

Future and past cones of a block Image: Future and past cones of a block.

Block votes for conflicting transaction

A block bb and the issuer b.IssuerIDb.IssuerID vote for a conflicting transaction txtx if the branch of block bb contains txtx.

Block approves slot commitment

A block bb approves a slot commitment CC if the slot commitment chain that ends with b.SlotCommitmentIDb.SlotCommitmentID contains CC. For instance, the block bb approves the slot commitment CC if bb contains CC, i.e., b.SlotCommitmentID=Cb.SlotCommitmentID = C.

Block References

Block references in IOTA 2.0 simultaneously serve two purposes:

  1. Contributing to the construction of an immutable directed acyclic graph structure on the block set.
  2. Encoding the issuer's perspective on which part of the Tangle is valid and which conflicting transactionsTransactions that consume the same UTXO. are supported by a majority of the network. This means that nodes perform voting directly on the Tangle by including appropriate references in their blocks.

Block references are crucial in the consensus protocol as they guide the tip selection algorithm.

Reference Types


Nodes randomly select strong parents from their tip poolCollection of blocks selected by the node for potential selection as a parent. and attach their newly issued blocks to these selected tips. The number of strong parents sets a tradeoff between confirmation time and the block size. More strong parents lead to shorter confirmation times and larger block sizes. When computing the branch of a new block, the branches of strong parents are directly inherited by the branch of the new block.

Shallow Like

Shallow like references are essential for rectifying the preliminary block's branch constructed from the strong parents. They align the block's branch with the issuer's preferred reality.


Weak references serve a different purpose. They come into play when the branches of certain strong parents cannot be aligned with a limited number of shallow like references. In such cases, strong parents are moved to the weak tip pool, and a bounded number are selected as weak parents. Weak references attempt to prevent orphaning blocks that may have voted for a large set of conflicts.

Total and Online Supermajority

To formally define consensus flagsConsensus flags for a block represent confidence levels about whether the block is successfully gossiped and included in the Tangle by the network. They include Pre-Acceptance, Acceptance, Pre-Confirmation, Confirmation, and Finalization, the notion of total and online supermajorities of blocks is introduced. A supermajorityA threshold for achieving consensus flags. A supermajority is a subset of the committee that has more than two-thirds of the total voting power. of a subset of blocks means that the issuers of these blocks have more than 2/32/3 of the total voting weight.

Total supermajority

A set of blocks AA is called a total supermajority of blocks if the relative weight of the issuers of blocks from AA is more than 2/32/3 of the total weight. In other words, let IssuerIDs(A)={b.IssuerID: bA}IssuerIDs(A)=\{b.IssuerID: \ b\in A\}, then

iIssuerIDs(A)Wi>23Wtotal.\sum_{i\in IssuerIDs(A)}W_i > \frac{2}{3} W_{total}.

Online supermajority

A set of blocks AA is called an online supermajority of blocks if the relative weight of issuers of blocks from AA is more than 2/32/3 of the online weight. In other words,

iIssuerIDs(A)Wi>23Wonline.\sum_{i\in IssuerIDs(A)}W_i > \frac{2}{3} W_{online}.

Slot Commitment Chain

Each block in IOTA 2.0 contains a commitment to the content of a certain slot in the past. A slot commitment is a hash value that encapsulates all the crucial information about a slot (such as accepted blocks and transactions, the index of the slot, etc.). A slot commitment is calculated by combining the following pieces of information through hashing:

1. Protocol version

The field denoting the protocol version that will be increased after each protocol upgrade.

2. Slot index

The index of a slot to which a slot content is committed. For a time instant timeInstant, the respected slot index is computed as Floor((timeInstant - genesisUnixTime)/slotDurationSeconds) + 1, where genesisUnixTime is the starting point of the timeline or the timestamp of the genesis block.

3. Previous slot commitment

The slot commitment of the slot with the preceding slot index.

4. Commitment of slot content

The hash root of a Merkle tree that contains all commitment elements at the end of this slot. For simplicity, one can think about this value as the hash of all accepted blocks and transactions issued within the slot.

5. Cumulative weight

The total weight of validators that reference a specific commitment in the past and the cumulative weightA system for valuing transactions. The cumulative weight of a transaction increases with each additional transaction that references it. A path through transactions with a higher cumulative weight is preferred when selecting tips. of the previous slot commitment.

6. Reference mana cost

The reference ManaA reward resource generated by holding IOTA tokens. It is utilized for block issuance, access to network throughput, and protecting against Sybil attacks. cost (RMC) is calculated from the contents of the slot and the previous slot’s RMC.


A commitment is linked to the commitment of the previous slot. All commitments form a slot commitment tree, where the path between the tree root (the genesis) and any node in the tree determines a slot commitment chain. Nodes that adopt the same slot commitment consequently adopt the same slot commitment chain. So, they agree on the common prefix of the ledger and the Tangle up to the last slot of the chain.

Each node maintains its slot commitment chain based on its understanding of the Tangle. The node tracks the online committee, that adopted the same slot commitment chain as the node. Upon receiving validation blocks, the node identifies which blocks and transactions get accepted by the online committee and flags them as accepted in turn. The accepted objects will then provide a basis for generating the commitment of slot content in the structure of a slot commitment.

The commitment for a slot that ends at the moment slotEnd is produced by the node at some moment in the period [slotEnd+minCommittableSlotAge*slotDurationSeconds, slotEnd+maxCommittableSlotAge*slotDurationSeconds], where minCommittableSlotAge and maxCommittableSlotAge are specially designed protocol constants measured in slot units.

The actual moment depends on the accepted Tangle time of the node. More specifically, if one of the conditions holds:

  • the accepted Tangle time is larger than slotEnd+minCommittableSlotAge*slotDurationSeconds;
  • the current wall clock is at least slotEnd+maxCommittableSlotAge*slotDurationSeconds;

then the node generates the commitment of the required slot.

Reality-based UTXO ledger

As ChrysalisThe name of the IOTA 1.5 network upgrade. and Stardust, IOTA 2.0 uses the Unspent Transaction Output (UTXO) model for transactions. Its parallel processingThe parallel validation of transactions without requiring total ordering. Processing can be done on multiple cores at the same time. capability allows independent transactions to be added to the ledger in any order, thus enhancing its scalability potential.

However, the append-only nature of the UTXO ledger can compromise this benefit when conflicting transactionsTransactions that consume the same UTXO. arise. To address this issue, IOTA 2.0 uses an enhanced UTXO ledger model, called the reality-based UTXO ledger, that optimistically updates the ledger and maintains a record of the dependencies of possible conflicts.

A UTXO transaction should have a list of unique outputs called UTXOs. In addition, each transaction has a list of inputs, which are UTXOs of previous transactions. A transaction is said to spend its inputs.

Ledger DAG

The ledger DAG is a DAG whose vertex set consists of all transactions. There is a directed edge between two transactions txtx and tyty if txtx spends the output of tyty. The ledger DAG's root is the genesis with no outgoing edges.

Causal history of a transaction

The causal history of a given transaction txtx consists of all transactions that can be reached from the transaction txtx by traversing the ledger DAG along the directed edges.


A transaction txtx is a conflict if there is another transaction tyty such that txtx and tyty attempt to spend at least one identical input.

Conflicting transactions

Two transactions txtx and tyty are called conflicting if the causal history of txtx and the causal history of tyty contain some transaction txtx' and tyty' which spend at least one identical input.

Non-conflicting transaction

A transaction txtx is non-conflicting if there is no transaction tyty such that txtx and tyty are conflicting.

Rejected transaction

A transaction txtx is rejected if there is a transaction tyty, which is conflicting with txtx and has been accepted.

In other words, once a transaction gets accepted, all transactions conflicting with it get rejected. Rejected transactions are removed from the reality-based ledger.


To understand the voting mechanism on the Tangle, it is essential to introduce the fundamental definition of branches.


A branch is a subset of conflicts BB if these two properties hold:

  1. Set BB does not contain two conflicting transactions.
  2. For any conflict txBtx\in B, all conflicts in the causal history of txtx are contained in BB.

One prominent example of branches is defined using the causal history of transactions.

Branch of a transaction

The set of all conflicts in the causal history of a transaction txtx is called the branch of txtx and denoted as Branch(tx)Branch(tx).

Branch of a block

For a block bb, there is the branch of bb, which is encoded through the references. This branch is denoted as Branch(b)Branch(b) and it can be computed using an algorithm.


A block votes for a conflicting transaction txtx if the branch of the block contains txtx. In such a case, the issuer of the block is also said to vote for txtx.

The issuer of a block votes for (supports) all conflicts in the branch of that block. Nodes use this simple idea to agree on which conflicting transactions should be accepted and included in the ledger and which should be rejected.

To determine the conflicts supported by a node, you need to understand the concept of the preferred reality.


A maximal branch is called a reality. In other words, for a reality, there is no larger branch containing this reality.

There is an exponential number of realities in the number of conflicts. However, every node at any moment can find its unique preferred reality by following the algorithm. This algorithm is practical as it has quadratic complexity in the number of conflicts.

The preferred reality represents the complete set of conflicts supported by a node. In principle, when choosing between two conflicting transactions, a node supports the one that has received more votes from the committee, i.e., validation blocks with more voting weight voted for that transaction.

In the actual implementation, the preferred reality is not fully computed at any moment. Instead, the concept of a preferred reality is implicitly used in the tip selection algorithm.

When issuing a new block, the node finds the preferred branch (an appropriate subset of the preferred reality), which conflicts can be referenced using shallow like references, consequently aligning the branch of the new block with the preferred reality.

Learn More

You can find more details about the reality-based UTXO ledger in the Reality-based UTXO Ledger paper.