Skip to main content

Consensus Specification

August 2025

Introduction​

The delta network uses a proof-of-stake consensus protocol that allows network validators to agree on which transactions will deterministically update the system state.

The protocol operates on a time-based epoch system, where each epoch (typically configured for about an hour) represents a period during which transactions are synchronized and ultimately accepted (i.e. applied to the system state) in all validators. At the end of each epoch, validators are guaranteed to have the same view of the system state.

For lower latency, delta implements a "fast-path" mechanism that allows certain transactions to be accepted as soon as possible, rather than waiting for an epoch boundary. By design, these transactions cannot modify key global data of the system state, such as the stakes of the validators.

This document presents the input-output specification of the consensus service that implements the consensus protocol, abstracting over the protocol definition and its implementation.

Definitions​

Transactions are uniquely identified by their data. Two transactions are considered "the same" if and only if they contain identical data. Each transaction includes "signer", "nonce" and “signing epoch” fields as part of this data.

Each validator divides its timeline into contiguous, non-overlapping epochs, each configured to be approximately 1 hour in length.

The main output of the protocol is an event stream of “accepted” transactions, on which it’s guaranteed that the network reached consensus. At the end of each epoch, the consensus decides a set of transactions to be accepted. Certain transactions, called "fast-path" transactions (a property defined based on the transaction data), can also be accepted during an epoch rather than only at epoch boundaries.

The consensus protocol is implemented by a consensus service communicating with the rest of the system via the following channels:

  • Inputs:
    • A stream of “submitted” transactions, received by the RPC server of the validator.
    • A stream of network messages, arriving from other validators.
  • Outputs:
    • A stream of network messages, sent to other validators.
    • A stream of submitted transactions that have been rejected.
    • A stream of the following possible events:
      • An epoch ended and a set of transactions have been accepted.
      • During an epoch, a fast-path transaction has been accepted.
      • An “out of sync” notification, which informs the rest of the system that, based on the consensus protocol, the validator recognized that it’s too slow.

Assumptions​

At any time, in a network of 3f+1 validators, at least 2f+1 are honest.

Partial synchrony model: starting from an (unknown) time instant called Global Stabilization Time (GST), all network messages from honest validators are always delivered within an (unknown) Δ time interval.

In general, the consensus might receive any transaction at any time, possibly with duplicates, from users, executors or other validators.

Guarantees​

Safety​

Within one epoch:

  • All honest validators accept the exact same set of transactions (i.e. the set of transactions accepted via fast-path or accepted at the end of the epoch).
  • In honest validators, each transaction is accepted at most once.
    • e.g. The same transaction is not accepted twice via two fast path events, or once via the fast path and once at the end of the epoch.
  • In honest validators, all accepted transactions have different (signer, nonce) pairs.
  • All transactions accepted during a certain epoch have been signed in the same epoch.

At any time, at least f+1 honest validators are in the same epoch.

In practice (no formal guarantees), we strongly expect:

  • Except for a few seconds around an epoch boundary, all honest validators are in the exact same epoch.

Liveness​

  • In honest validators, each epoch eventually terminates (with probability 1).
  • Each time a hones validator receives a submitted transaction, the transaction will eventually be accepted or rejected.

In practice (no formal guarantees), we strongly expect:

  • Each epoch terminates within a few seconds after the local timer of the epoch expires.
  • When a honest validator receives a submitted transaction X, if there exists no other transaction with the same (signer, nonce) pair, and if the transaction has been signed in the current epoch:
    • If X is submitted well before the end of the epoch then it’ll be accepted. In particular, if X is a fast-path transaction, it’ll be are accepted within a few seconds.