Skip to main content

Epochs and Reconfiguration

Epoch​

In IOTA, an epoch is a fixed period (typically around 24 hours) during which the validator set and their stakes remain constant. This stable period ensures that transactions are processed smoothly without unexpected validator changes.

Epoch Numbering & Transaction Data​

Epochs are sequentially numbered, and each transaction on the IOTA network includes an epoch identifier. While regular users generally do not need to worry about epochs, they are relevant when dealing with expiring transactions, which must be completed before a specific epoch ends.

Consensus & Checkpoints​

During each epoch, the Mysticeti consensus protocol operates to finalize transactions. Validators reach agreement by collecting transaction effect certificates, ensuring a consistent transaction order. A key part of this process is the checkpoint, which is a snapshot of finalized transactions at the end of an epoch. The checkpoint includes:

  • A set of finalized transactions
  • Validator agreement data
  • State updates required for the next epoch

Reconfiguration​

At the end of each epoch, a reconfiguration process occurs to prepare the network for the next epoch. This involves the following.

1. Finalizing Transactions & Checkpoints​

  • Validators finalize the order of transactions and generate a checkpoint, ensuring a synchronized network state.
  • This step guarantees that an honest majority of validators share the same transaction history, reinforcing consistency and security.

2. Distribution of Gas Rewards​

  • Computation gas fees are distributed to the validator staking reward pool.
  • Stakers can withdraw their rewards after the epoch ends.

Refer to the Staking and Rewards page for more details.

3. Validator Set Updates​

  • Any pending staking and unstaking requests are processed.
  • The validator set is updated—new validators may be added, and inactive ones may be removed.
  • Since staking influences validator selection, it is only processed at epoch transitions.

4. Protocol Upgrades (Optional)​

info

In Byzantine Fault Tolerant (BFT) f represents the number of faulty validators. 2f+1 represents the minimum number of validators needed to agree on a transaction to ensure integrity and finality, even if up to f validators are faulty.

For example, if f = 1, this means 3 validators must confirm a transaction (a supermajority) to guarantee its integrity, ensuring that even if one validator is faulty, the correct decision still stands.

  • If 2f+1 validators (a Byzantine Fault Tolerant supermajority) agree, the network may upgrade to a new protocol version.
  • These upgrades may include:
    • Security patches
    • New protocol features
    • Updates to the IOTA Move framework

Refer to the Protocol Upgrades page for details.