Reading Guidelines

The Algorand Specifications consist of normative and non-normative sections.

The normative sections formally define Algorand. The Algorand consensus protocol gates all the components of the normative sections. The scope of these sections is to provide a complete and correct specification of the Algorand protocol, regardless of the implementation. Therefore, the language used in those sections is formal, prescriptive, and succinct.

The non-normative sections provide context and auxiliary information for the Algorand implementation. The components of the non-normative sections are not enforced through the Algorand consensus protocol. The scope of these sections is to ease the understanding of the normative sections and provide readers with a comprehensive view of the Algorand reference implementation (go-algorand). Therefore, the language used in those sections is informal, descriptive, and discursive.

The current version of the Algorand Specifications reflects the latest version of the Algorand consensus protocol in its normative sections and is generally aligned with the latest stable release of go-algorand in its non-normative sections.

Specifications for previous consensus versions can be found via the link provided in the block’s current-protocol.upgrade-state field corresponding to the desired consensus version.

Contents Hierarchy

The node functional diagram above provides an overview of the functional blocks that define the structure of the Algorand Specification.

Contents are organized in four hierarchical levels (see the navigation sidebar on the left):

Part
└── 1. Chapter (Normative / Non-Normative)
    └── 1.1. Section
        └── 1.1.1. Sub Section

Each Part begins with an Overview, highlighting the covered functional blocks, usually divided into two Chapters: normative and non-normative (always present).

The navigation sidebar can be folded up to the Chapter level by clicking the folding icon (>), next to the level name.

Formatting

Notes like this are non-normative comments in the normative sections.

📎 EXAMPLE

Sections like this are examples aiming to clarify the formal specifications.

⚙️ IMPLEMENTATION

Sections like this contain links to the go-algorand reference implementation.

The code-blocks may contain pseudocode or real code snippets.

Math Symbols

For a correct rendering of mathematical symbols and formulas, it is recommended to right-click on the symbol below, and select Math Settings -> Math Renderer -> Common HTML from the drop-down menu.

$$ \mathcal{C} $$

Once MathJax rendering is correctly set, you should see a calligraphic “C”.

PDF Book

Readers used to classical \( \text{\LaTeX} \)-styled books can download the full book from the latest release artifacts.

Algorand Byzantine Fault Tolerance Protocol Specification

The Algorand Byzantine Fault Tolerance protocol (ABFT) is an interactive protocol which produces a sequence of common information between a set of participants.

$$ \newcommand \BBA {\mathrm{BinaryBA⋆}} $$

Conventions and Notation

This specification defines a player to be a unique participant in this protocol.

This specification describes the operation of a single correct player. A correct player follows this protocol exactly and is distinct from a faulty player. A faulty player may deviate from the protocol in any way, so this specification does not describe the behavior of those players.

Correct players do not follow distinct protocols, so this specification describes correct behavior with respect to a single, implicit player. When the protocol must describe a player distinct from the implicit player (for example, a message that originated from another player), the protocol will use subscripts to distinguish different players. Subscripts are omitted when the player is unambiguous. For instance, a player might be associated with some “address” \( I \); if this player is the \( k \)-th player in the protocol, then this address may also be denoted \( I_k \).

This specification will describe certain objects as opaque. This document does not specify the exact implementation of opaque objects, but it does specify the subset of properties required for any implementation of some opaque object.

Opaque data definitions and semantics may be specified in other documents, which this document will cite when available.

All integers described in this document are unsigned, with a maximum value of \( 2^{64}-1 \), unless otherwise noted.

Context Tuple

The Algorand protocol’s progress is described using a context tuple \( (r, p, s) \), which identifies the current state within the Agreement protocol’s state machine.

• \( r \) (round): Indicates the current round of the protocol. It increases monotonically and corresponds to the block being committed. It is driven by protocol threshold events.

• \( p \) (period): Indicates the attempt number for reaching agreement in the current round¹. It is typically zero. A non-zero value reflects recovery from a failed commitment attempt. It is driven by protocol threshold events.

• \( s \) (step): Enumerates the stages of the Agreement protocol within a given period. It is driven by protocol time events.

1. The protocol defined in the original research papers was based just on a rounds and steps \( (r, s) \) state machine and on a Binary Byzantine Agreement, named \( \BBA \), that could lead to the proposal of a block or an empty block for a given round. The notion of period (i.e., new consensus attempt for the same round) replaces the outcome of \( \BBA \) over an empty block for a round. ↩

$$ \newcommand \FilterTimeout {\mathrm{FilterTimeout}} \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} $$

Parameters

The Algorand protocol is parameterized by the following constants:

Time Constants

These values represent durations of time.

Round Constants

These are positive integers that represent an amount of protocol rounds.

For convenience, we define:

• \( \delta_b = 2\delta_s\delta_r \) (the “balance lookback”).

Timeouts

We define \( \FilterTimeout(p) \) on a period \( p \) as follows:

• If \( p = 0 \) the \( \FilterTimeout(p) \) is calculated dynamically based on the lower 95th percentile of the observed lowest credentials per round arrival time:

  • \( 2\lambda_{0min} \leq \FilterTimeout(p) \leq 2\lambda_{0max} \)

Refer to the non-normative section for details about the implementation of the dynamic filtering mechanism.

• If \( p \ne 0 \):

  • \( \FilterTimeout(p) = 2\lambda \).

We define \( \DeadlineTimeout(p) \) on period \( p \) as follows:

• If \( p = 0 \):

  • \( \DeadlineTimeout(p) = \Lambda_0 \)

• If \( p \ne 0 \):

  • \( \DeadlineTimeout(p) = \Lambda \)

⚙️ IMPLEMENTATION

\( \DeadlineTimeout \) reference implementation.

$$ \newcommand \pk {\mathrm{pk}} \newcommand \sk {\mathrm{sk}} \newcommand \fv {\text{first}} \newcommand \lv {\text{last}} \newcommand \Sign {\mathrm{Sign}} \newcommand \Verify {\mathrm{Verify}} \newcommand \Rand {\mathrm{Rand}} $$

Identity, Authorization, and Authentication

A player is uniquely identified by a 256-bit string \( I \) called an address.

Each player owns exactly one participation keypair. A participation keypair consists of a public key \( \pk \) and a secret key \( \sk \).

A keypair is defined in the specification of participation keys in Algorand. Each participation keypair is valid for a range of protocol rounds \( [r_\fv, r_\lv] \).

Let \( m \), \( m’ \) be arbitrary sequences of bits.

Let \( B_k \), \( \bar{B} \) be 64-bit integers representing balances in μALGO with rewards applied.

Let \( \tau \), \( \bar{\tau} \) be 32-bit integers, and \( Q \) be a 256-bit string.

Let \( (\pk_k, \sk_k) \) be some valid keypair.

A secret key supports a signing procedure

$$ y := \Sign(m, m’, sk_k, B_k, \bar{B}, Q, \tau, \bar{\tau}) $$

Where \( y \) is opaque and cryptographically resistant to tampering, where defined.

Signing is not defined on many inputs: for any given input, signing may fail to produce an output.

The following functions are defined on \( y \):

• Verifying: \( \Verify(y, m, m’, \pk_k, B_k, \bar{B}, Q, \tau, \bar{\tau}) = w \) where \( w \) is a 64-bit integer called the weight of \( y \). \( w \neq 0 \) if and only if \( y \) was produced by signing by \( \sk_k \) (up to cryptographic security). \( w \) is uniquely determined given fixed values of \( m’, \pk_k, B_k, \bar{B}, Q, \tau, \bar{\tau} \).

• Comparing: Fixing the inputs \( m’, \bar{B}, Q, \tau, \bar{\tau} \) to a signing operation, there exists a total ordering on the outputs \( y \). In other words, if \( f(\sk, B) = \Sign(m, m’, \sk, B, \bar{B}, Q, \tau, \bar{\tau}) = y \), and \( S = \{(\sk_0, B_0), (\sk_1, B_1), \ldots, (\sk_n, B_n)\} \), then \( \{f(x) | x \in S\} \) is a totally ordered set. We write that \( y_1 < y_2 \) if \( y_1 \) comes before \( y_2 \) in this ordering.

• Generating Randomness: Let \( y \) be a valid output of a signing operation with \( \sk_k \). Then \( R = \Rand(y, \pk_k) \) is defined to be a pseudorandom 256-bit integer (up to cryptographic security). \( R \) is uniquely determined given fixed values of \( m’, \pk_k, B_k, \bar{B}, Q, \tau, \bar{\tau} \).

The signing procedure is allowed to produce a nondeterministic output, but the functions above must be well-defined with respect to a given input to the signing procedure (e.g., a procedure that implements \( \Verify(\Sign(\ldots)) \) always returns the same value).

$$ \newcommand \pk {\mathrm{pk}} \newcommand \fv {\text{first}} \newcommand \lv {\text{last}} \newcommand \Digest {\mathrm{Digest}} \newcommand \Encoding {\mathrm{Encoding}} \newcommand \Seed {\mathrm{Seed}} \newcommand \Record {\mathrm{Record}} \newcommand \DigestLookup {\mathrm{DigestLookup}} \newcommand \Stake {\mathrm{Stake}} \newcommand \Entry {\mathrm{Entry}} \newcommand \ValidEntry {\mathrm{ValidEntry}} \newcommand \Kcal {\mathcal{K}} $$

The Ledger of Entries

An entry is a pair \( e = (o, Q) \) where \( o \) is some opaque object, and \( Q \) is a 256-bit integer called a seed.

For a detailed definition of this object, see the Algorand Ledger Specification.

The following functions are defined on \( e \):

• Encoding: \( \Encoding(e) = x \) where \( x \) is a variable-length bitstring.

• Summarizing: \( \Digest(e) = h \) where \( h \) is a 256-bit integer. \( h \) should be a cryptographic commitment to the contents of \( e \).

A ledger is a sequence of entries \( L = (e_1, e_2, \ldots, e_n) \).

A round \( r \) is some 64-bit index into this sequence.

The following functions are defined on \( L \):

• Validating: \( ValidEntry(L, o) = 1 \) if and only if \( o \) is valid with respect to \( L \). This validity property is opaque.

• Seed Lookup: If \( e_r = (o_r, Q_r) \), then \( \Seed(L, r) = Q_r \).

• Record Lookup: \( \Record(L, r, I_k) = (\pk_{k,r}, B_{k,r}, r_\fv, r_\lv) \) for some address \( I_k \), some public key \( \pk_{k,r} \), and some 64-bit integer \( B_{k,r} \). \( r_\fv \) and \( r_\lv \) define the first valid and last valid rounds for this participating account.

• Digest Lookup: \( \DigestLookup(L, r) = \Digest(e_r) \).

• Total Stake Lookup: We use \( \Kcal_{r_b,r_v} \) to represent all players with participation keys at \( r_b \) that are eligible to vote at \( r_v \). Let \( \Kcal_{r_b,r_v} \) be the set of all \( k \) for which \( (\pk_{k,r_b}, B_{k,r_b}, r_\fv, r_\lv) = \Record(L, r_b, I_k) \) and \( r_\fv \leq r_v \leq r_\lv \) holds. Then \( \Stake(L, r_b, r_v) = \sum_{k \in \Kcal_{r_b,r_v}} B_{k,r_b} \).

A ledger may support an opaque entry generation procedure:

$$ o := \Entry(L, Q) $$

which produces an object \( o \) for which \( \ValidEntry(L, o) = 1 \).

For implementation details on this procedure, see the block assembly section in the Algorand Ledger non-normative specification.

Messages

Players communicate with each other by exchanging messages.

A message is an opaque object containing arbitrary data, save for the fields defined below.

For a detailed overview of message composition, whether consensus or other types, see the Algorand Network Overview.

$$ \newcommand \Propose {\mathit{propose}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} \newcommand \Next {\mathit{next}} \newcommand \CommitteeSize {\mathrm{CommitteeSize}} \newcommand \CommitteeThreshold {\mathrm{CommitteeThreshold}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \Digest {\mathrm{Digest}} \newcommand \Encoding {\mathrm{Encoding}} \newcommand \Hash {\mathrm{Hash}} $$

Elementary Data Types

A period \( p \) is a 64-bit integer.

A step \( s \) is an 8-bit integer.

Steps are named for clarity and are defined as follows:

The following functions are defined on \( s \):

• \( \CommitteeSize(s) \) is a 64-bit integer defined as follows:

$$ \CommitteeSize(s) = \left\{ \begin{array}{rl} 20 & : s = \Propose \\ 2990 & : s = \Soft \\ 1500 & : s = \Cert \\ 500 & : s = \Late \\ 2400 & : s = \Redo \\ 6000 & : s = \Down \\ 5000 & : \text{otherwise} \end{array} \right. $$

• \( \CommitteeThreshold(s) \) is a 64-bit integer defined as follows:

$$ \CommitteeThreshold(s) = \left\{ \begin{array}{rl} 0 & : s = \Propose \\ 2267 & : s = \Soft \\ 1112 & : s = \Cert \\ 320 & : s = \Late \\ 1768 & : s = \Redo \\ 4560 & : s = \Down \\ 3838 & : \text{otherwise} \end{array} \right. $$

A proposal-value is a tuple \( v = (I, p, \Digest(e), \Hash(\Encoding(e))) \) where:

• \( I \) is an address (the “original proposer”),

• \( p \) is a period (the “original period”),

• \( \Hash \) is some cryptographic hash function.

The special proposal-value where all fields are the zero-string is called the bottom proposal \( \bot \).

$$ \newcommand \pk {\mathrm{pk}} \newcommand \sk {\mathrm{sk}} \newcommand \fv {\text{first}} \newcommand \lv {\text{last}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Equivocation {\mathrm{Equivocation}} \newcommand \Propose {\mathit{propose}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} \newcommand \Seed {\mathrm{Seed}} \newcommand \Record {\mathrm{Record}} \newcommand \Stake {\mathrm{Stake}} \newcommand \CommitteeSize {\mathrm{CommitteeSize}} \newcommand \CommitteeThreshold {\mathrm{CommitteeThreshold}} \newcommand \Sign {\mathrm{Sign}} \newcommand \Verify {\mathrm{Verify}} \newcommand \abs[1] {\lvert #1 \rvert} $$

Votes

Let

• \( I \) be an address,

• \( r \) be a round,

• \( p \) be a period,

• \( s \) be a step,

• \( v \) be a proposal-value.

Let \( x \) be a canonical encoding of the 5-tuple \( (I, r, p, s, v) \), and let \( x’ \) be a canonical encoding of the 4-tuple \( (I, r, p, s) \).

Let \( y \) be an arbitrary bitstring.

Then we say that the tuple

$$ (I, r, p, s, v, y) $$

is a vote from \( I \) for \( v \) at round \( r \), period \( p \), step \( s \) (or a vote from \( I \) for \( v \) at \( (r, p, s) \)), denoted

$$ \Vote(I, r, p, s, v) $$

⚙️ IMPLEMENTATION

Vote reference implementation.

Moreover, let \( L \) be a ledger where \( \abs{L} \geq \delta_b \).

Let

• \( (\sk, \pk) \) be a keypair,
• \( B, \bar{B} \) be 64-bit integers,
• \( Q \) be a 256-bit integer,
• \( \tau, \bar{\tau} \) 32-bit integers.

We say that this vote is valid with respect to \( L \) (or simply valid if \( L \) is unambiguous) if the following conditions are true:

⚙️ IMPLEMENTATION

The reference implementation builds an asynchronous vote verifier, which builds a verification pool and under the hood uses two different verifying routines: one for regular unauthenticated votes, and one for unauthenticated equivocation votes.

See the non-normative Algorand ABFT Overview for further details.

• \( r \leq |L| + 2 \)

• Let \( v = (I_{orig}, p_{orig}, d, h )\).

  • If \( s = 0 \), then \( p_{orig} \le p \).
  • Furthermore, if \( s = 0 \) and \( p = p_{orig} \), then \( I = I_{orig} \).

• If \( s \in \{ \Propose, \Soft, \Cert, \Late, \Redo\} \), \( v \neq \bot \). Conversely, if \( s = \Down \), \( v = \bot \).

• Let

  • \( (\pk, B, r_\fv, r_\lv) = \Record(L, r - \delta_b, I) \),
  • \( \bar{B} = \Stake(L, r - \delta_b, r) \),
  • \( Q = \Seed(L, r - \delta_s) \),
  • \( \tau = \CommitteeThreshold(s) \),
  • \( \bar{\tau} = \CommitteeSize(s) \).

  Then

  • \( \Verify(y, x, x’, \pk, B, \bar{B}, Q, \tau, \bar{\tau}) \neq 0 \),
  • \( r_\fv \leq r \leq r_\lv \).

Observe that valid votes contain outputs of the \( \Sign \) procedure; i.e., \( y := \Sign(x, x’, \sk, B, \bar{B}, Q, \tau, \bar{\tau}) \).

Informally, these conditions check the following:

• The vote is not too far in the future for \( L \) to be able to validate.

• “Propose”-step votes can either propose a new proposal-value for this period (\( p_{orig} = p \)) or claim to “re-propose” a value originally proposed in an earlier period (\( p_{orig} < p \)). But they can’t claim to “re-propose” a value from a future period. And if the proposal-value is new (\( p_{orig} = p \)) then the “original proposer” must be the voter.

• The \( \Propose \), \( \Soft \), \( \Cert \), \( \Late \), and \( \Redo \) steps must vote for an actual proposal. The \( \Down \) step must only vote for \( \bot \).

• The last condition checks that the vote was properly signed by a voter who was selected to serve on the committee for this round, period, and step. The committee selection process uses the voter’s stake and keys as of \( \delta_b \) rounds before the vote and the seed as of \(\delta_s\) rounds before the vote. It also checks if the vote’s round is within the range associated with the voter’s participation key.

An equivocation vote pair or equivocation vote \( \Equivocation(I, r, p, s) \) is a pair of votes that differ in their proposal values. In other words,

$$ \begin{aligned} \Equivocation(I, r, p, s) = (&\Vote(I, r, p, s, v_1), \\ &\Vote(I, r, p, s, v_2)) \end{aligned} $$

for some \( v_1 \neq v_2 \).

An equivocation vote pair is valid with respect to \( L \) (or simply valid if \( L \) is unambiguous) if both of its constituent votes are also valid with respect to \( L \).

$$ \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Propose {\mathit{propose}} \newcommand \CommitteeThreshold {\mathrm{CommitteeThreshold}} \newcommand \abs[1] {\lvert #1 \rvert} $$

Bundles

Let \( V \) be any set of votes and equivocation votes.

We say that \( V \) is a bundle for \( v \) in round \( r \), period \( p \), and step \( s \) (or a bundle for \( v \) at \( (r, p, s) \)), denoted \( \Bundle(r, p, s, v) \).

⚙️ IMPLEMENTATION

Bundle reference implementation.

Moreover, let \( L \) be a ledger where \( \abs{L} \geq \delta_b \).

We say that this bundle is valid with respect to \( L \) (or simply valid if \( L \) is unambiguous) if the following conditions are true:

⚙️ IMPLEMENTATION

The reference implementation makes use of an asynchronous Bundle verifying function.

See the non-normative Algorand ABFT Overview for further details.

• Every element \( a_i \in V \) is valid with respect to \( L \).

• For any two elements \( a_i, a_j \in V \), \( I_i \neq I_j \).

• For any element \( a_i \in V \), \( r_i = r, p_i = p, s_i = s \).

• For any element \( a_i \in V \), either \( a_i \) is a vote and \( v_i = v \), or \( a_i \) is an equivocation vote.

• Let \( w_i \) be the weight of the signature in \( a_i \). Then \( \sum_i w_i \geq \CommitteeThreshold(s) \).

$$ \newcommand \pk {\mathrm{pk}} \newcommand \fv {\text{first}} \newcommand \lv {\text{last}} \newcommand \Sign {\mathrm{Sign}} \newcommand \ValidEntry {\mathrm{ValidEntry}} \newcommand \Hash {\mathrm{Hash}} \newcommand \Digest {\mathrm{Digest}} \newcommand \Encoding {\mathrm{Encoding}} \newcommand \Record {\mathrm{Record}} \newcommand \Verify {\mathrm{Verify}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \abs[1] {\lvert #1 \rvert} $$

Proposals

Let \( e = (o, s) \) be an entry and \( y \) be the output of a \( \Sign \) procedure.

The pair \( (e, y) \) is a proposal or a proposal payload.

Moreover, let

• \( L \) be a ledger where \( \abs{L} \geq \delta_b \),

• \( v = (I, p, h, x) \) be some proposal-value.

We say that this proposal is a valid proposal matching \( v \) with respect to \( L \) (or simply that this proposal matches \( v \) if \( L \) is unambiguous) if the following conditions are true:

• \( \ValidEntry(L, e) = 1 \),

• \( h = \Digest(e) \),

• \( x = \Hash(\Encoding(e)) \),

• The seed \( s \) and seed proof are valid as specified in the following section,

• Let \( (\pk, B, r_\fv, r_\lv) = \Record(L, r - \delta_b, I) \),

  • If \( p = 0 \), then \( \Verify(y, Q_0, Q_0, \pk, 0, 0, 0, 0, 0) \neq 0 \),

• Let \( (\pk, B, r_\fv, r_\lv) = \Record(L, r - \delta_b, I) \). Then \( r_\fv \leq r \leq r_\lv \).

If \( e \) matches \( v \), we write \( e = \Proposal(v) \).

$$ \newcommand \VRF {\mathrm{VRF}} \newcommand \Prove {\mathrm{Prove}} \newcommand \ProofToHash {\mathrm{ProofToHash}} \newcommand \Verify {\mathrm{Verify}} \newcommand \pk {\mathrm{pk}} \newcommand \sk {\mathrm{sk}} \newcommand \fv {\text{first}} \newcommand \lv {\text{last}} \newcommand \Record {\mathrm{Record}} \newcommand \Seed {\mathrm{Seed}} \newcommand \Hash {\mathrm{Hash}} \newcommand \DigestLookup {\mathrm{DigestLookup}} $$

Seed

Informally, the protocol interleaves \( \delta_s \) seeds in an alternating sequence. Each seed is derived from a seed \( \delta_s \) rounds in the past through either a hash function or through a \( \VRF \), keyed on the entry proposer. Additionally, every \( \delta_s\delta_r \) rounds, the digest of a previous entry (specifically, from round \( r-\delta_s\delta_r \)) is hashed into the result. The seed proof is the corresponding VRF proof, or 0 if the \( \VRF \) was not used.

More formally, suppose \( I \) is a correct proposer in round \( r \) and period \( p \).

Let

• \( (\pk, B, r_\fv, r_\lv) = \Record(L, r - \delta_b, I) \),

• \( \sk \) be the secret key corresponding to \( \pk \),

• \( \alpha \) be a 256-bit integer.

Then \( I \) computes the seed proof \( y \) for a new entry as follows:

• If \( p = 0 \):

  • \( y = \VRF.\Prove(\Seed(L, r-\delta_s), \sk) \),
  • \( \alpha = \Hash(\VRF.\ProofToHash(y), I) \).

• If \( p \ne 0 \):

  • \( y = 0 \),
  • \( \alpha = \Hash(\Seed(L, r-\delta_s)) \).

Now \( I \) computes the seed \( Q \) as follows:

$$ Q = \left\{ \begin{array}{rl} H(\alpha, \DigestLookup(L, r-\delta_s\delta_r)) & : (r \bmod \delta_s\delta_r) < \delta_s \\ H(\alpha) & : \text{otherwise} \end{array} \right. $$

⚙️ IMPLEMENTATION

Seed computation reference implementation.

The seed is valid if the following verification procedure succeeds:

1. Let \( (\pk, B, r_\fv, r_\lv) = \Record(L, r-\delta_b, I) \); let \( q_0 = \Seed(L, r-\delta_s) \).

2. If \( p = 0 \), check \( \VRF.\Verify(y, q_0, \pk) \), immediately returning failure if verification fails. Let \( q_1 = \Hash(\VRF.\ProofToHash(y), I) \) and continue to step 4.

3. If \( p \ne 0 \), let \( q_1 = \Hash(q_0) \). Continue.

4. If \( r \equiv (r \bmod \delta_s) \mod \delta_r\delta_s \), then check \( Q = \Hash(q_1||\DigestLookup(L, r-\delta_s\delta_r)) \). Otherwise, check \( Q = q_1 \).

Round \( r \) leader selection and committee selection both use the seed from \( r-\delta_s \) and the balances / public keys from \( r-\delta_b \).

For re-proposals, the period \( p \) used in this section is the original period, not the reproposal period.

For a detailed overview of the seed computation algorithm and some explanatory examples, refer to the Algorand ABFT non-normative specification.

$$ \newcommand \Vote {\mathrm{Vote}} $$

State Machine

This specification defines the Algorand agreement protocol as a state machine. The input to the state machine is some serialization of events, which in turn results in some serialization of network transmissions from the state machine.

We can define the operation of the state machine as transitions between different states.

A transition \( N \) maps some initial state \( S_0 \), a ledger \( L_0 \), and an event \( e \) to an output state \( S_1 \), an output ledger \( L_1 \), and a sequence of output network transmissions \( \mathbf{a} = (a_1, a_2, \ldots, a_n) \).

We write this as

$$ N(S_0, L_0, e) = (S_1, L_1, \mathbf{a}) $$

If no transmissions are output, we write that \( \mathbf{a} = \epsilon \).

Events

The state machine receives two types of events as inputs.

1. message events: A message event is received when a vote, a proposal, or a bundle is received. A message event is simply written as the message that is received.

2. timeout events: A timeout event is received when a specific amount of time passes after the beginning of a period. A timeout event \( \lambda \) seconds after a period \( p \) begins is denoted \( t(\lambda, p) \).

For more details on the way these events may be constructed from an implementation point of view, refer to the non-normative Algorand ABFT Overview.

Outputs

The state machine produces a series of network transmissions as output. In each transmission, the player broadcasts a vote, a proposal, or a bundle to the rest of the network.

A player may perform a special broadcast called a relay. In a relay, the data received from another peer is broadcast to all peers except for the sender.

A broadcast action is simply written as the message to be transmitted. A relay action is written as the same message except with an asterisk. For instance, an action to relay a vote is written as \( \Vote^\ast(r, p, s, v) \).

For implementation details on relay and broadcasting actions, refer to the non-normative Algorand Network Overview.

$$ \newcommand \Vote {\mathrm{Vote}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Priority {\mathrm{Priority}} \newcommand \VRF {\mathrm{VRF}} \newcommand \ProofToHash {\mathrm{ProofToHash}} \newcommand \Hash {\mathrm{Hash}} $$

Player State Definition

We define the player state \( S \) to be the following tuple:

$$ S = (r, p, s, \bar{s}, V, P, \bar{v}) $$

where

• \( r \) is the current round,
• \( p \) is the current period,
• \( s \) is the current step,
• \( \bar{s} \) is the last concluding step,
• \( V \) is the set of all votes,
• \( P \) is the set of all proposals, and
• \( \bar{v} \) is the pinned value.

We say that a player has observed

• \( \Proposal(v) \) if \( \Proposal(v) \in P \),
• \( \Vote(r, p, s, v) \) if \( \Vote(r, p, s, v) \in V \),
• \( \Bundle(r, p, s, v) \) if \( \Bundle(r, p, s, v) \subset V \),
• That the round \( r \) (period \( p = 0 \)) has begun if there exists some \( p \) such that \( \Bundle(r-1, p, \Cert, v) \) was also observed for some \( v \),
• That the round \( r \), period \( p > 0 \) has begun if there exists some \( p \) such that either
  • \( \Bundle(r, p-1, s, v) \) was also observed for some \( s > \Cert, v \), or
  • \( \Bundle(r, p, \Soft, v) \) was observed for some \( v \).

An event causes a player to observe something if the player has not observed that thing before receiving the event and has observed that thing after receiving the event. For instance, a player may observe a vote \( \Vote \), which adds this vote to \( V \):

$$ N((r, p, s, \bar{s}, V, P, \bar{v}), L_0, \Vote) = ((r’, p’, \ldots, V \cup \{\Vote\}, P, \bar{v}’), L_1, \ldots) $$

We abbreviate the transition above as

$$ N((r, p, s, \bar{s}, V, P, \bar{v}), L_0, \Vote) = ((S \cup \Vote, P, \bar{v}), L_1, \ldots) $$

Note that observing a message is distinct from receiving a message. A message which has been received might not be observed (for instance, the message may be from an old round). Refer to the relay rules for details.

Special Values

We define two functions \( \mu(S, r, p), \sigma(S, r, p) \), which are defined as follows:

The frozen value \( \mu(S, r, p) \) is defined as the proposal-value \( v \) in the proposal vote in round \( r \) and period \( p \) with the minimal credential.

More formally, then, let

$$ V_{r, p, 0} = \{\Vote(I, r, p, 0, v) | \Vote \in V\} $$

where \( V \) is the set of votes in \( S \).

Then if \( \Vote_l(r, p, 0, v_l) \) is the vote with the smallest weight in \( V_{r, p} \), then \( \mu(S, r, p) = v_l \).

If \( V_{r, p} \) is empty, then \( \mu(S, r, p) = \bot \).

The staged value \( \sigma(S, r, p) \) is defined as the sole proposal-value for which there exists a soft-bundle in round \( r \) and period \( p \).

More formally, suppose \( \Bundle(r, p, Soft, v) \subset V \). Then \( \sigma(S, r, p) = v \).

If no such soft-bundle exists, then \( \sigma(S, r, p) = \bot \).

If there exists a proposal-value \( v \) such that \( \Proposal(v) \in P \) and \( \sigma(S, r, p) = v \), we say that \( v \) is committable for round \( r \), period \( p \) (or simply that \( v \) is committable if \( (r, p) \) is unambiguous).

⚙️ IMPLEMENTATION

The current implementation constructs a Proposal Tracker which, amongst other things, is in charge of handling both frozen and staged value tracking.

Relay Rules

Here we describe how players handle message events.

Whenever the player receives a message event, it may decide to relay that or another message. In this case, the player will produce that output before producing any subsequent output (which may result from the player’s observation of that message; see the broadcast rules below).

A player may receive messages from a misbehaving peer. These cases are marked with an asterisk (*) and enable the node to perform a special action (e.g., disconnect from the peer).

For examples of what these special actions may involve, see the non-normative Algorand Network Overview.

We say that a player ignores a message if it produces no outputs on receiving that message.

$$ \newcommand \Vote {\mathrm{Vote}} \newcommand \Late {\mathit{late}} \newcommand \Down {\mathit{down}} \newcommand \Next {\mathit{next}} $$

Votes

On receiving a vote \( \Vote_k(r_k, p_k, s_k, v) \) a player

• Ignores* it if \( \Vote_k \) is malformed or trivially invalid.

• Ignores it if \( s = 0 \) and \( \Vote_k \in V \).

• Ignores it if \( s = 0 \) and \( \Vote_k \) is an equivocation.

• Ignores it if \( s > 0 \) and \( \Vote_k \) is a second equivocation.

• Ignores it if

  • \( r_k \notin [r,r+1] \) or

  • \( r_k = r + 1 \) and either

    • \( p_k > 0 \) or
    • \( s_k \in (\Next_0, \Late) \) or

  • \( r_k = r \) and one of

    • \( p_k \notin [p-1,p+1] \) or
    • \( p_k = p + 1 \) and \( s_k \in (\Next_0, \Late) \) or
    • \( p_k = p \) and \( s_k \in (\Next_0, \Late) \) and \( s_k \notin [s-1,s+1] \) or
    • \( p_k = p - 1 \) and \( s_k \in (\Next_0, \Late) \) and \( s_k \notin [\bar{s}-1,\bar{s}+1] \).

• Otherwise, relays \( \Vote_k \), observes it, and then produces any consequent output.

Specifically, if a player ignores the vote, then

$$ N(S, L, \Vote_k(r_k, p_k, s_k, v)) = (S, L, \epsilon) $$

while if a player relays the vote, then

$$ N(S, L, \Vote_k(r_k, p_k, s_k, v)) = (S’ \cup \Vote(I, r_k, p_k, s_k, v), L’, (\Vote_k^\ast(r_k, p_k, s_k, v),\ldots)). $$

$$ \newcommand \Bundle {\mathrm{Bundle}} $$

Bundles

On receiving a bundle \( \Bundle(r_k, p_k, s_k, v) \) a player

• Ignores* it if \( Bundle(r_k, p_k, s_k, v) \) is malformed or trivially invalid.

• Ignores it if

  • \( r_k \neq r \) or
  • \( r_k = r \) and \( p_k + 1 < p \).

• Otherwise, observes the votes in \( \Bundle(r_k, p_k, s_k, v) \) in sequence. If there exists a vote that causes the player to observe some bundle \( \Bundle(r_k, p_k, s_k, v’) \) for some \( s_k \), then the player relays \( \Bundle(r_k, p_k, s_k, v’) \), and then executes any consequent action; if there does not, the player ignores it.

Specifically, if the player ignores the bundle without observing its votes, then

$$ N(S, L, \Bundle(r_k, p_k, s_k, v)) = (S, L, \epsilon); $$

while if a player ignores the bundle but observes its votes, then

$$ N(S, L, \Bundle(r_k, p_k, s_k, v)) = (S’ \cup \Bundle(r_k, p_k, s_k, v), L, \epsilon); $$

and if a player, on observing the votes in the bundle, observes a bundle for some value (not necessarily distinct from the bundle’s value), then

$$ N(S, L, \Bundle(r_k, p_k, s_k, v)) = (S’ \cup \Bundle(r_k, p_k, s_k, v), L’, (\Bundle^\ast(r_, p_k, s_k, v’), \ldots)). $$

$$ \newcommand \Proposal {\mathrm{Proposal}} $$

Proposals

On receiving a proposal \( \Proposal(v) \) a player

• Relays \( \Proposal(v) \) if \( \sigma(S, r+1, 0) = v \).

• Ignores* it if it is malformed or trivially invalid.

• Ignores it if \( \Proposal(v) \in P \).

• Relays \( \Proposal(v) \), observes it, and then produces any consequent output, if \( v \in \{\sigma(S, r, p), \bar{v}, \mu(S, r, p)\} \).

• Otherwise, ignores it.

Specifically, if the player ignores a proposal, then

$$ N(S, L, \Proposal(v)) = (S, L, \epsilon) $$

while if a player relays the proposal after checking if it is valid, then

$$ N(S, L, \Proposal(v)) = (S’ \cup \Proposal(v), L’, (\Proposal^\ast(v), \ldots)). $$

However, in the first condition above, the player relays \( \Proposal(v) \) without checking if it is valid.

Since the proposal has not been seen to be valid, the player cannot observe it yet, so

$$ N(S, L, \Proposal(v)) = (S, L, (\Proposal^\ast(v))). $$

An implementation may buffer a proposal in this case. Specifically, an implementation which relays a proposal without checking that it is valid, may optionally choose to replay this event when it observes that a new round has begun (see State Transition section). In this case, at the conclusion of a new round, this proposal is processed once again as input.

Implementations MAY store and relay fewer proposals than specified here to improve efficiency. However, implementations MUST relay proposals which match the following proposal-values (where \( r \) is the current round and \( p \) is the current period):

• \( \bar{v} \),

• \( \sigma(S, r, p), \sigma(S, r, p-1) \),

• \( \mu(S, r, p) \) if \( \sigma(S, r, p) \) is not set and \( \mu(S, r, p+1) \) if \( \sigma(S, r, p+1) \) is not set.

State Transitions

After receiving message events or a time events, the player may update some components of its state.

New Round

When a player observes that a new round \( (r, 0) \) has begun, the player sets

• \( \bar{s} := s \),

• \( \bar{v} := \bot \),

• \( p := 0 \),

• \( s := 0 \).

Specifically, if a new round has begun, then

$$ N((r-i, p, s, \bar{s}, V, P, \bar{v}), L, \ldots) = ((r, 0, 0, s, V’, P’, \bot), L’, \ldots) $$

for some \( i > 0 \).

⚙️ IMPLEMENTATION

New round reference implementation.

$$ \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Bundle {\mathrm{Bundle}} $$

New Period

When a player observes that a new period \( (r, p) \) has begun, the player sets

• \( \bar{s} := s \),

• \( s := 0 \).

Also, the player sets \( \bar{v} := v \) if the player has observed \( \Bundle(r, p-1, s, v) \) given some values \( s > \Cert \) (or \( s = \Soft \)), \( v \neq \bot \); if none exist, the player sets \( \bar{v} := \sigma(S, r, p-i) \) if it exists, where \( p-i \) was the player’s period immediately before observing the new period; and if none exist, the player does not update \( \bar{v} \).

In other words, if \( \Bundle(r, p-1, s, v) \in V’ \) for some \( v \neq \bot, s > \Cert \) or \( s = \Soft \), then

$$ N((r, p-i, s, \bar{s}, V, P, \bar{v}), L, \ldots) = ((r, p, 0, s, V’, P, v), L’, \ldots); $$

and otherwise, if \( \Bundle(r, p-1, s, \bot) \in V’ \) for some \( s > \Cert \) with \( \sigma(S, r, p-i) \) defined, then

$$ N((r, p-i, s, \bar{s}, V, P, \bar{v}), L, \ldots) = ((r, p, 0, s, V’, P, \sigma(S, r, p-i)), L’, \ldots); $$

and otherwise

$$ N((r, p-i, s, \bar{s}, V, P, \bar{v}), L, \ldots) = ((r, p, 0, s, V’, P, \bar{v}), L’, \ldots); $$

for some \( i > 0 \) (where \( S = (r, p-i, s, \bar{s}, V, P, \bar{v}) \)).

⚙️ IMPLEMENTATION

New period reference implementation.

$$ \newcommand \Vote {\mathrm{Vote}} $$

Garbage Collection

When a player observes that either a new round or a new period \( (r, p) \) has begun, then the player garbage-collects old state.

In other words,

$$ N((r-i, p-i, s, \bar{s}, V, P, \bar{v}), L, \ldots) = ((r, p, \bar{s}, 0, V’ \setminus V^\ast_{r, p}, P’ \setminus P^\ast_{r, p}, \bar{v}), L, \ldots) $$

where

$$ \begin{aligned} V^\ast_{r, p} &= \{\Vote(I, r’, p’, \bar{s}, v) | \Vote \in V, r’ < r\} \\\ &\cup \{\Vote(I, r’, p’, \bar{s}, v) | \Vote \in V, r’ = r, p’ + 1 < p\} \end{aligned} $$

and \( P^\ast_{r, p} \) is defined similarly.

$$ \newcommand \FilterTimeout {\mathrm{FilterTimeout}} \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} $$

New Step

A player may also update its step after receiving a timeout event.

On observing a timeout event of \( \FilterTimeout(p) \) for a period \( p \), the player sets \( s := \Cert \).

On observing a timeout event of \( \DeadlineTimeout(p) \) for a period \( p \), the player sets \( s := \Next_0 \).

On observing a timeout event of \( \DeadlineTimeout(p) + 2^{s_t}\lambda + u \) where \( u \in [0, 2^{s_t}\lambda) \) sampled uniformly at random, the player sets \( s := s_t \).

⚙️ IMPLEMENTATION

New step reference implementation.

In other words,

$$ \begin{aligned} &N((r, p, s, \bar{s}, V, P, \bar{v}), L, t(\FilterTimeout(p), p)) &&= ((r, p, \Cert, \bar{s}, V, P, \bar{v}), L’, \ldots) \\
&N((r, p, s, \bar{s}, V, P, \bar{v}), L, t(\DeadlineTimeout(p), p)) &&= ((r, p, \Next_0, \bar{s}, V, P, \bar{v}), L’, \ldots) \\
&N((r, p, s, \bar{s}, V, P, \bar{v}), L, t(\DeadlineTimeout(p) + 2^{s_t}\lambda + u, p)) &&= ((r, p, \Next_{s_t}, \bar{s}, V, P, \bar{v}), L’, \ldots). \end{aligned} $$

$$ \newcommand \pk {\mathrm{pk}} \newcommand \sk {\mathrm{sk}} \newcommand \Vote {\mathrm{Vote}} \newcommand \fv {\text{first}} \newcommand \Record {\mathrm{Record}} \newcommand \lv {\text{last}} \newcommand \Stake {\mathrm{Stake}} \newcommand \Seed {\mathrm{Seed}} \newcommand \CommitteeThreshold {\mathrm{CommitteeThreshold}} \newcommand \CommitteeSize {\mathrm{CommitteeSize}} \newcommand \Sign {\mathrm{Sign}} $$

Broadcast Rules

Upon observing messages or receiving timeout events, the player state machine emits network outputs, which are externally visible. The player may also append an entry to the ledger.

A correct player emits only valid votes. Suppose the player is identified with the address \( I \) and possesses the secret key \( \sk \), and the agreement is occurring on the ledger \(L\). Then the player constructs a vote \( \Vote(I, r, p, s, v) \) by doing the following:

• Let

  • \(( \pk, B, r_\fv, r_\lv) = \Record(L, r - \delta_b, I) \),
  • \( \bar{B} = \Stake(L, r - \delta_b) \),
  • \( Q = \Seed(L, r - \delta_s) \),
  • \( \tau = \CommitteeThreshold(s) \),
  • \( \bar{\tau} = \CommitteeSize(s) \).

• Encode \( x := (I, r, p, s, v), x’ := (I, r, p, s) \).

• Try to set \( y := \Sign(x, x’, \sk, B, \bar{B}, Q, \tau, \bar{\tau}) \).

If the signing procedure succeeds, the player broadcasts \( Vote(I, r, p, s, v) = (I, r, p, s, v, y) \). Otherwise, the player does not broadcast anything.

For certain broadcast vote-messages specified here, a node is forbidden to equivocate (i.e., produce a pair of votes which contain the same round, period, and step but which vote for different proposal values). These messages are marked with an asterisk (*) below. To prevent accidental equivocation after a power failure, nodes SHOULD checkpoint their state to crash-safe storage before sending these messages.

For further details on these checkpoint strategies, refer to the non-normative Ledger specification. For an in-depth review of broadcasting functionalities, refer to the non-normative Network specification.

$$ \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Proposal {\mathrm{Proposal}} $$

Resynchronization Attempt

Where specified, a player attempts to resynchronize.

A resynchronization attempt involves the following stages.

First, the player broadcasts its freshest bundle, if one exists.

A player’s freshest bundle is a complete bundle defined as follows:

• \( \Bundle(r, p, \Soft, v) \subset V \) for some \( v \), if it exists, or else

• \( \Bundle(r, p-1, s, \bot) \subset V \) for some \( s > \Cert \), if it exists, or else

• \( \Bundle(r, p-1, s, v) \subset V \) for some \( s > \Cert, v \neq \bot \), if it exists.

⚙️ IMPLEMENTATION

Freshness relation reference implementation.

Second, if the player broadcasted a bundle \( \Bundle(r, p, s, v) \), and \( v \neq \bot \), then the player broadcasts \( \Proposal(v) \) if the player has it.

Specifically, a resynchronization attempt:

• Corresponds to no additional outputs if no freshest bundle exists

$$ N(S, L, \ldots) = (S’, L’, \ldots), $$

• Corresponds to a broadcast of the freshest bundle after a relay output and before any subsequent broadcast outputs, if said bundle exists, no matching proposal exists

$$ N(S, L, \ldots) = (S’, L’, (\ldots, \Bundle^\ast(r, p, s, v), \ldots)), $$

• Otherwise corresponds to a broadcast of both a bundle and its associated proposal after a relay output and before any subsequent broadcast outputs

$$ N(S, L, \ldots) = (S’, L’, (\ldots, \Bundle^\ast(r, p, s, v), \Proposal(v), \ldots)). $$

$$ \newcommand \pk {\mathrm{pk}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Cert {\mathit{cert}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Entry {\mathrm{Entry}} \newcommand \Seed {\mathrm{Seed}} \newcommand \Sign {\mathrm{Sign}} \newcommand \Rand {\mathrm{Rand}} \newcommand \Hash {\mathrm{Hash}} \newcommand \Digest {\mathrm{Digest}} \newcommand \Encoding {\mathrm{Encoding}} $$

Proposals

On observing that \( (r, p) \) has begun, the player attempts to resynchronize, and then

• if \( p = 0 \) or there exists some \( s > \Cert \) where \( \Bundle(r, p-1, s, \bot) \) was observed, then a player generates a new proposal \( (v’, \Proposal(v’)) \) and then broadcasts \( (\Vote(I, r, p, 0, v’), \Proposal(v’)) \).

• if \( p > 0 \) and there exists some \( s_0 > \Cert, v \) where \( \Bundle(r, p-1, s_0, v) \) was observed, while there exists no \( s_1 > \Cert \) where \( \Bundle(r, p-1, s_1, \bot) \) was observed, then the player broadcasts \( \Vote(I, r, p, 0, v) \). Moreover, if \( \Proposal(v) \in P \), the player then broadcasts \( \Proposal(v) \).

A player generates a new proposal by executing the entry-generation procedure and by setting the fields of the proposal accordingly. Specifically, the player creates a proposal payload \( ((o, s), y) \) by setting

• \( o := \Entry(L) \),

• \( Q := \Seed(L, r-1) \),

• \( y := \Sign(Q, Q, 0, 0, 0, 0, 0, 0) \),

• and \( s := \Rand(y, \pk)\) if \( p = 0 \) or \( s := \Hash(\Seed(L, r-1)) \) otherwise.

This consequently defines the matching proposal-value \( v = (I, p, \Digest(e), \Hash(\Encoding(e))) \).

For an in-depth overview of how proposal generation may be implemented, refer to the Algorand Ledger non-normative section.

In other words, if the player generates a new proposal,

$$ N(S, L, \ldots) = (S’, L’, (\ldots, \Vote(I, r, p, 0, v’), \Proposal(v’))), $$

while if the player broadcasts an old proposal,

$$ N(S, L, \ldots) = (S’, L’, (\ldots, \Vote(I, r, p-1, 0, v), \Proposal(v))) $$

if \( \Proposal(v) \in P \) and

$$ N(S, L, \ldots) = (S’, L’, (\ldots, \Vote(I, r, p-1, 0, v))) $$

otherwise.

$$ \newcommand \Vote {\mathrm{Vote}} \newcommand \Proposal {\mathrm{Proposal}} $$

Reproposal Payloads

On observing \( \Vote(I, r, p, 0, v) \), if \( \Proposal(v) \in P \) then the player broadcasts \( \Proposal(v) \).

In other words, if \( \Proposal(v) \in P \),

$$ N(S, L, \Vote(I, r, p, 0, v)) = (S’, L’, (\Proposal(v))). $$

$$ \newcommand \FilterTimeout {\mathrm{FilterTimeout}} \newcommand \Cert {\mathit{cert}} \newcommand \Soft {\mathit{soft}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} $$

Filtering

On observing a timeout event of \( \FilterTimeout(p) \) (where \( \mu = (H, H’, l, p_\mu) = \mu(S, r, p) \)),

• if \( \mu \neq \bot \) and if

  • \( p_\mu = p \) or
  • there exists some \( s > \Cert \) such that \( \Bundle(r, p-1, s, \mu) \) was observed then the player broadcasts \( \Vote(I, r, p, \Soft, \mu) \).

• if there exists some \( s_0 > \Cert \) such that \( \Bundle(r, p-1, s_0, \bar{v}) \) was observed and there exists no \( s_1 > \Cert \) such that \( \Bundle(r, p-1, s_1, \bot) \) was observed, then the player broadcasts* \( \Vote(I, r, p, \Soft, \bar{v}) \).

• otherwise, the player does nothing.

For a detailed overview of how the filtering step may be implemented, refer to the Algorand ABFT non-normative section.

In other words, in the first case above,

$$ N(S, L, t(\FilterTimeout(p), p)) = (S, L, \Vote(I, r, p, \Soft, \mu)); $$

while in the second case above,

$$ N(S, L, t(\FilterTimeout(p), p)) = (S, L, \Vote(I, r, p, \Soft, \bar{v})); $$

and if neither case is true,

$$ N(S, L, t(\FilterTimeout(p), p)) = (S, L, \epsilon). $$

$$ \newcommand \Cert {\mathit{cert}} \newcommand \Soft {\mathit{soft}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Proposal {\mathrm{Proposal}} $$

Certifying

On observing that some proposal-value \( v \) is committable for its current round \( r \), and some period \( p’ \geq p \) (its current period), if \( s \leq \Cert \), then the player broadcasts* \( \Vote(I, r, p, \Cert, v) \). (It can be shown that this occurs either after a proposal is received or a soft-vote, which can be part of a bundle, is received.)

For a detailed overview of how the certification step may be implemented, refer to the Algorand ABFT non-normative section.

In other words, if observing a soft-vote causes a proposal-value to become committable,

$$ N(S, L, \Vote(I, r, p, \Soft, v)) = (S’, L, (\ldots, \Vote(I, r, p, \Cert, v))); $$

while if observing a bundle causes a proposal-value to become committable,

$$ N(S, L, \Bundle(r, p, \Soft, v)) = (S’, L, (\ldots, \Vote(I, r, p, \Cert, v))); $$

and if observing a proposal causes a proposal-value to become committable,

$$ N(S, L, \Proposal(v)) = (S’, L, (\ldots, \Vote(I, r, p, \Cert, v))); $$

as long as \( s \leq \Cert \).

$$ \newcommand \Cert {\mathit{cert}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Proposal {\mathrm{Proposal}} $$

Commitment

On observing \( \Bundle(r, p, \Cert, v) \) for some value \( v \), the player commits the entry \( e \) corresponding to \( \Proposal(v) \); i.e., the player appends \( e \) to the sequence of entries on its ledger \( L \). (Evidently, this occurs either after a vote is received or after a bundle is received.)

For further details on how entry commitment may be implemented, refer to the Algorand Ledger non-normative section.

In other words, if observing a cert-vote causes the player to commit \( e \),

$$ N(S, L, \Vote(I, r, p, \Cert, v)) = (S’, L || e, \ldots)); $$

while if observing a bundle causes the player to commit \( e \),

$$ N(S, L, \Bundle(r, p, \Cert, v)) = (S’, L || e, \ldots)). $$

Occasionally, an implementation may not have \(e\) at the point \(e\) becomes committed. In this case, the implementation may wait until it receives \(e\) somehow (perhaps by requesting peers for \(e\)). Alternatively, the implementation may continue running the protocol until it receives \(e\). However, if the protocol chooses to continue running, it may not transmit any vote for which \(v \neq \bot\) until it has committed \(e\).

$$ \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} $$

Recovery

On observing a timeout event of

• \( T = \DeadlineTimeout(p) \) or

• \( T = \DeadlineTimeout(p) + 2^{s_t}\lambda + u \) where \( u \in [0, 2^{s_t}\lambda] \) sampled uniformly at random,

the player attempts to resynchronize and then broadcasts* \( \Vote(I, r, p, \Next_h, v) \) where

• \( v = \sigma(S, r, p) \) if \( v \) is committable in \( (r, p) \),

• \( v = \bar{v} \) if there does not exist a \( s_0 > \Cert \) such that \( \Bundle(r, p-1, s_0, \bot) \) was observed and there exists an \( s_1 > \Cert \) such that \( \Bundle(r, p-1, s_1, \bar{v} )\) was observed,

• and \( v = \bot \) otherwise.

⚙️ IMPLEMENTATION

Next vote issuance reference implementation.

Next vote timeout ranges computation reference implementation.

Call to \( \Next_0 \) reference implementation.

Subsequent calls to \( \Next_{st} \) reference implementation.

Step increase in recovery step timeouts reference implementation.

For a detailed overview of how the recovery routine may be implemented, refer to the Algorand ABFT non-normative section.

In other words, if a proposal-value \( v \) is committable in the current period,

$$ N(S, L, t(T, p)) = (S’, L, (\ldots, \Vote(I, r, p, \Next_h, v))); $$

while in the second case,

$$ N(S, L, t(T, p)) = (S’, L, (\ldots, \Vote(I, r, p, \Next_h, \bar{v}))); $$

and otherwise,

$$ N(S, L, t(T, p)) = (S’, L, (\ldots, \Vote(I, r, p, \Next_h, \bot))). $$

$$ \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Cert {\mathit{cert}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} $$

Fast Recovery

On observing a timeout event of \( T = k\lambda_f + u \) where \( k \) is a positive integer and \( u \in [0, \lambda_f] \) sampled uniformly at random, the player attempts to resynchronize. Then,

• The player broadcasts* \( \Vote(I, r, p, \Late, v) \) if \( v = \sigma(S, r, p) \) is committable in \( (r, p) \).

• The player broadcasts* \( \Vote(I, r, p, \Redo, \bar{v}) \) if there does not exist a \( s_0 > \Cert \) such that \( \Bundle(r, p-1, s_0, \bot) \) was observed and there exists an \( s_1 > \Cert \) such that \( \Bundle(r, p-1, s_1, \bar{v}) \) was observed.

• Otherwise, the player broadcasts* \( \Vote(I, r, p, \Down, \bot \).

Finally, the player broadcasts all \( \Vote(I, r, p, \Late, v) \in V\), all \( \Vote(I, r, p, \Redo, v) \in V\), and all \( \Vote(I, r, p, \Down, \bot) \in V \) that it has observed.

⚙️ IMPLEMENTATION

Fast recovery reference implementation.

For a detailed pseudocode overview of the fast recovery routine, along with protocol recovery run examples, refer to the Algorand ABFT non-normative section.

Agreement Protocol Overview

The following section is a non-normative overview of the Algorand Agreement Protocol.

We attempt to ease understanding of the normative section and provide readers with a comprehensive view of its inner workings, while maintaining technical correctness.

We provide pseudocode examples and diagrams for readers and potential implementers to clarify how these processes may be implemented, and how they might interact with one another.

For a normative specification of the Algorand Byzantine Fault Tolerance protocol, refer to the normative ABFT section.

$$ \newcommand \ABFT {\mathrm{ABFT}} \newcommand \Credentials {\mathrm{Credentials}} \newcommand \sk {\mathrm{sk}} \newcommand \VRF {\mathrm{VRF}} $$

General Concepts

The Algorand Agreement Protocol, or Algorand Byzantine Fault Tolerance (\( \ABFT \)), is a consensus mechanism ensuring secure, decentralized agreement on transactions’ ordering and validity in the Algorand blockchain. It tolerates malicious actors as long as less than one-third of the participants are compromised.

The protocol relies on a cryptographic sortition to randomly and verifiably self-select a small, representative group of participants to propose and validate blocks. This randomness ensures security, scalability, and resistance to attacks.

By achieving instant finality, \( \ABFT \) enables Algorand to process transactions efficiently, making it suitable for large-scale, real-time applications.

In each round, a block must be confirmed. In the context of this section, a block is treated as an opaque data packet with two mandatory fields:

• A block hash,
• A randomness seed.

For details on the remaining fields and the structure of a block, please refer to the Ledger’s normative specification and non-normative overview.

The Algorand Agreement Protocol is executed between nodes.

Functionally, an Algorand node “plays” on behalf of every actively participating account whose participation keys are registered for voting.

Each of these accounts can be viewed as an independent player in the protocol, identified by its unique address \( I \) and associated balance.

All the accounts registered on the node share a unified view of the transaction pool and blockchain state, which is maintained by the node through which they participate in the protocol.

Consensus is reached progressively. A round is the primary unit of time in the consensus protocol. Each round aims to agree on a single block to append to the blockchain.

The protocol begins a new round once the previous one has finalized a block.

Credentials

We define a structure \( \Credentials \) for ease of use and readability.

This structure will contain all the necessary fields for identifying a voting player, which includes:

• Address (\( I \)): A unique identifier for the participating account.

• Secret key (\( \sk_r \)): A private key associated with the account, used for cryptographic operations such as signing messages¹.

• \( \VRF \) proof (\( y \)): A cryptographic proof generated using the Verifiable Random Function (\( \VRF \))².

The sets of observed votes \( V \) and proposals \( P \), observed in a given round, are utilized here with the same definition as in the normative specification.

Analogous to these, we define a set of observed bundles \( B \) for a given round, that is built taking subsets of votes in \( V \) according to the rules for a valid bundle specified in the normative specification.

1. The secret key \( \sk \) is round-dependent because it makes use of a two-level ephemeral key scheme under the hood. In the context of this document, this procedure is replaced by an opaque structure that produces the key needed for the round and abstracts away both a signature and verification procedure. ↩

2. Since the sortition hash \( \VRF_{out} \) can be derived from a proof \( y \), we assume that \( \VRF_{out} \) is implicitly available whenever \( y \) is present. ↩

Context Tuple

The Algorand Agreement protocol may be modeled as a state machine. The state machine’s progress is driven mainly by two types of events:

• Time Events: triggered by the node’s local clock. The Agreement Protocol defines the duration of the timeouts for each protocol stage.

• Threshold Events: triggered by the votes expressed by randomly elected committees and counted by the node. The Agreement Protocol defines the number of votes for each protocol stage.

Analogous to execution coordinates, three integers taken together provide enough context on which stage of the protocol the state machine is currently processing. This triplet is referred to throughout this document as the context tuple.

The context tuple supplies the necessary information to determine the exact phase of the Agreement Protocol being executed, or, in simpler terms, “where we are” in the broader process.

For details on the formal implications of these values in the overall protocol, refer to the Algorand Byzantine Fault Tolerance normative section.

The components of the context tuple are:

1. Round (\( r \)):

   • A round defines the top-level cycle of the Algorand Agreement protocol.
   • Completing a round adds a block to the ledger (i.e., the blockchain).
   • A round is composed of one or more periods.
   • Rounds are identified by a monotonically increasing unsigned 64-bit integer representing the ledger’s current size and the committed block’s round number.
   • Fundamentally, it serves as an increasing index into the blockchain, reflecting the progression of confirmed blocks.
   • Rounds’ progression is driven by threshold events.

2. Period (\( p \)):

   • A period is a cycle within a round.
   • One or more periods will be processed until the parent round completes by reaching consensus and producing a block
   • A period is composed of multiple steps.
   • Within a round, periods are identified by a monotonically increasing unsigned 64-bit integer (starting with 0), indicating the current “run” (consensus attempt) of the same round.
   • Under ideal conditions \( p = 0 \), and remains so throughout the entire process from block proposal to block commitment.
   • If \( p \neq 0 \), the network is recovering from a failed attempt to commit a block within the current round. In such cases, all or some Agreement stages may be re-executed.
   • During recovery, specific routines monitor the network’s ability to reach consensus again. These routines may reuse information from previous failed attempts to speed up the block commitment once normal operation resumes.
   • Periods’ progression is driven by threshold events.

3. Step (\( s \)):

   • Steps are discrete units of logic that define each Algorand Agreement state machine’s states.
   • There are 5 separate steps. Each Step helps move closer to reaching consensus for the next block among the Algorand participants.
   • Some steps require a period of time to pass before moving to the next step.
   • Steps 4 and 5 will repeat with increasing timeouts until a consensus is reached for the current period.
   • Within a period, steps are identified by an unsigned 8-bit integer representing an enumeration of the possible Agreement Protocol stages. See the normative section for a formal definition of this enumeration.
   • Steps are bounded (uint8_max = 255) and follow the protocol’s predefined progression through its stages.
   • Steps’ progression is driven by time events.

$$ \newcommand \StakeOn {\mathrm{StakeOnline}} \newcommand \VRF {\mathrm{VRF}} $$

Security Model

The parameter selection of Algorand blockchain is based on a combination of assumptions:

1. Majority of online honest stake,

2. Security of cryptographic primitives,

3. Upper bound on message latency.

Honest Majority Assumption

Let’s define \( \StakeOn_{r-322} \) as the total “online” stake at round \( r-322 \).

For every round, at least \( 80\% \) of \( \StakeOn_{r-322} \) is honest in round \( r \). (Larger committee sizes would be required if we assume a smaller honest majority ratio.)

Cryptographic Assumptions

Algorand uses a digital signature scheme for message authentication. It uses a \( \VRF \) and a hash function, modeled as random oracles in the context of the consensus protocol analysis.

We allow an adversary to perform up to \( 2^{128} \) hash operations over the system’s lifetime. This is an extraordinarily large number! With these many hash operations, the adversary can find collisions in SHA-256 function, or mine \( 25 \) billion years’ worth of Bitcoin blocks at today’s hash rate¹.

Security Against Dynamic Corruption

In the Algorand protocol, users change their ephemeral participation keys used for every round. That is, after users sign their message for round \( r \), they delete the ephemeral key used for signing, and fresh ephemeral keys will be used in future rounds.

This allows Algorand to be secure against dynamic corruptions, where an adversary may corrupt a user after seeing her propagate a message through the network. (Recall that since users use their \( \VRF \)s to perform cryptographic self-selection, an adversary does not even know whom to corrupt prior to round \( r \)).

Moreover, even if in the future an adversary corrupts all committee members for a round \( r \), as the users holding the supermajority of stakes were honest in round \( r \) and erased their ephemeral keys, no two distinct valid blocks can be produced for the same round.

Network Model

Algorand guarantees liveness assuming a maximum propagation delay on messages sent through the network (see protocol parameters normative section).

Algorand guarantees safety (“no forks”) even in the case of network partitions. When a network partition heals, liveness recovers in linear time against an adversary capable of dynamic corruptions, and in constant time otherwise. Refer to the protocol run non-normative section for network partitioning examples.

1. \( \sim900 \text{ [EH/s]} \) in May 2025. ↩

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \VRF {\mathrm{VRF}} \newcommand \Prove {\mathrm{Prove}} \newcommand \ProofToHash {\mathrm{ProofToHash}} \newcommand \Secrets {\mathrm{Secrets}} \newcommand \Rerand {\mathrm{Rerand}} $$

Seed Calculation

The cryptographic seed is a source of randomness for many internal operations inside the protocol.

A formal definition of the seed can be found in the normative specification.

This section provides an engineering and implementation-oriented way of conceptualizing the seed computation, to ease its understanding.

The following algorithm makes heavy use of \( \VRF \) specific functions. For more information on their definition and internal work, refer to the Algorand Cryptographic Primitive Specification.

Notation

For the seed calculation algorithm, consider the following notation:

Algorithm

For the seed calculation algorithm, consider the following pseudocode:

\( \textbf{Algorithm 1} \text{: Compute Seed and Proof} \)

$$ \begin{aligned} &\text{1: } \PSfunction \mathrm{ComputeSeedAndProof}(I) \\ &\text{2: } \quad \PSif p = 0 \PSthen \\ &\text{3: } \quad \quad y \gets \VRF.\Prove(\Secrets(I)_{\text{VRFkey}}, L[r - \delta_s]_Q) \\ &\text{4: } \quad \quad \alpha \gets H(I || \VRF.\ProofToHash(y)) \\ &\text{5: } \quad \PSelse \\ &\text{6: } \quad \quad y \gets 0 \\ &\text{6: } \quad \quad \alpha \gets H(L[r - \delta_s]_Q) \\ &\text{7: } \quad \PSendif \\ &\text{9: } \quad \PSif r \bmod (\delta_s\delta_r) < \delta_s \PSthen \\ &\text{10:} \quad \quad Q \gets H(\alpha || H(L[r - \delta_s \delta_r])) \\ &\text{11:} \quad \PSelse \\ &\text{12:} \quad \quad Q \gets H(\alpha) \\ &\text{13:} \quad \PSendif \\ &\text{14:} \quad \PSreturn (Q, y) \\ &\text{15: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Seed computation reference implementation.

The function takes as input the address \( I \) of an online player who will be computing the seed \( Q \).

Note that the player needs to have registered participation keys on the node computing the seed, so as for the \( \Secrets(I) \) call (Algorithm 1, line 3) to retrieve available \( \VRF \) secrets generated during that registration process.

For more information on the types of keys a player has to use, refer to the Algorand Participation Key Specification.

The function computes the cryptographic seed appended to the block candidate for round \( r \), which will be used (if said block candidate is committed) as a source of randomness for the \( \VRF \) in a future round.

The seed is computed according to whether the function is called in the first period of the round, \( p = 0 \), or not.

The function also computes the proof \( y \), bundled up with the block inside a proposal structure (for broadcasting), and used by nodes receiving the proposal as part of the proposal validation process.

Example

The following is an example of seed computation in three adjacent blocks, chosen to show both branches of the Algorithm 1 execution, according to \( r \bmod \delta_s\delta_r \) condition, also known as re-randomization.

Noting that:

• \( \delta_s = 2 \),
• \( \delta_r = 80 \).

We define \( \Rerand(r) = r \bmod \delta_s\delta_r \).

When \( \Rerand(r) < \delta_s \) we say we are re-randomizing the seed \( Q \) for the round \( r \).

📎 EXAMPLE

Take the process for a player with address \( I \) at the first consensus attempt of the round (\( p = 0 \)).

• Let’s consider round \( r_a = 48182880 \), as

$$ \Rerand(r_a) = 48182880 \bmod 160 = 0 < \delta_s $$

The computation is:

1. Get the seed \( Q \) for round \( r_a - \delta_s = (48182880 - 2) = 48182878 \),
2. Construct a \( \VRF \) proof \( y \) with that seed,
3. Convert the \( \VRF \) proof \( y \) to a \( \VRF \) proof hash (named \( \VRF_h \)),
4. Hash the object \( \{I || \VRF_h\} \) (named \( \alpha \)),
5. Lookup the block digest of the old round \( r_a - \delta_s\delta_r = 48182880 - 160 = 48182720 \) (named \( H_\text{old}\)),
6. Calculate the final seed by hashing the object \( \{\alpha, H_\text{old} \} \).

• This process will be the same for \( r_b = 48182881 \) as

$$ \Rerand(r_b) = 48182881 \bmod 160 = 1 < \delta_s $$

• For the round \( r_c = 48182882 \), since

$$ Rerand(r_c) = 48182882 \bmod 160 = 2 \ge \delta_s $$

The computation is:

1. Get the seed \( Q \) for round \( r_c - \delta_s = (48182882 - 2) = 48182880 \),
2. Construct a \( \VRF \) proof \( y \) with that seed,
3. Convert the \( \VRF \) proof \( y \) to a \( \VRF \) proof hash (named \( \VRF_h \)),
4. Hash the object \( \{I || \VRF_h\} \) (named \( \alpha \)),
5. Calculate the final seed by hashing \( \alpha \).

• This process will be the same for rounds \( 48182883, \ldots, 48183039 \) as

$$ \Rerand(48182883, \ldots, 48183039) > \delta_s. $$

If during the execution of consensus for a given round, a period \( p > 0 \) is observed (i.e., the protocol is performing a new consensus attempt for the same round), steps 2-3-4 change calculating \( \alpha \) by hashing the seed of a round \( r - \delta_s \) (instead of the object \( \{I || \VRF_h\}\ \)). This condition occurs when another proposal for the same round has to be created. In this case, to avoid the possibility of seed manipulation by malicious proposers, their input is excluded from the computation (as the process uses a seed that is \( \delta_s \) rounds in the past, outside potential attacker’s influence).

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \EventHandler {\mathrm{EventHandler}} \newcommand \BlockProposal {\mathrm{BlockProposal}} \newcommand \BlockAssembly {\mathrm{BlockAssembly}} \newcommand \SoftVote {\mathrm{SoftVote}} \newcommand \CertificationVote {\mathrm{CertificationVote}} \newcommand \Commitment {\mathrm{Commitment}} \newcommand \Recovery {\mathrm{Recovery}} \newcommand \FastRecovery {\mathrm{FastRecovery}} \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \HandleProposal {\mathrm{HandleProposal}} \newcommand \HandleVote {\mathrm{HandleVote}} \newcommand \HandleBundle {\mathrm{HandleBundle}} \newcommand \Propose {\mathit{propose}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} \newcommand \ev {\mathit{ev}} \newcommand \t {\mathit{time}} \newcommand \s {\mathit{step}} \newcommand \data {\mathit{msg}_\text{data}} \newcommand \TimeoutEvent {\texttt{TimeoutEvent}} \newcommand \MessageEvent {\texttt{MessageEvent}} \newcommand \DynamicFilterTimeout {\mathrm{DynamicFilterTimeout}} $$

Agreement Stages

The Algorand Agreement Protocol can be split into a series of stages.

In the normative section, these stages are univocally associated with infinite subsets of protocol states. These subsets are disjoint and together represent the whole space of possible states for the node state machine to be in.

The stages are, in chronological order within a given round:

• \( \BlockProposal \),
• \( \SoftVote \),
• \( \CertificationVote \), which includes a final \( \Commitment \).

If \( \Commitment \) is not possible because of external reasons (i.e., a network partition), two fallback stages:

• \( \FastRecovery \),
• \( \Recovery \).

By abstracting away some implementation-specific complexity, we propose a model for the Agreement Protocol state machine that captures how and when transitions between different states happen.

Algorithm

We may model the state machine’s main algorithm in the following way:

\( \textbf{Algorithm 2} \text{: Main State Machine} \)

$$ \begin{aligned} &\text{1: } \PSfunction \EventHandler(ev) \\ &\text{2: } \qquad \PSif \ev \text{ is a } \TimeoutEvent \PSthen \\ &\text{3: } \qquad \quad \t \gets \ev_\t \\ &\text{4: } \qquad \quad \PSif \t = 0 \PSthen \PScomment{Last round should have left us with s := propose} \\ &\text{5: } \qquad \quad \quad \BlockProposal() \\&\text{6: } \qquad \quad \quad \PSif \text{finished a block} \lor \mathrm{CurrentTime}() = \mathrm{AssemblyDeadline}() \PSthen \\ &\text{7: } \qquad \quad \quad \quad \s \gets \Soft \\ &\text{8: } \qquad \quad \quad \PSendif \\ &\text{9: } \qquad \quad \PSelseif time = \DynamicFilterTimeout(p) \PSthen \\ &\text{10:} \qquad \quad \quad \SoftVote() \\ &\text{11:} \qquad \quad \quad \s \gets \Cert \\ &\text{12:} \qquad \quad \PSelseif \t = \DeadlineTimeout(p) \PSthen \\ &\text{13:} \qquad \quad \quad \s \gets \Next_0 \\ &\text{14:} \qquad \quad \quad \Recovery() \\ &\text{15:} \qquad \quad \PSelseif \t = \DeadlineTimeout(p) + 2^{s_t - 3}\lambda \text{ for } 4 \le s_t \le 252 \PSthen \\ &\text{16:} \qquad \quad \quad \s \gets \Next_{s_t} \\ &\text{17:} \qquad \quad \quad \Recovery() \\ &\text{18:} \qquad \quad \PSelseif \t = k\lambda_f + rnd \text{ for } k, rnd \in \mathbb{Z}, k > 0, 0 \le rnd \le \lambda_f \PSthen \\ &\text{19:} \qquad \quad \quad \FastRecovery() \\ &\text{20:} \qquad \quad \PSendif \\ &\text{21:} \qquad \PSelse \PScomment{MessageEvent could trigger a commitment and round advancement} \\ &\text{22:} \qquad \quad msg \gets ev_{msg} \\ &\text{23:} \qquad \quad \PSif \data \text{ is of type } \texttt{Proposal } pp \PSthen \\ &\text{24:} \qquad \quad \quad \HandleProposal(pp) \\ &\text{25:} \qquad \quad \PSelseif \data \text{ is of type } \texttt{Vote } v \PSthen \\ &\text{26:} \qquad \quad \quad \HandleVote(v) \\ &\text{27:} \qquad \quad \PSelseif \data \text{ is of type } \texttt{Bundle } b \PSthen \\ &\text{28:} \qquad \quad \quad \HandleBundle(b) \\ &\text{29:} \qquad \quad \PSendif \\ &\text{30:} \qquad \PSendif \\ &\text{31: } \PSendfunction \end{aligned} $$

The first three steps (\( \Propose, \Soft, \Cert \)) are the fundamental parts, and will be the only steps run in regular “healthy” functioning conditions.

The following steps are recovery procedures if there’s no observable consensus before their trigger times.

Note that in the case of \( \Propose \), if a block is not assembled and finalized in time for the \( \BlockAssembly() \) timeout, this might trigger advancement to the next step.

For more information on this process, refer to the Algorand Ledger non-normative section.

The \( \Next_{s-3} \) with \( s \in [3, 252] \) are recovery steps, while the last three (\( \Late, \Redo, \Down \)) are special fast recovery steps.

A period is an execution of a subset of steps, executed in order until one of them achieves a bundle for a specific value.

A round always starts with a \( \Propose \) step and finishes with a \( \Cert \) step (when a block becomes commitable, it is certified and committed to the Ledger).

However, multiple periods might be executed inside a round until:

• A certification bundle (\( \Bundle(r,p,s,v) \) where \( s = \Cert \)) is observable by the network, and

• The corresponding proposal \( Proposal(v) \) has been received and validated, and

• The proposal payload is available at the moment of commitment.

Events

Events are the only way for the node state machine to transition internally and produce output.

⚙️ IMPLEMENTATION

Events reference implementation.

If an event is not identified as misconstrued or malicious, it will produce a state change. Also, it will almost certainly cause a receiving node to produce and then broadcast or relay an output, consumed by its peers in the network.

There are two main kinds of events:

• \( \TimeoutEvent \), which are produced once the internal clock of a node reaches a specific time since the start of the current period;

• \( \MessageEvent \), which are outputs produced by nodes in response to some stimulus (including the receiving node itself).

Internally, we consider the structure of an event to be composed of:

• A floating point number, representing time (in seconds) from the start of the current period, in which the event has been triggered;

• An event type, from an enumeration;

• A data type;

• Some attached data, plain bytes to be cast and interpreted according to the attached data type, or empty in case of a timeout event.

Time Events

\( \TimeoutEvent \) are triggered when a specific time has elapsed after the start of a new period.

• \( \Soft \) timeout (a.k.a. Filtering): is run after a timeout of \( \DynamicFilterTimeout(p) \) is observed (where \( p \) is the currently running period). Note that it only depends on the period, whether it’s the first period in the round or a later one. In response to this, the node state machine will perform a filtering action, finding the highest priority proposal observed to produce a soft vote (as detailed in the \( \SoftVote \) algorithm).

• \( \Next_0 \) timeout: it triggers the first recovery step, only executed if no consensus for a specific value was observed, and no \( \Cert \) bundle is constructible with observed votes. It plays after observing a timeout of \( \DeadlineTimeout(p) \). In this step, the node will next vote a value and attempt to reach a consensus for a \( \Next_0 \) bundle, that would kickstart a new period.

• \( \Next_s \) timeout: this family of timeouts runs whenever the elapsed time since the start of the current period reaches \( \DeadlineTimeout(p) + 2^{s_t-3}\lambda \) for some \( 4 \le s_t \le 252 \). The algorithm run is the same as in the \( \Next_0 \) step.

⚙️ IMPLEMENTATION

Next vote ranges to reference implementation.

• (\( \Late, \Redo, \Down \)) fast recovery timeouts: on observing a timeout of \( k\lambda_f + rnd \) with \( rnd \) a uniform random sample in \( [0, \lambda_f] \) and \( k \) a positive integer, the fast recovery algorithm is executed. It works very similarly to \( \Next_k \) timeouts, with some subtle differences (besides trigger time).

For a detailed description, refer to its subsection.

Message Events

\( \MessageEvent \) are events triggered after observing a specific message carrying data.

In Algorithm 2, we focused on three kinds of messages:

• \( \texttt{Proposal} \),
• \( \texttt{Vote} \),
• \( \texttt{Bundle} \),

Each carries the corresponding construct (coinciding with their attached data type field).

$$ \newcommand \SoftVote {\mathrm{SoftVote}} \newcommand \CredentialHistory {\mathbf{C}} \newcommand \CredentialHistorySize {|\CredentialHistory|} \newcommand \CredentialIdx {i^\ast} \newcommand \Timeout {T_\SoftVote} \newcommand \TimeoutGracePeriod {T_\epsilon} \newcommand \lambdaMin {\lambda_\text{0min}} \newcommand \lambdaMax {\lambda_\text{0max}} \newcommand \deltaL {\delta_\text{lag}} $$

Dynamic Filter Timeout

An adaptive algorithm computes the dynamic filter timeout (i.e., the timeout to trigger a call to \( \SoftVote \)).

In regular conditions, the filtering timeout \( \Timeout \) tends to the minimum \( \lambdaMin \).

Whenever network conditions force the round advancement to stall, \( \Timeout \) will diverge towards the maximum of \( \lambdaMax \).

See the formal definition of the filtering timeout parameters in the ABFT normative section.

⚙️ IMPLEMENTATION

Dynamic filter timeout to reference implementation.

Algorithm

Let \( \CredentialHistory \) be a circular array of size \( \CredentialHistorySize \), whose elements are rounds’ minimum credential arrival time, defined as the time (elapsed since the start of \( r \)) at which the highest priority proposal vote was observed for that round.

See the formal definition of the lowest credential priority function in the ABFT normative section.

We now define the credential round lag, as:

$$ \deltaL = \min \left\{ \left\lfloor \frac{2\lambda}{\lambdaMin} \right\rfloor, 8 \right\} $$

to be the rounds’ lookback¹ for \( \CredentialHistory \).

The node tracks in \( \CredentialHistory \) the minimum credential arrival time for a certain number of rounds before \( r - \deltaL \).

Every time a round \( r \) is “successfully” completed², the node looks up the arrival time of the relevant credential for the round \( r - \deltaL \), and pushes it into \( \CredentialHistory \). If the circular array is full, the oldest entry is deleted).

It is worth noting that only rounds completed in the first attempt (\( p = 0 \)) are considered and relevant for \( \CredentialHistory \). If the round is completed in later periods (\( p > 0 \)), that round is skipped and \( \CredentialHistory \) remains unchanged.

⚙️ IMPLEMENTATION

Update credential arrival history reference implementation.

When computing the dynamic filter timeout, if a sufficient history of credentials is available (i.e., the node stored \( \CredentialHistorySize \) past credential arrival times), the array holding this history is sorted in ascending order.

Then \( \CredentialIdx \)-th element is selected as the filtering timeout value³.

Finally, a \( \TimeoutGracePeriod \) extra time is added to the selected entry, for the final filter timeout to be returned as

$$ \Timeout = \CredentialHistory[\CredentialIdx] + \TimeoutGracePeriod $$

Note that the filter timeout \( \lambdaMin \leq \Timeout \leq \lambdaMax \) is clamped on the minimum and maximum bounds defined in the ABFT normative section.

⚙️ IMPLEMENTATION

\( \CredentialIdx \)-th element selection reference implementation.

Parameters

1. With current values for \( \lambda \) and \( \lambdaMin \), \( \deltaL = 2 \). ↩

2. A round is “successfully” completed if a certification bundle is observed and the proposal is already available, or if the proposal for an already present certification bundle is received. ↩

3. With the current parametrization, this corresponds to the 95th percentile of the accumulated arrival times history. ↩

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \Resync {\mathrm{ResynchronizationAttempt}} \newcommand \BlockProposal {\mathrm{BlockProposal}} \newcommand \BlockAssembly {\mathrm{BlockAssembly}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Broadcast {\mathrm{Broadcast}} \newcommand \RetrieveProposal {\mathrm{RetrieveProposal}} \newcommand \c {\mathit{credentials}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Vote {\mathrm{Vote}} \newcommand \prop {\mathit{proposal}} $$

Block Proposal

The following is an abstracted pseudocode of the \( \BlockProposal \) algorithm.

Algorithm

\( \textbf{Algorithm 3} \text{: Block Proposal} \)

$$ \begin{aligned} &\text{1: } \PSfunction \BlockProposal() \\ &\text{2: } \quad \PSif p \ne 0 \PSthen \\ &\text{3: } \quad \quad \Resync() \\ &\text{4: } \quad \PSendif \\ &\text{5: } \quad \PSfor a \in A \PSdo \\ &\text{6: } \quad \quad \c \gets \Sortition(a_I, r, p, \prop) \\ &\text{7: } \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{8: } \quad \quad \quad \PSif p = 0 \lor \exists s’ \text{ such that } \Bundle(r, p-1, s’, \bot) \subset V \PSthen \\ &\text{9: } \quad \quad \quad \quad (e, y) \gets \BlockAssembly(a_I) \\ &\text{10:} \quad \quad \quad \quad \prop \gets \Proposal(e, y, p, a_I) \\ &\text{11:} \quad \quad \quad \quad v \gets \Proposal_\text{value}(\prop) \\ &\text{12:} \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, \prop, v, \c)) \\ &\text{13:} \quad \quad \quad \quad \Broadcast(\prop) \\ &\text{14:} \quad \quad \quad \PSelse \\ &\text{15:} \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, \prop, \bar{v}, \c)) \\ &\text{16:} \quad \quad \quad \quad \PSif \RetrieveProposal(\bar{v}) \ne \bot \PSthen \\ &\text{17:} \quad \quad \quad \quad \quad \Broadcast(\RetrieveProposal(\bar{v})) \\ &\text{18:} \quad \quad \quad \quad \PSendif \\ &\text{19:} \quad \quad \quad \PSendif \\ &\text{20:} \quad \quad \PSendif \\ &\text{21:} \quad \PSendfor \\ &\text{22: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Block proposal reference implementation.

This algorithm is the first procedure executed when entering a new round, and upon starting any period where a reproposal is not possible.

Starting on Algorithm 3 - Line 2, the node attempts a resynchronization (described in the corresponding section), which has only effect on periods \( p > 0 \).

⚙️ IMPLEMENTATION

The reference implementation executes a resynchronization attempt when entering into a new period. Functionally, the behavior is the same, as resynchronization is performed before starting a new period, save for \( p = 0 \).

The algorithm loops over all the participating accounts (\( a \in A \)) registered on the node. This is a typical pattern in every main algorithm subroutine performing committee voting.

For each participating account, the sortition algorithm runs to check if said account is allowed to participate in the proposal.

If an account \( a \) is selected by sortition (because \( \c_j = \Sortition(a_I, r, p, \prop)_j > 0 \)) there are two options:

1. If this is a proposal step (\( p = 0 \)) or if the node has observed a bundle \( \Bundle(r, p-1, s’, \bot) \) (meaning there is no valid pinned value), then the node:

   • Assembles a block (see the Ledger non-normative section for details on this process),
   • Computes the proposal value for this block,
   • Broadcast a proposal vote by the account \( a \),
   • Broadcasts the full block in a \( \texttt{Proposal} \) type message.

2. Otherwise, a value \( \bar{v} \) has been pinned, supported by a bundle observed in period \( p - 1 \), and on Algorithm 3 - Line 15 the node:

   • Gets the pinned value,
   • Assembles a vote \( \Vote(a_I, r, p, \prop, \bar{v}, \c) \),
   • Broadcasts this vote,
   • Broadcast the proposal for the pinned vote if it has already been observed.

⚙️ IMPLEMENTATION

The reference implementation assembles a set of transactions and a block header independently of the proposer, in parallel with the proposer loop. This improves timing and guarantees the tight deadline constraints for the block proposal step.

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \Priority {\mathrm{Priority}} \newcommand \VRF {\mathrm{VRF}} \newcommand \ProofToHash {\mathrm{ProofToHash}} \newcommand \SoftVote {\mathrm{SoftVote}} \newcommand \Hash {\mathrm{Hash}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Broadcast {\mathrm{Broadcast}} \newcommand \RetrieveProposal {\mathrm{RetrieveProposal}} \newcommand \DynamicFilterTimeout {\mathrm{DynamicFilterTimeout}} \newcommand \Soft {\mathit{soft}} \newcommand \Prop {\mathit{propose}} \newcommand \Vote {\mathrm{Vote}} \newcommand \loh {\mathit{lowestObservedHash}} \newcommand \vt {\mathit{vote}} \newcommand \ph {\mathit{priorityHash}} \newcommand \c {\mathit{credentials}} $$

Soft Vote

The soft vote stage (also known as “filtering”) filters the proposal-value candidates available for the round, selecting the one with the highest priority to vote for.

Priority Function

Let \( \Priority \) be the function that determines which proposal-value to soft-vote for this round, as defined in the normative section:

$$ \Priority(v) = \min_{i \in [0, w_j)} \left\{ \Hash \left( \VRF.\ProofToHash(y) || I_j || i \right) \right\} $$

Where:

• \( v \) is a proposal value for this round,
• \( I_j \) is the proposer address identified by the subscript \( j \),
• \( w_j \) is the weight of the credentials for \( v \) by proposer \( I_j \),
• \( y \) is the \( \VRF \) proof as computed by proposer \( I_j \) using their \( \VRF \) secret key.

The function selects the minimum among a set of \( w_j \) hash values calculated as \(\Hash \left(\VRF.\ProofToHash(y) || I_j || i \right)\), with \(i \in [0, w_j)\).

The higher the credentials’ weight \( w_j \), the larger the set, the higher the chances for the proposer \( I_j \) to get the lowest value among all the players for this round.

Algorithm

\( \textbf{Algorithm 4} \text{: Soft Vote} \)

$$ \begin{aligned} &\text{1: } \PSfunction \SoftVote() \\ &\text{2: } \quad \loh \gets \infty \\ &\text{3: } \quad v \gets \bot \\ &\text{4: } \quad \PSfor \vt_p \in V^\ast \PSdo \PScomment{The subset of votes corresponding to proposals} \\ &\text{5: } \quad \quad \ph \gets \Priority(\vt_p) \\ &\text{6: } \quad \quad \PSif \ph < \loh \PSthen \\ &\text{7: } \quad \quad \quad \loh \gets \ph \\ &\text{8: } \quad \quad \quad v \gets \vt_p \\ &\text{9: } \quad \quad \PSendif \\ &\text{10:} \quad \PSendfor \\ &\text{11:} \quad \PSif \loh < \infty \PSthen \\ &\text{12:} \quad \quad \PSfor a \in A \PSdo \\ &\text{13:} \quad \quad \quad \c \gets \Sortition(a_I, r, p, \Soft) \\ &\text{14:} \quad \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{15:} \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, \Soft, v, \c)) \\ &\text{16:} \quad \quad \quad \quad \PSif \RetrieveProposal(v) \PSthen \\ &\text{17:} \quad \quad \quad \quad \quad \Broadcast(\RetrieveProposal(v)) \\ &\text{18:} \quad \quad \quad \quad \PSendif \\ &\text{19:} \quad \quad \quad \PSendif \\ &\text{20:} \quad \quad \PSendfor \\ &\text{21:} \quad \PSendif \\ &\text{22: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Soft vote filtering reference implementation.

Soft vote issuance reference implementation.

The soft vote stage is run after a timeout of \( \DynamicFilterTimeout(p) \) (where \( p \) is the executing period of the node) is observed by the node (see the dynamic filter timeout section for more details).

Let \( V \) be the set of all observed votes in the currently executing round. For convenience, we define a subset, \( V^\ast \) to be all proposals received; that is \( V^\ast = \{\vt \in V : \vt_s = \Prop\} \).

With the aid of a priority function, this stage performs a filtering action, selecting the highest priority observed proposal to vote for, defined as the one with the lowest hashed value.

The priority function (Algorithm 4 - Lines 4 to 9) should be interpreted as follows.

Consider every proposal value \( \vt_p \) in the subset \( V^\ast \) and the hash of the \( \VRF \) proof \( \ProofToHash(y) \) obtained by its proposer in the sortition.

For each index \( i \) in the interval from \( 0 \) (inclusive) up to the proposer credentials’ weight¹ \( w_j \) (exclusive), the node hashes the concatenation of \( \ProofToHash(y) \), the proposer address \( I_j \) and the index \( i \), as \( \Hash(\VRF.\ProofToHash(y) || I_j || i) \) (where \( \Hash \) is the node’s general cryptographic hashing function.

See the cryptography normative section for details on the \( \Hash \) function.

Then, the node keeps track of the proposal-value \( v \) that minimizes the concatenation hashing (Algorithm 4 - Lines 6 to 8).

After running the filtering algorithm for all proposal votes observed, and assuming there was at least one proposal in \( V^\ast \), the broadcasting section of the algorithm is executed (Algorithm 4 - Lines 11 to 15).

For every online account (registered on the node), selected to be part of the \( \Soft \) voting committee, a \( \Soft \) vote is broadcast for the previously filtered value \( v \).

If the corresponding full proposal has already been observed and is available in \( P \), it is also broadcast (Algorithm 4 - Lines 16 to 17).

If the previous assumption of non-empty \( V^\ast \) does not hold, no broadcasting is performed, and the node produces no output in its filtering step.

1. Corresponds to the \( j \) output of \( \Sortition \), stored inside the \( \c \) structure. ↩

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \ValidateVote {\mathrm{ValidateVote}} \newcommand \VerifyVote {\mathrm{VerifyVote}} \newcommand \SenderPeer {\mathrm{SenderPeer}} \newcommand \DisconnectFromPeer {\mathrm{DisconnectFromPeer}} \newcommand \Equivocation {\mathrm{Equivocation}} \newcommand \IsEquivocation {\mathrm{IsEquivocation}} \newcommand \IsSecondEquivocation {\mathrm{IsSecondEquivocation}} \newcommand \HandleVote {\mathrm{HandleVote}} \newcommand \Relay {\mathrm{Relay}} \newcommand \RetrieveProposal {\mathrm{RetrieveProposal}} \newcommand \Broadcast {\mathrm{Broadcast}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \RequestProposal {\mathrm{RequestProposal}} \newcommand \StartNewPeriod {\mathrm{StartNewPeriod}} \newcommand \GarbageCollect {\mathrm{GarbageCollect}} \newcommand \StartNewRound {\mathrm{StartNewRound}} \newcommand \Commit {\mathrm{Commit}} \newcommand \Prop {\mathit{propose}} \newcommand \Next {\mathit{next}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \sk {\mathrm{sk}} \newcommand \vt {\mathit{vote}} \newcommand \c {\mathit{credentials}} $$

Vote Handler

The algorithms presented in this section abstract away a series of behaviors as a single vote handler for ease of understanding and to provide an implementation-agnostic engineering overview.

In the reference implementation, the vote verification and vote observation, although dependent on each other, are performed by separate processes.

Note that an equivocation vote is a pair of votes that differ only in their proposal values \( v \). In other words, given a player \( I \) and a node’s context tuple \((r, p, s)\), \( \Equivocation(I, r, p, s) = (\Vote(I, r, p, s, v_1), \Vote(I, r, p, s, v_2)) \) for some \( v_1 \neq v_2 \).

Algorithm

\( \textbf{Algorithm 5} \text{: Handle Vote} \)

$$ \begin{aligned} &\text{1: } \PSfunction \ValidateVote(\vt): \\ &\text{2: } \quad \PSif \PSnot \VerifyVote(\vt) \PSthen \\ &\text{3: } \quad \quad \DisconnectFromPeer(\SenderPeer(\vt)) \\ &\text{4: } \quad \quad \PSreturn \PScomment{Ignore invalid vote} \\ &\text{5: } \quad \PSendif \\ &\text{6: } \quad \PSif \vt_s = 0 \land (\vt \in V \lor \IsEquivocation(\vt)) \PSthen \\ &\text{7: } \quad \quad \PSreturn \PScomment{Ignore vote, equivocation not allowed in proposal votes} \\ &\text{8: } \quad \PSendif \\ &\text{9: } \quad \PSif \vt_s > 0 \land \IsSecondEquivocation(\vt) \PSthen \\ &\text{10:} \quad \quad \PSreturn \PScomment{Ignore vote if it’s a second equivocation} \\ &\text{11:} \quad \PSendif \\ &\text{12:} \quad \PSif \vt_r < r \PSthen \\ &\text{13:} \quad \quad \PSreturn \PScomment{Ignore vote of past round} \\ &\text{14:} \quad \PSendif \\ &\text{15:} \quad \PSif \vt_r = r + 1 \land (\vt_p > 0 \lor \vt_s \in \{\Next_0, \dots, \Next_{249}\}) \PSthen \\ &\text{16:} \quad \quad \PSreturn \PScomment{Ignore vote of next round if non-zero period or next-k step} \\ &\text{17:} \quad \PSendif \\ &\text{18:} \quad \PSif \vt_r = r \land (\vt_p \notin \{p-1, p, p+1\} \lor \\ &\text{} \quad \quad \quad \quad \quad \quad (\vt_p = p+1 \land \vt_s \in \{\Next_1, \dots, \Next_{249}\}) \lor \\ &\text{} \quad \quad \quad \quad \quad \quad (\vt_p = p \land \vt_s \in \{\Next_1, \dots, \Next_{249}\} \land \vt_s \notin \{s-1, s, s+1\}) \lor \\ &\text{} \quad \quad \quad \quad \quad \quad (\vt_p = p-1 \land \vt_s \in \{\Next_1, \dots, \Next_{249}\} \land \vt_s \notin \{\bar{s}-1, \bar{s}, \bar{s}+1\})) \PSthen \\ &\text{19:} \quad \quad \PSreturn \PScomment{Ignore vote} \\ &\text{20:} \quad \PSendif \\ &\text{21: } \PSendfunction \\ \\ &\text{22: } \PSfunction \HandleVote(\vt): \\ &\text{23:} \quad \ValidateVote(\vt) \PScomment{Check the validity of the vote} \\ &\text{24:} \quad V \gets V \cup \vt \PScomment{Observe the vote} \\ &\text{25:} \quad \Relay(\vt) \\ &\text{26:} \quad \PSif \vt_s = \Prop \PSthen \\ &\text{27:} \quad \quad \PSif \RetrieveProposal(\vt_v) \neq \bot \PSthen \\ &\text{28:} \quad \quad \quad \Broadcast(\RetrieveProposal(\vt_v)) \\ &\text{29:} \quad \quad \PSendif \\ &\text{30:} \quad \PSelseif \vt_s = \Soft \PSthen \\ &\text{31:} \quad \quad \PSif \exists v : \Bundle(\vt_r, \vt_p, \Soft, v) \subset V \PSthen \\ &\text{32:} \quad \quad \quad \PSfor a \in A \PSdo \\ &\text{33:} \quad \quad \quad \quad \c \gets \Sortition(a_{\sk}, r, p, \Cert) \\ &\text{34:} \quad \quad \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{35:} \quad \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, \Cert, v, \c)) \\ &\text{36:} \quad \quad \quad \quad \PSendif \\ &\text{37:} \quad \quad \quad \PSendfor \\ &\text{38:} \quad \quad \PSendif \\ &\text{39:} \quad \PSelseif \vt_s = \Cert \PSthen \\ &\text{40:} \quad \quad \PSif \exists v : \Bundle(\vt_r, \vt_p, \Cert, v) \subset V \PSthen \\ &\text{41:} \quad \quad \quad \PSif \RetrieveProposal(v) = \bot \PSthen \\ &\text{42:} \quad \quad \quad \quad \RequestProposal(v) \\ &\text{43:} \quad \quad \quad \quad \PSif p < \vt_p \PSthen \\ &\text{44:} \quad \quad \quad \quad \quad p_{old} \gets p \\ &\text{45:} \quad \quad \quad \quad \quad \StartNewPeriod(\vt_p) \\ &\text{46:} \quad \quad \quad \quad \quad \GarbageCollect(r, p_{old}) \\ &\text{47:} \quad \quad \quad \quad \PSendif \\ &\text{48:} \quad \quad \quad \PSendif \\ &\text{49:} \quad \quad \quad \Commit(v) \\ &\text{50:} \quad \quad \quad r_{old} \gets r \\ &\text{51:} \quad \quad \quad \StartNewRound(\vt_r + 1) \\ &\text{52:} \quad \quad \quad \GarbageCollect(r_{old}, p) \\ &\text{53:} \quad \quad \PSendif \\ &\text{54:} \quad \PSelseif \vt_s > \Cert \PSthen \\ &\text{55:} \quad \quad \PSif \exists v : \Bundle(\vt_r, \vt_p, \vt_s, v) \subset V \PSthen \\ &\text{56:} \quad \quad \quad p_{old} \gets p \\ &\text{57:} \quad \quad \quad \StartNewPeriod(\vt_p + 1) \\ &\text{58:} \quad \quad \quad \GarbageCollect(r, p_{old}) \\ &\text{59:} \quad \quad \PSendif \\ &\text{60:} \quad \PSendif \\ &\text{61: } \PSendfunction \\ \end{aligned} $$

⚙️ IMPLEMENTATION

Relevant parts of the reference implementation related to vote handling:

• Vote verification.
• Vote handling in the vote tracker.
• Vote handling in the proposal manager.
• Threshold handling.
• Certification vote issuance.
• Equivocation vote verification.

The vote handler is triggered when a node receives a message containing a vote for a given proposal value, round, period, or step.

It first performs a series of checks, and if the received vote passes all of them, then it is broadcast by all accounts selected as the appropriate committee members.

Vote Validation

On Line 2, the \( \ValidateVote \) function checks if the vote is valid. If invalid, this is considered adversarial behavior. Therefore, a node may disconnect from the vote sender node (Line 3), retrieving the network ID of the original message sender with the \( SenderPeer \ helper network module function.

For more details on disconnection actions and the definition of a peer, refer to the Algorand Network Layer non-normative section.

Equivocation votes on a proposal step are not allowed, so a check for this condition is performed (Line 6).

Furthermore, second equivocations are never allowed (Line 9).

Any votes for rounds before the current round are discarded (Line 12).

In the special case of receiving a message vote for a round immediately after the current round, the node observes it only if it is related to the first period (\( p = 0 \)), in any of the following steps: proposal, soft, cert, late, down, or redo (ignoring votes for further periods \( p > 0 \) or for \( \Next_k \) steps).

Finally, the node checks that (Line 18) if the vote’s round is for the currently executing round, and one of the following:

• Vote’s period is not the current node period, the period before, or the next period, or

• Vote’s period is the next period, and

  • Its step is \( \Next_k \) with \( k \geq 1 \), or

• Vote’s period is the current node period, and

  • Its step is \( \Next_k \) with \( k \geq 1 \), and
  • Its step is not the current step, the step before, or the next step, or

• Vote’s period is the period before, and

  • Its step is \( \Next_k \) with \( k \geq 1 \), and
  • Its step distance is not one or less from the node’s last finished step.

Then the vote is ignored and discarded. Note that the equivocation vote verification uses the same verification functions, but verifies that both constituent votes are valid separately.

Vote Handling

Once finished with the series of validation checks, the vote is observed, relayed, and then processed by the node according to its current context and the vote’s step:

• If the vote’s step is \( \Prop \), and the proposal corresponding to the proposal-value \( v \) has already been observed, the proposal is broadcast (that is, the node performs a re-proposal payload broadcast).

• If the vote’s step is \( Soft \), and a \( \Soft \Bundle \) has been observed with the addition of the vote, the \( \Sortition \) sub-procedure is run for every online account managed by the node. Then, a \( Cert \) vote is cast for each account the lottery selects.

• If the vote’s step is \( Cert \), and observing the vote causes the node to observe a \( Cert \Bundle \) for a proposal-value \( v \), then it checks if the full proposal associated with the critical value has been observed. Simultaneous observation of a \( Cert \Bundle \) for a value \( v \) and of a proposal equal to \( RetrieveProposal(v) \) implies the associated entry is committable. If the full proposal has not yet been observed, the node may stall and request the full proposal from the network. Once the desired proposal can be committed, the node proceeds to commit, start a new round, and garbage collects all transient data from the round it just finished.

• Finally, if the vote is that of a recovery step (\( s > \Cert \)), and a \( \Bundle \) has been observed for a given proposal-value \( v \), then a new period is started, and the currently executing period-specific data is garbage collected.

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \HandleProposal {\mathrm{HandleProposal}} \newcommand \VerifyProposal {\mathrm{VerifyProposal}} \newcommand \IsCommittable {\mathrm{IsCommittable}} \newcommand \Relay {\mathrm{Relay}} \newcommand \Broadcast {\mathrm{Broadcast}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Hash {\mathrm{Hash}} \newcommand \Encode {\mathrm{Encode}} \newcommand \bh {\mathrm{bh}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} \newcommand \pr {\mathit{proposal}} \newcommand \c {\mathit{credentials}} $$

Proposal Handler

The proposal handler is triggered when a node receives a full proposal message.

A proposal-value and a full proposal are related but separate constructions. This is motivated by a slower gossiping time of a full proposal, compared to a much more succinct and therefore quickly gossiped proposal-value.

A proposal-value contains four fields:

1. The original period in which this block was proposed.

2. The original proposer’s address.

3. The block digest, equal to the block header’s hash (including a domain separator). This field expands to \( \Hash(\texttt{“BH”} || \Encode(\bh)) \), where \( \texttt{“BH”} \) is the domain separator for a “block header”, and the encoding function is the msgpack of the block header (\( \bh \)).

4. A hash of the proposal, \( \Hash(\Proposal) \). This field expands to \( \Hash(\texttt{“PL”} || \Encode(\Proposal)) \), where \( \Proposal \) represents the unauthenticated proposal, \( \texttt{“PL”} \) is the domain separator for a “payload”, and the encoding function is the msgpack of the \( \Proposal \).

⚙️ IMPLEMENTATION

Proposal-value structure.

Domain separators for block header and payload.

On the other hand, an unauthenticated proposal contains a full block and all extra data for the block validation:

1. The original period in which this block was proposed.

2. The original proposer’s address.

3. A full block (header and payset).

4. A seed proof \( \pi_{seed} \).

Note that the original period and proposer’s address are the same as the associated proposal-value. The seed proof \( \pi_{seed} \) is used to verify the seed computation.

⚙️ IMPLEMENTATION

Unauthenticated proposal structure.

⚙️ IMPLEMENTATION

In the reference implementation, the unauthenticated proposal is sent to the network linked to a previously emitted proposal vote. These are sent together in a struct defined as a compound message, which avoids the edge case of receiving proposal and proposal-value messages in an unfavorable order. Consider the following edge case: a node observes a proposal before receiving its supporting proposal-value. It discards the proposal (to avoid DDoS attacks). Right after the node receives the related proposal-value, it goes through all the steps, and certifies this block, but needs to request the previously discarded proposal to be able to commit it and advance a round. If this happens to enough nodes (voting stake), the network might move to a second period. In the new period, the proposal is broadcast and committed fast, since the proposal step is skipped (having carried over the staged and frozen values).

Algorithm

In the following pseudocode the frozen value \( \mu \) is either:

• The highest priority observed proposal-value in the current \((r, p)\) context (i.e., the lowest hashed according to the priority function), or
• \( \bot \) if the node has observed no valid proposal vote.

The staged value \( \sigma \) is either:

• The sole proposal-value for which a \( \Bundle_\Soft \) has been observed in the current \((r, p)\) context (see normative section), or
• \( \bot \) if the node has observed no valid \( \Bundle_\Soft \).

The pinned value \( \bar{v} \) is a proposal-value that was a staged value in a previous period. When available, this value is used to fast-forward the first steps of the protocol when a \( \Next \) vote has been successful.

\( \textbf{Algorithm 6} \text{: Handle Proposal} \)

$$ \begin{aligned} &\text{1: } \PSfunction \HandleProposal(\pr) \\ &\text{2: } \quad v \gets \Proposal_v(\pr, \pr_p, \pr_I) \\ &\text{3: } \quad \PSif \exists \Bundle(r+1, 0, \Soft, v) \in B \PSthen \\ &\text{4: } \quad \quad \Relay(\pr) \\ &\text{5: } \quad \quad \PSreturn \PScomment{Future round, do not observe (node is behind)} \\ &\text{6: } \quad \PSendif \\ &\text{7: } \quad \PSif \PSnot \VerifyProposal(\pr) \lor \pr \in P \PSthen \\ &\text{8: } \quad \quad \PSreturn \PScomment{Ignore proposal} \\ &\text{9: } \quad \PSendif \\ &\text{10:} \quad \PSif v \notin \{\sigma, \bar{v}, \mu\} \PSthen \\ &\text{11:} \quad \quad \PSreturn \PScomment{Ignore proposal} \\ &\text{12:} \quad \PSendif \\ &\text{13:} \quad \Relay(\pr) \\ &\text{14:} \quad P \gets P \cup \pr \\ &\text{15:} \quad \PSif \IsCommittable(v) \land s \le \Cert \PSthen \\ &\text{16:} \quad \quad \PSfor a \in A \PSdo \\ &\text{17:} \quad \quad \quad \c \gets \Sortition(a_I, r, p, \Cert) \\ &\text{18:} \quad \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{19:} \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, \Cert, v, \c)) \\ &\text{20:} \quad \quad \quad \PSendif \\ &\text{21:} \quad \quad \PSendfor \\ &\text{22:} \quad \PSendif \\ &\text{23: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Proposal handler reference implementation.

The node starts by performing a series of checks, after which it will either:

• Ignore the received proposal, discarding it and emitting no output, or

• Relay, observe, and produce an output according to the current context and the characteristics of the proposal.

The node checks if the proposal is from the first period of the next round (Line 3), in which case, the node relays this proposal and then ignores it for the operations of the current round.

Whenever the node catches up (i.e., observes a round change), and only if necessary, it will request this proposal back from the network.

The node checks (Line 7) if the proposal is invalid or has already been observed. Any one of those conditions is enough to discard and ignore the incoming proposal.

Finally, the node checks (Line 10) if the associated proposal value is either a special proposal-value for the current round and period (\( \sigma \), \( \mu \)) or the pinned proposal-value (\( \bar{v} \)). Any full proposal whose proposal-value does not match one of these is ignored.

For formal details on special values, refer to the normative section.

Once the checks have been passed, the node relays and observes the proposal (Lines 13 and 14), by adding it to the observed proposals set \( P \).

Next, only if the proposal-value is committable (meaning the staged value is set for a proposal, and said proposal has already been observed and is available) and the current step is lower than or equal to a \( \Cert \) step (i.e., is not yet in a recovery step), the node plays for each online account (registered on the node), performing a \( \Sortition \)to select the certification committee members.

For each selected account, a \( \Vote_\Cert \) for the current proposal-value is broadcast.

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \Bundle {\mathrm{Bundle}} \newcommand \HandleBundle {\mathrm{HandleBundle}} \newcommand \VerifyBundle {\mathrm{VerifyBundle}} \newcommand \HandleVote {\mathrm{HandleVote}} \newcommand \SenderPeer {\mathrm{SenderPeer}} \newcommand \DisconnectFromPeer {\mathrm{DisconnectFromPeer}} \newcommand \vt {\mathit{vote}} \newcommand \b {\mathit{bundle}} $$

Bundle Handler

The node runs a bundle handler when receiving a message with a full bundle.

Algorithm

\( \textbf{Algorithm 6} \text{: Handle Bundle} \)

$$ \begin{aligned} &\text{1: } \PSfunction \HandleBundle(\b): \\ &\text{2: } \quad \PSif \PSnot \VerifyBundle(\b) \PSthen \\ &\text{3: } \quad \quad \DisconnectFromPeer(\SenderPeer(\b)) \\ &\text{4: } \quad \quad \PSreturn \\ &\text{5: } \quad \PSendif \\ &\text{6: } \quad \PSif \b_r = r \land \b_p + 1 \ge p \PSthen \\ &\text{7: } \quad \quad \PSfor \vt \in \b \PSdo \\ &\text{8: } \quad \quad \quad \HandleVote(\vt) \\ &\text{9: } \quad \quad \PSendfor \\ &\text{10:} \quad \PSendif \\ &\text{11: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Bundle verification reference implementation.

Bundle handling in general message handler.

The bundle handler is invoked whenever a bundle message is received.

The received bundle is immediately discarded if it is invalid (Line 2). The node may penalize the malicious sending peer (e.g., disconnecting from or “blacklisting” it).

If the received bundle (Line 6):

• Is for round equal to the node’s current round, and
• Is for at most one period behind the node’s current period.

Then the bundle is processed, calling the vote handler for each vote in the bundle (Lines 7 and 8).

Note that multiple bundles can be processed concurrently. Therefore, while handling votes from a bundle \( b \) for proposal-value \( v \) separately, if another bundle \( \b\prime = \Bundle(\b_r, \b_p, \b_s, v\prime) \) is formed and observed first (with \( v\prime \) not necessarily equal to \( v \)¹), votes in \( \b\prime \) are relayed individually, and any output or state changes caused by observing \( \b\prime \) is produced.

All leftover votes in \( b \) are then processed according to the new node state determined by \( \b\prime \) observation (e.g., votes are discarded if the executing step was certification and a new round has started, and so \( b_r < r \)).

If \( \b \) does not pass the previous check (Line 6), then no output is produced, and the bundle is ignored and discarded.

1. Consider what would happen if equivocation votes contained in \( b \) cause a bundle for \( v\prime \) to reach the required threshold before the player may finish observing every single vote in \( b \). ↩

$$ \newcommand \Commit {\mathrm{Commit}} \newcommand \RetrieveProposal {\mathrm{RetrieveProposal}} \newcommand \ApplyDeltas {\mathrm{ApplyDeltas}} \newcommand \TP {\mathrm{TransactionPool}} \newcommand \Update {\mathrm{Update}} \newcommand \PSfunction {\textbf{function }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \pset {\mathit{payset}} $$

Commitment

The commitment is the final stage that updates the copy of the Ledger on the node, applying all the state deltas (e.g., account balances, application state, etc.) related to the transactions contained in the committed block proposal.

Algorithm

In the following pseudocode \( e_t \) denotes the body (transactions) of the proposal (a.k.a. the payset).

\( \textbf{Algorithm 8} \text{: Commit} \)

$$ \begin{aligned} &\text{1: } \PSfunction \Commit(v) \\ &\text{2: } \quad e \gets \RetrieveProposal(v)_e \\ &\text{3: } \quad L \gets L || e \\ &\text{4: } \quad \ApplyDeltas(e) \\ &\text{5: } \quad \TP.\Update(e_t) \\ &\text{6: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Commit block proposal reference implementation.

The function commits to the Ledger the block corresponding to the received proposal-value.

The proposal-value must be committable, which implies both validity and availability of the full block body and seed.

The node retrieves the full block \( e \) related to the proposal-value (Line 2), and appends it to the Ledger \( L \) (Line 3).

Then, the node updates the Ledger state (and trackers) with all state changes (deltas) produced by the new committed block.

For further details, refer to the Ledger normative section.

The \( \TP \) is then purged of all transactions in the committed block.

For further details on this process, see the Ledger non-normative section.

$$ \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \s {\mathit{step}} \newcommand \Soft {\mathit{soft}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} \newcommand \Next {\mathit{next}} $$

Recovery Stages

Whenever the threshold for a certification vote is not achieved in the allowed time for the current period, \( DeadlineTimeout(p) \), the protocol enters in recovery mode.

The protocol employs a series of recovery routines to provide a quick response once normal network conditions are reestablished.

In the “best case scenario” the protocol tries to “preserve and carry over” some information from the failed consensus attempt to speed up the recovery process.

In the “worst case scenario” the protocol tries to reach an “agreement to disagree”, that is a bundle of votes to start the next period without any previous assumptions, and goes back to the block assembly and proposal stage.

The following sections present the recovery stages and routines.

Recovery Modes

The Algorand protocol provides two recovery modes, executed in parallel at different time-cadence, driven by the \( \s \) and the local node timer \( t_N \).

The following is a conceptual diagram of the two recovery modes, briefly described below.

Recovery (Exponential Recovery)

\( \s \in [3,252] \): the Recovery (or Exponential Recovery) mode attempts are executed with an exponentially growing time cadence (apart from a finite random variance), and so becoming increasingly sporadic.

When

• \( t_N = \max{4\lambda,\Lambda} \) (when \( \s = 3 \)) or,

• \( t_N = \max{4\lambda,\Lambda} + 2^{\s-3} \lambda + r \) (when \( 4 \leq \s \leq 252 \)), where \( r \in [0, 2^{\s-3}\lambda] \) is sampled uniformly at random,

Then

• If the node has seen a valid block proposal \( B \) and a \( (r, p) \)-\( \Soft \)-quorum for \( H(B) \) has been observed, then the node \( \Next \)-votes \( H(B) \),

• Otherwise, if \( p > 0 \) and the node has received a \( \Next \)-quorum for \( \bot \) from period \( (r, p-1) \), then the node \( \Next \)-votes \( \bot \),

• Otherwise, the node has received a \( \Next \)-quorum for \( v = H(B’) \neq \bot \) from period \( (r, p-1) \), and the node \( \Next \)-votes \( v \).

The \( \s \) of the node context tuple \( (r, p, s) \) is incremented every time the local node clock triggers a Recovery trial.

For further details on the Recovery procedure, see the non-normative section.

Fast Recovery (Linear Recovery)

\( \s \in [253,255] \): the Fast Recovery (or Linear Recovery) mode attempts are executed with almost constant time cadence (apart from a finite random variance).

When

• \( t_N = k\lambda_f + t \) for any positive integer \( k \) and \( t \in [0,\lambda_f] \), where \( t \) is sampled uniformly at random,

Then

• If the node has seen a valid block proposal \( B \) and a \( (r, p ) \)-\( \Soft \)-quorum for \( H(B) \) then the node \( \Late \)-votes \( H(B) \) (\( \s = 253 \)),

• Otherwise, if \( p > 0 \) and the node has received a \( \Next \)-quorum for \( \bot \) from period \( (r, p-1) \), then the node \( \Down \)-votes \( \bot \) (\( \s = 255 \)),

• Otherwise, the node has received a \( \Next \)-quorum for \( v = H(B’) \neq \bot \) from period \( (r, p-1) \), and the node \( \Redo \)-votes \( v \) (\( \s = 254 \)).

These three steps are mutually exclusive; therefore, whenever a time event triggers the Fast Recovery procedure, just one of \( \Late, \Redo, \Down \) steps is executed.

In the Fast Recovery procedure, the \( \s \) of the node context tuple \( (r, p, s) \) is not incremented every time the local node clock triggers a Fast Recovery trial. In fact, the node does not wait \( \s \) to be equal to \( 253, 254, 255 \) to execute a Fast Recovery attempt. Fast Recovery attempts are driven just by the local node clock (\( t_N = k\lambda_f + t \)) and just one among the three mutually exclusive \( \Late, \Redo, \Down \) steps is executed.

For further details on the Fast Recovery procedure, see the non-normative section.

$$ \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} $$

Resynchronization Attempt

The resynchronization is an auxiliary function used throughout the recovery steps.

A partial order relation is defined in the space of all observed bundles. We call this relation freshness.

A resynchronization attempt broadcasts the freshest observed bundle (if any).

Priority-wise, bundles’ freshness is defined as follows:

• Bundles for a \( \Cert \) step are fresher than all other bundles.

• Bundles from a later period are fresher than bundles from an older period.

• Bundles for \( \Next \) step are fresher than bundles for a \( \Soft \) step of the same period.

• Bundles for \( \Next \) step for the \( \bot \) proposal-value are fresher than bundles for a \( \Next \) step for some other value.

For a formal definition of this property, refer to the ABFT normative section.

⚙️ IMPLEMENTATION

Bundle freshness reference implementation.

In the reference implementation, a resynchronization attempt is handled by the partitionPolicy function, as the network is assumed to be in a “partitioned state” due to the temporary inability to reach consensus. In this case, the function is only invoked when the current step \( s \geq 3 \) or when the current period \( p \geq 3 \) (that is, the player has gone through two full periods without reaching a consensus).

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \Recovery {\mathrm{Recovery}} \newcommand \ResynchronizationAttempt {\mathrm{ResynchronizationAttempt}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \IsCommittable {\mathrm{IsCommittable}} \newcommand \Broadcast {\mathrm{Broadcast}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} \newcommand \c {\mathit{credentials}} \newcommand \prop {\mathit{proposal}} \newcommand \s {\mathit{step}} $$

Recovery

The recovery algorithm is executed periodically, whenever a \( \Bundle_\Cert \) has not been observed before \( \DeadlineTimeout(p) \) for a given period \( p \).

Algorithm

\( \textbf{Algorithm 9} \text{: Recovery} \)

$$ \begin{aligned} &\text{1: } \PSfunction \Recovery() \\ &\text{2: } \quad \ResynchronizationAttempt() \\ &\text{3: } \quad \PSfor a \in A \PSdo \\ &\text{4: } \quad \quad \c \gets \Sortition(a_I, r, p, s) \\ &\text{5: } \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{6: } \quad \quad \quad \PSif \exists v = \Proposal_v(\prop, \prop_p, \prop_I) \\ &\text{ } \quad \quad \quad \quad \quad \text{for some } \prop \in P \mid \IsCommittable(v) \PSthen \\ &\text{7: } \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, s, v, \c)) \\ &\text{8: } \quad \quad \quad \PSelseif \exists s_0 > \Cert \mid \Bundle(r, p - 1, s_0, \bot) \subseteq V \land \\ &\text{ } \quad \quad \quad \quad \quad \quad \quad \exists s_1 > \Cert \mid \Bundle(r, p - 1, s_1, \bar{v}) \subseteq V \PSthen \\ &\text{9: } \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, s, \bar{v}, \c)) \\ &\text{10:} \quad \quad \quad \PSelse \\ &\text{11:} \quad \quad \quad \quad \Broadcast(\Vote(a_I, r, p, s, \bot, \c)) \\ &\text{12:} \quad \quad \quad \PSendif \\ &\text{13:} \quad \quad \PSendif \\ &\text{14:} \quad \PSendfor \\ &\text{15:} \quad \s \gets \s + 1 \\ &\text{16: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Next vote issuance reference implementation.

The node starts by making a resynchronization attempt (Line 2).

Afterward (Lines 3:5), the node plays independently for each online account (registered on the node). This means that for every account available in \( A \), the \( \Sortition \) algorithm is run, and accounts selected in the recovery committee (i.e., the players) for the current step \( \Next_k \) (that is, those whose \( \c_j > 0 \)) will produce one of the following three distinct outputs (Lines 6:14):

• If a proposal-value \( v \) can be committed in the current context, then the player broadcasts a \( \Next_k \) vote for \( v \).

• If no proposal-value can be committed, and

  • No recovery step \( \Bundle \) for the empty proposal-value (\( \bot \)) was observed in the previous period, and
  • A recovery step \( \Bundle \) for the pinned value was observed in the previous period¹,

  then a \( \Next_k \) vote for \( \bar{v} \) is broadcast by the player.

• Finally, if none of the above conditions were met, a \( \Next_k \) vote for \( \bot \) is broadcast.

A player is forbidden from equivocating in \( \Next_k \) votes.

Lastly (Line 15), the node’s current \( \s \) is updated.

For a formal definition of this functionality, refer to the ABFT normative section.

1. This implies \( \bar{v} \neq \bot \). ↩

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \Recovery {\mathrm{Recovery}} \newcommand \FastRecovery {\mathrm{FastRecovery}} \newcommand \Resync {\mathrm{Resync}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Broadcast {\mathrm{Broadcast}} \newcommand \IsCommittable {\mathrm{IsCommittable}} \newcommand \Vote {\mathrm{Vote}} \newcommand \Bundle {\mathrm{Bundle}} \newcommand \Cert {\mathit{cert}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} \newcommand \Next {\mathit{next}} \newcommand \vt {\mathit{vote}} \newcommand \c {\mathit{credentials}} \newcommand \s {\mathit{step}} $$

Fast Recovery

The fast recovery algorithm is executed periodically every integer multiple of \( \lambda_f \) seconds (plus finite random variance).

This results in an approximately linear execution rate, while the network partitioning continues.

The algorithm uses the last three steps (named \( \Late, \Redo, \Down \) respectively) for \( \s \in [253, 254, 255] \).

These steps are, by nature, mutually exclusive:

• A \( \Late \)-vote will be attempted if a staged value \( \sigma \) is available (for the current round and period),

• Otherwise, a \( \Redo \)-vote will be attempted if the current period \( p > 0 \), and the last period was completed with a \( \Next \)-threshold for a proposal-value different from \( \bot \),

• Finally, as a fallback, a \( \Down \)-vote is attempted if none of the above conditions were met.

A \( \Down \)-vote is always a vote for the \( \bot \) proposal-value, while \( \Late \) and \( \Redo \) must vote for a proposal-value different from \( \bot \).

Algorithm

\( \textbf{Algorithm 10} \text{: Fast Recovery} \)

$$ \begin{aligned} &\text{1: } \PSfunction \FastRecovery() \\ &\text{2: } \quad \Resync() \\ &\text{3: } \quad \PSfor a \in A \PSdo \\ &\text{4: } \quad \quad \PSif \IsCommittable(\bar{v}) \PSthen \\ &\text{5: } \quad \quad \quad \c \gets \Sortition(a_I, r, p, \Late) \\ &\text{6: } \quad \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{7: } \quad \quad \quad \quad \Broadcast(\Vote(r, p, \Late, \bar{v}, \c)) \\ &\text{8: } \quad \quad \quad \PSendif \\ &\text{9: } \quad \quad \PSelseif \nexists s_0 > \Cert \mid \Bundle(r, p - 1, s_0, \bot) \subseteq V \land \\ &\text{ } \quad \quad \quad \quad \quad \quad \exists s_1 > \Cert \mid \Bundle(r, p - 1, s_1, \bar{v}) \subseteq V \PSthen \\ &\text{10:} \quad \quad \quad \c \gets \Sortition(a_I, r, p, \Redo) \\ &\text{11:} \quad \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{12:} \quad \quad \quad \quad \Broadcast(\Vote(r, p, \Redo, \bar{v}, \c)) \\ &\text{13:} \quad \quad \quad \PSendif \\ &\text{14:} \quad \quad \PSelse \\ &\text{15:} \quad \quad \quad \c \gets \Sortition(a_I, r, p, \Down) \\ &\text{16:} \quad \quad \quad \PSif \c_j > 0 \PSthen \\ &\text{17:} \quad \quad \quad \quad \Broadcast(\Vote(r, p, \Down, \bot, \c)) \\ &\text{18:} \quad \quad \quad \PSendif \\ &\text{19:} \quad \quad \PSendif \\ &\text{20:} \quad \PSendfor \\ &\text{21:} \quad \PSfor \vt \in V \text{ such that } \vt_s \geq 253 \PSdo \\ &\text{22:} \quad \quad \Broadcast(\vt) \\ &\text{23:} \quad \PSendfor \\ &\text{24: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Fast recovery vote issuance reference implementation.

\( \FastRecovery \) is functionally very close to the regular \( \Recovery \) algorithm (outlined in the previous section), performing the same checks and similar outputs.

The main difference is that it emits votes for any of the three different steps \( \Late, \Redo, \Down \), according to \( \Sortition \) results for every selected account.

Nodes are forbidden to equivocate for \( \Late, \Redo, \Down \) votes.

Finally, the node broadcasts all fast recovery votes observed. That is, all votes \( \vt \in V \) for which \( \vt_s \) is a fast recovery step (\( \Late, \Redo, \Down \)).

For a formal definition of this functionality, refer to the ABFT normative section.

$$ \newcommand \TP {\mathrm{TransactionPool}} \newcommand \Next {\mathit{next}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} $$

Examples of Protocol Runs

The following section presents three examples of valid protocol runs, going from simple to more complex agreement attempts, by adding partition scenarios that involve recovery stages.

The run examples are named from “best” to “worst” respectively:

• Vanilla Run: agreement is achieved at the first attempt,

• Jalapeño Run: agreement is achieved with a \( \Next \) recovery procedure,

• Habanero Run: agreement is achieved with \( \Late, \Redo, \Down \) fast recovery procedure.

Besides being the simplest, the Vanilla Run is the most common case, as infrastructure failures are extremely rare. However, the partition scenarios in the Jalapeño Run and Habanero Run shed light on the recovery mechanisms.

Initial Context

All three scenarios share the following initial context and are played by the node \( \bar{N} \).

A genesis block was generated. Algorand has been running for a while with a set of nodes and accounts, and several blocks have already been generated.

The network is now at round \( r - 1 \) (with \( r >> 2 \)), meaning that \( r - 1 \) blocks have been generated and confirmed on the blockchain.

Moreover, the node \( \bar{N} \) has:

• Received some transactions,

• Verified them to be correctly signed by Algorand accounts,

• Validated them according to Ledger and node context,

• Added them to its \( \TP \),

• Relayed them to other nodes.

For this section, we assume that all players behave according to protocol and are in sync, that is:

• The context \( (r, p, s) \) for all nodes is the same,

• Nodes’ internal clocks are synchronized.

$$ \newcommand \BlockProposal {\mathrm{BlockProposal}} \newcommand \BlockAssembly {\mathrm{BlockAssembly}} \newcommand \SoftVote {\mathrm{SoftVote}} \newcommand \DynamicFilterTimeout {\mathrm{DynamicFilterTimeout}} \newcommand \EventHandler {\mathrm{EventHandler}} \newcommand \Proposal {\mathrm{Proposal}} \newcommand \Priority {\mathrm{Priority}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Commit {\mathrm{Commit}} \newcommand \HandleProposal {\mathrm{HandleProposal}} \newcommand \HandleVote {\mathrm{HandleVote}} \newcommand \VerifyProposal {\mathrm{VerifyProposal}} \newcommand \RetrieveProposal {\mathrm{RetrieveProposal}} \newcommand \StartNewRound {\mathrm{StartNewRound}} \newcommand \GarbageCollect {\mathrm{GarbageCollect}} \newcommand \CommitteeThreshold {\mathrm{CommitteeThreshold}} \newcommand \VRF {\mathrm{VRF}} \newcommand \ProofToHash {\mathrm{ProofToHash}} \newcommand \TP {\mathrm{TransactionPool}} \newcommand \Vote {\mathrm{Vote}} \newcommand \EventNewRound {\texttt{NewRound}} \newcommand \EventProposal {\texttt{Proposal}} \newcommand \EventVote {\texttt{Vote}} \newcommand \EventTimeout {\texttt{Timeout}} \newcommand \Propose {\mathit{propose}} \newcommand \Soft {\mathit{soft}} \newcommand \prop {\mathit{proposal}} \newcommand \c {\mathit{credentials}} \newcommand \vt {\mathit{vote}} $$

Vanilla Run

For ease of understanding, we present a “vanilla run” of the Algorand consensus algorithm, the simplest scenario in which the agreement protocol produces a valid block and appends it to the Ledger.

The following timeline diagram illustrates the process:

timeline
    title Vanilla Run
    section (r = i, p = 0, 0 <= s <= 2)
        Proposal (s = 0) time = 0                   : Emits proposals for i-th round from selected accounts registered on the node
        Soft Vote (s = 1) time = DynamicTO(p)       : Filters proposals (lowest hash criteria) : Soft vote on the best proposal for round i
        Certification (s = 2) time < DeadlineTO(p)  : Certification vote of a proposal backed by a Soft Vote Bundle
                                                    : Appended i-th block to the Ledger
                                                    : State deltas applied
                                                    : Transaction pool purged
    section (r = i+1, p = 0, 0 <= s <= 2)
        Proposal (s = 0) time = 0                   : Emits proposals for i+1-th round from selected accounts registered on the node
        Soft Vote (s = 1) time = DynamicTO(p)       : Filters proposals (lowest hash criteria) : Soft vote on the best proposal for round i+1
        Certification (s = 2) time < DeadlineTO(p)  : Certification vote of a proposal backed by a Soft Vote Bundle
                                                    : Appended i+1-th block to the Ledger
                                                    : State deltas applied
                                                    : Transaction pool purged

Run

Let us assume the network conditions are those described in the initial context.

Proposal

As the main algorithm starts a round, it is called with a \( \EventNewRound \) event (node’s clock reset \( t = 0 \)) and calls the \( \BlockProposal \) procedure.

The \( \BlockProposal \) algorithm runs a loop in which it iterates over all the accounts registered online in the node. When at least one account gets selected by the \( \Sortition \), the node participates in the proposal voting on behalf of the selected accounts, and starts the \( \BlockAssembly \) procedure.

This procedure will traverse the \( \TP \), calling the Algorand Virtual Machine, and execute one transaction at a time, obtaining a new block \( e \).

The node will:

1. Assemble a \( \prop \) and a \( \vt \) on proposal-value \( v \),

2. Set \( v \) as the proposal-value obtained from block \( e \),

3. Make two separate broadcasts for \( \Vote(a_I, r,p, \prop, v, \c) \) and for \( e \).

Then, the main algorithm enters the \( \Soft \) step setting \( s = 1 \).

Proposal received from other nodes

Assume that some time has passed, now \( 0 < t < \DynamicFilterTimeout(p) \), and that the node receives a block proposal \( e^\prime \) broadcast from another node.

Then, the \( \EventHandler \) runs the proposal handling subroutine \( \HandleProposal(e^\prime) \).

This algorithm receives the proposal \( e^\prime \) and unpacks its contents, including the execution state \( (r^\prime, p^\prime, s^\prime) \).

Given the vanilla context assumptions, both nodes have the same context, therefore \( r = r^\prime \) and \( p = p^\prime = 0 \).

The algorithm checks if the proposal is valid, calling \( \VerifyProposal(v^\prime) \) on \( v^\prime = \Proposal_v(e^\prime) \), and if periods are equal (\( p = p^\prime \)). Both checks pass given the vanilla context assumptions.

Next, if \( e^\prime \in P \), it returns; else the proposal handler re-broadcasts \( e^\prime \), adds \( e^\prime \) to the set \( P \) of stored proposals, and exits.

Vote received from other nodes

Let us now assume that the node received a broadcasted \( \vt \), and that \( 0 < t < \DynamicFilterTimeout(p) \) still holds.

The \( \EventHandler \) for the main algorithm thus calls \( HandleVote(\vt) \). The algorithm exits on failing checks (all passed with the vanilla context assumptions), or if the vote received has already been recorded in the votes set \( V \). If it is a new vote, the node adds it to the votes set \( V \) and broadcasts it to other nodes.

Since nodes are synchronized (by assumption), it holds that \( \vt_s = 0 = \Propose \), so the algorithm checks if \( \RetrieveProposal(\vt_v) \neq \bot \) and broadcasts if it is available, ignore it if not.

Until \( t \ge \DynamicFilterTimeout(p) \) the main algorithm will execute the above steps whenever a vote or a proposal is received.

Filtering (Soft Vote)

Eventually, the node clock reaches \( t = \DynamicFilterTimeout(p) \) (that is, the node observes a \( \EventTimeout \) event for filtering), and the main algorithm calls \( \SoftVote \).

The soft vote procedure selects the highest priority block proposal and votes on it. The node goes through all the votes \( \vt^\prime \in V \) in its votes set which are in the \( \Propose \) step (\( \vt^\prime_s = 0 \)).

Given the \( \c_j \) of player \( I_j \) for the vote \( \vt^\prime_{\c_j} = (w_j, y, \VRF.\ProofToHash(y)) \), the procedure runs a \( \Priority\) function on the vote, as described in the soft vote non-normative section, and keeps track of the one with the highest priority (i.e., the one with the lowest hash).

Next, if there was at least one \( \vt \) in \( V \), for every registered account \( a \in A \) it computes:

$$ (w_j, y, \VRF.\ProofToHash(y)) \gets \c^{\prime\prime} = \Sortition(a, \Soft) $$

and, if \( w_j > 0 \) it broadcasts \( \Vote(r, p, \Soft, v, \c^{\prime\prime}) \).

Moreover, if \( \prop \gets \RetrieveProposal(v) \) is not \( \bot \), it also broadcasts \( \prop \).

Certification

When the node receives a event of type \( \EventProposal \), it runs the \( \HandleProposal \) procedure as before.

Commit

When the node receives a event of type \( \EventVote \), \( \Vote(r, p, \Soft, v, \c) \), it

1. Relays the vote,

2. Adds the vote to the vote set (if new),

3. Checks whether the vote can form a bundle with the votes in \( V \)¹.

After a while, the last condition is met, and a bundle can be formed for the \( \Soft \) step.

When a \( \Soft \) bundle is observed for round \( r \), the node adds the accepted \( r \)-th block to the Ledger, updates its state accordingly, garbage collects the information related \( r \)-th round, and sets the round counter to \( r + 1 \).

In other words, the node:

• Broadcast the proposal if \( \prop \PSnot \in P \),

• Commits \( v \), calling \( \Commit(v) \),

• Sets \( r_\text{old} = r \),

• Calls \( \StartNewRound(r + 1) \),

• \( \GarbageCollect(r_\text{old}, p) \) ending the round.

Starting a new round will reset context variables as follows:

• \( \bar{s} = s \),

• \( \bar{v} = \bot \),

• \( r = r + 1 \),

• \( p = 0 \),

• \( s = \Propose = 0 \).

Calling the garbage collection algorithm will compute:

$$ \begin{aligned} V_{(r, p-1)} & = \{\vt \in V : \vt_r < r \text{ or } (\vt_r = r \text{ and } \vt_p + 1 < p)\} \\ P_{(r, p-1)} & = \{\prop \in P: \prop_r < r \text{ or } (\prop_r = r \text{ and } \prop_p + 1 < p)\} \end{aligned} $$

and then remove these sets from the votes and proposal sets:

• \( V \gets V \setminus V_{(r, p-1)} \),

• \( P \gets P \setminus P_{(r, p-1)} \).

$$ \sum_{\vt \in V} \vt_{\c_j} \ge \CommitteeThreshold(\Soft). $$

1. The node checks if there is a \( \vt_v \), such that for all the \( \vt \in V \) with \( \vt_r = r, \vt_p = 0, \vt_s = \Soft \), the sum of votes’ weights is bigger than the committee threshold: ↩

$$ \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \Sortition {\mathrm{Sortition}} \newcommand \Prop {\mathit{propose}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Next {\mathit{next}} \newcommand \TP {\mathrm{TransactionPool}} $$

Jalapeño Run (Recovery)

Let us now assume a scenario similar to the Vanilla run, with the following difference: on round \( r = i \), when \( s = 2 \), before block commitment, the network experiences a network partitioning. The voting stake is fragmented, and no network partition has enough voting power to certify a block.

timeline
    title Jalapeño Run
    section (r = i, p = 0, 0 <= s <= 1)
        Proposal (s = 0) time = 0                       : Emits proposals for i-th round from selected accounts registered on the node
        Soft Vote (s = 1) time = DynamicTO(p)           : Filters proposals (lowest hash criteria) : Soft vote on the best proposal for round i : A Soft Bundle is observed and a pinned value is enstabilished
    section (r = i, p = 0, s >= 2) Network partition K begins
        Certification (s = 2) time = DeadlineTO(p=0)    : Certification vote fails, no Committe Threshold is reached
        Recovery (s > 3) time > DeadlineTO(p=0)         : Next and Fast Recovery votes triggered
    section (r = i, p = 0, s >= 3) Network partition K ends
        Recovery (s > 3) time > DeadlineTO(p=0)         : Next Bundle observed, new period begins
    section (r = i, p = 1, s = 2)
        Certification (s = 2) time < DeadlineTO(p=1)    : Certification vote of a pinned value
                                                        : Appended i-th block to the Ledger
                                                        : State deltas applied
                                                        : Transaction pool purged

Run

Let us assume the network conditions are those described in the initial context.

Regular Propose and Soft steps

The network starts round \( r \) performing regular \( \Prop \) and \( \Soft \) steps.

Suppose that during the \( \Soft \) step (\( s = 1 \)), a \( \Soft \)-Bundle is observed, therefore a pinned-value \( \bar{v} \) is established on the nodes, and the \( \Cert \) step begins.

Network Partitioning begins: failing Certification step

During the \( \Cert \) step, before the block commitment, the network experiences a partitioning \( K \).

For any two accounts in the certification committee, the nodes playing for them have their connected peers \( K_t \) and \( K_l \), with \( t \neq l \).

Given the proposed network graph, players reach \( \DeadlineTimeout(p = 0) \) without a committable block proposal (that is, no \( \Cert \)-Bundle supporting any proposal-value has been observed).

Recovery

The protocol enters into recovery mode, and several \( \Next \) votes and fast recovery votes sessions happen, without any of them being able to form a Bundle for a value, due to the persisting network partition.

Suppose now that after a given time, connections are restored and \( K \) is solved. For any two accounts in the certification committee, the nodes in which they are registered are part of the same (unique) network. In other words, this time \( K_t = K_l \) for all nodes whose managed accounts are chosen by \( \Sortition \) procedure to vote in a step \( s = \Next_h \), with \( 3 \leq h < 248 \).

Since during \( \Soft \) step (\( s = 1 \)), before the network partitioning occurred, a \( \Soft \)-Bundle had been observed, causing a pinned-value \( \bar{v} \) to be established on the nodes. Therefore, all selected players vote on this pinned-value, and a \( \Next_h \) Bundle is observed for \( \bar{v} \).

Network Partitioning ends: new period

The protocol agrees to move into the next period \( p = 1 \), garbage collects old period (\( p = 0 \)) data, and restarts from \( s = \Prop = 0 \).

Since there is already an agreed-upon value \( \bar{v} \), there are no proposals and the protocol moves quickly into \( \Soft \) and then \( \Cert \) votes.

This time the network is sufficiently connected to observe a \( \Cert \)-Bundle for \( \bar{v} \) and so, before \( \DeadlineTimeout(p = 1) \), the network is able to reach an agreement, and a new block is committed in the same way as in the Vanilla run; advancing the network into the new round.

$$ \newcommand \DynamicFilterTimeout {\mathrm{DynamicFilterTimeout}} \newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}} \newcommand \Prop {\mathit{propose}} \newcommand \Soft {\mathit{soft}} \newcommand \Cert {\mathit{cert}} \newcommand \Late {\mathit{late}} \newcommand \Redo {\mathit{redo}} \newcommand \Down {\mathit{down}} \newcommand \Next {\mathit{next}} $$

Habanero Run (Fast Recovery)

Let us now assume a scenario identical to the Japlapeño run, up until the attempt at period \( p = 1 \) to form a \( \Cert \)-Bundle for the pinned value.

In this scenario, a consensus-stalling network partition happens again, which lasts more than 5 minutes (i.e., \( \lambda_f \)).

timeline
    title Habanero Run
    section (r = i, p = 0, 0 <= s <= 1)
        Proposal (s = 0) time = 0                       : Emits proposals for i-th round from selected accounts registered on the node
        Soft Vote (s = 1) time = DynamicTO(p)           : Filters proposals (lowest hash criteria) : Soft vote on the best proposal for round i
    section (r = i, p = 0, s >= 2) Network partition K begins
        Certification (s = 2) time = DeadlineTO(p=0)    : Certification vote fails, no Committe Threshold is reached
        Recovery (s > 3) time > DeadlineTO(p=0)         : Next and Fast Recovery votes triggered : No Next bundle is observed
    section (r = i, p = 0, s >= 3) Network partition K ends
        Recovery (s > 3) time > DeadlineTO(p=0)         : Next Bundle observed, new period begins
    section (r = i, p = 1, s = [253, 254, 255])
        Fast Recovery (s = 253) time = lambda_f         : Late step fails
        Fast Recovery (s = 254)                         : Redo step fails
        Fast Recovery (s = 255)                         : Down Bundle observed, new period begins
    section (r = i, p = 2, 0 <= s <= 2)
        Proposal (s = 0) time = 0                       : Emits proposals for i-th round from selected accounts registered on the node
        Soft Vote (s = 1) time = DynamicTO(p=2)         : Filters proposals (lowest hash criteria) : Soft vote on the best proposal for round i
        Certification (s = 2) time < DeadlineTO(p=2)    : Certification vote of a pinned value
                                                        : Appended i-th block to the Ledger
                                                        : State deltas applied
                                                        : Transaction pool purged

Run

Let us assume the network conditions are those described in the initial context.

In addition to the initial context:

• The network successfully performed \( \Prop \) and \( \Soft \) steps for round \( r \),

• During the \( \Cert \) step, before the block commitment, the network experiences a partitioning \( K \) (as described in the Jalapeno run),

• Players reach \( \DeadlineTimeout(p = 0) \) without a committable block proposal (that is, no \( \Cert \)-Bundle supporting any proposal-value has been observed).

Fast Recovery

Under these conditions, a \( \Cert \)-Bundle is not formed and the protocol enters in partition recovery mode.

Now, after connections are reestablished, a \( \Next \)-Bundle for a new period \( p = 1 \) is observed, and a fast recovery is about to take place (when the node’s clock is equal to \( \lambda_f \)).

In this scenario, however, differently from the Jalapeño run, most players have lost the previously observed pinned value, or have since seen \( \Soft \)-Bundle for different values. Therefore, no consensus on a bundle going into the period \( p = 2 \) certification is possible.

In this case, after failing to form \( \Late \) and \( \Redo \) bundles, a \( \Down \)-Bundle is observed by a majority of players (an “agree to disagree” with value \( \bot \)).

Players move into a period \( p = 2 \), this time with no “carry over” information from the previous consensus attempt.

In this scenario, the whole protocol is rerun (a reproposal ensues). The rest of the scenario is similar to the Vanilla run, save for different timeout values for \( DynamicFilterTimeout(p = 2) \) and \( DeadlineTimeout(p = 2) \), the protocol goes over \( \Prop \), \( \Soft \) and \( \Cert \) steps in the same fashion.

However, in this case, the network partition has been solved, so a block commitment ensues before \( \DeadlineTimeout(p = 2) \).

Ledger Overview

This part describes the Algorand Ledger, which records the history and the state of the distributed system, defining its entities (e.g., blocks, transactions, accounts, assets, applications, etc.).

It also covers the processes of ingesting, verifying, prioritizing, and enqueuing transactions in the transaction pool, and finally assembly and appending blocks to commit their state transition.

Algorand Ledger State Machine Specification

Algorand replicates a state and the state’s history between protocol participants.

This state and its history are called the Algorand Ledger.

$$ \newcommand \BonusBaseAmount {B_{b,\mathrm{base}}} \newcommand \BonusBaseRound {B_{b,\mathrm{start}}} \newcommand \BonusDecayInterval {B_{b,\mathrm{decay}}} \newcommand \MaxTimestampIncrement {\Delta t_{\max}} \newcommand \MaxTxnBytesPerBlock {B_{\max}} \newcommand \MaxVersionStringLen {V_{\max}} \newcommand \Heartbeat {\mathrm{hb}} \newcommand \Fee {\mathrm{fee}} \newcommand \PayoutsChallengeBits {\Heartbeat_\mathrm{bits}} \newcommand \PayoutsChallengeGracePeriod {\Heartbeat_\mathrm{grace}} \newcommand \PayoutsChallengeInterval {\Heartbeat_r} \newcommand \PayoutsGoOnlineFee {B_{p,\Fee}} \newcommand \AccountMinBalance {A_{b,\min}} \newcommand \DefaultUpgradeWaitRounds {\delta_x} \newcommand \MaxUpgradeWaitRounds {\delta_{x_{\max}}} \newcommand \MinUpgradeWaitRounds {\delta_{x_{\min}}} \newcommand \UpgradeThreshold {\tau} \newcommand \UpgradeVoteRounds {\delta_d} \newcommand \RewardUnit {U_r} \newcommand \RewardsRateRefreshInterval {\omega_r} \newcommand \StateProof {\mathrm{SP}} \newcommand \StateProofInterval {\delta_\StateProof} \newcommand \StateProofVotersLookback {\delta_{\StateProof,b}} \newcommand \StateProofTopVoters {N_\StateProof} \newcommand \StateProofStrengthTarget {KQ_\StateProof} \newcommand \StateProofMaxRecoveryIntervals {I_\StateProof} \newcommand \StateProofWeightThreshold {f_\StateProof} \newcommand \MinTxnFee {T_{\Fee,\min}} \newcommand \MaxTxnLife {T_{\Delta r,\max}} \newcommand \MaxTxnNoteBytes {T_{m,\max}} \newcommand \MaxTxGroupSize {GT_{\max}} \newcommand \MaxKeyregValidPeriod {K_{\Delta r,\max}} \newcommand \MaxTxTail {\mathrm{TxTail}_{\max}} $$

$$ \newcommand \MinBalance {b_{\min}} \newcommand \Asset {\mathrm{Asa}} \newcommand \MaxAssetDecimals {\Asset_{d,\max}} \newcommand \MaxAssetNameBytes {\Asset_{n,\max}} \newcommand \MaxAssetUnitNameBytes {\Asset_{u,\max}} \newcommand \MaxAssetURLBytes {\Asset_{r,\max}} \newcommand \LogicSig {\mathrm{LSig}} \newcommand \LogicSigMaxCost {\LogicSig_{c,\max}} \newcommand \LogicSigMaxSize {\LogicSig_{\max}} \newcommand \LogicSigVersion {\LogicSig_{V}} \newcommand \MaxProposedExpiredOnlineAccounts {B_{N_\mathrm{e},\max}} \newcommand \PayoutMaxMarkAbsent {B_{N_\mathrm{a},\max}} \newcommand \PayoutsMaxBalance {A_{r,\max}} \newcommand \PayoutsMinBalance {A_{r,\min}} \newcommand \PayoutsPercent {B_{p,\%}} \newcommand \App {\mathrm{App}} \newcommand \AppFlatOptInMinBalance {\App_{\mathrm{optin},\MinBalance}} \newcommand \AppFlatParamsMinBalance {\App_{\mathrm{create},\MinBalance}} \newcommand \Box {\mathrm{Box}} \newcommand \BoxByteMinBalance {\Box_{\mathrm{byte},\MinBalance}} \newcommand \BoxFlatMinBalance {\Box_{\mathrm{flat},\MinBalance}} \newcommand \BytesPerBoxReference {\Box_{\mathrm{IO}}} \newcommand \MaxBoxSize {\Box_{\max}} \newcommand \MaxAppArgs {\App_{\mathrm{arg},\max}} \newcommand \MaxAppBoxReferences {\App_{\Box,\max}} \newcommand \MaxAppBytesValueLen {\App_{\mathrm{v},\max}} \newcommand \MaxAppKeyLen {\App_{\mathrm{k},\max}} \newcommand \MaxAppProgramCost {\App_{c,\max}} \newcommand \MaxAppProgramLen {\App_{\mathrm{prog},\max}} \newcommand \MaxAppSumKeyValueLens {\App_{\mathrm{kv},\max}} \newcommand \MaxAppTotalArgLen {\App_{\mathrm{ay},\max}} \newcommand \MaxAppTotalProgramLen {\App_{\mathrm{prog},t,\max}} \newcommand \MaxAppTotalTxnReferences {\App_{r,\max}} \newcommand \MaxAppTxnAccounts {\App_{\mathrm{acc},\max}} \newcommand \MaxAppTxnForeignApps {\App_{\mathrm{app},\max}} \newcommand \MaxAppTxnForeignAssets {\App_{\mathrm{asa},\max}} \newcommand \MaxAppAccess {\App_{\mathrm{access},\max}} \newcommand \MaxExtraAppProgramPages {\App_{\mathrm{page},\max}} \newcommand \MaxGlobalSchemaEntries {\App_{\mathrm{GS},\max}} \newcommand \MaxLocalSchemaEntries {\App_{\mathrm{LS},\max}} \newcommand \MaxInnerTransactions {\App_\mathrm{itxn}} \newcommand \SchemaBytesMinBalance {\App_{\mathrm{b},\MinBalance}} \newcommand \SchemaMinBalancePerEntry {\App_{\mathrm{s},\MinBalance}} \newcommand \SchemaUintMinBalance {\App_{\mathrm{u},\MinBalance}} $$

$$ \newcommand \Account {\mathrm{Acc}} \newcommand \MaxAssetsPerAccount {\Account_{\Asset,\max}} \newcommand \MaxAppsCreated {\Account_{\App,\max}} \newcommand \MaxAppsOptedIn {\Account_{\App,optin,\max}} \newcommand \MaximumMinimumBalance {\mathrm{MBR}_{\max}} \newcommand \DefaultKeyDilution {\mathrm{KeyDilution}} $$

Parameters

The Algorand Ledger is parameterized by the values in the following tables.

For each parameter, the tables provide the reference implementation name and the last update version, to facilitate the match of the specifications and the implementation.

Block

Block Rewards

Protocol Upgrade

State Proof

Transaction

Account

Asset

LogicSig

Application

1. \( \StateProofStrengthTarget = 256 \) is the value set for State Proofs of type \(0 \). Other types of State Proofs might be added in the future. \( \StateProofStrengthTarget = \mathrm{target_{PQ}} \) is set to achieve post-quantum security for State Proof. For further details, refer to the State Proofs normative specification. ↩

$$ \newcommand \MaxTxTail {\mathrm{TxTail}_{\max}} \newcommand \App {\mathrm{App}} \newcommand \Box {\mathrm{Box}} $$

States

A Ledger (\( L \)) is a sequence of states which comprise the common information established by some instantiation of the Algorand protocol.

A Ledger is identified by a string called the genesis identifier, as well as a genesis hash that cryptographically commits to the starting state of the Ledger.

Each state consists of the following components:

• The round of the state, which indexes into the Ledger’s sequence of states.

• The genesis identifier and genesis hash, which identify the Ledger to which the state belongs.

• The current protocol version and the upgrade state.

• A timestamp, which is informational and identifies when the state was first proposed.

• A seed, which is a source of randomness used to establish consensus on the next state.

• The current reward state, which describes the policy at which incentives are distributed to participants.

• The current account state, which holds account balances and participation keys for all stakeholding addresses.

  • One component of this state is the transaction tail, which caches the transaction sets (see below) in the last \( \MaxTxTail \) blocks.

• The current box state, which holds mappings from (\( \App_{ID} \), \( \Box_{ID} \)) tuples to box contents of arbitrary bytes.

$$ \newcommand \BonusDecayInterval {B_{b,\mathrm{decay}}} \newcommand \MaxProposedExpiredOnlineAccounts {B_{N_\mathrm{e},\max}} \newcommand \MinBalance {b_{\min}} \newcommand \PayoutsMaxBalance {A_{r,\max}} \newcommand \PayoutsMinBalance {A_{r,\min}} \newcommand \Heartbeat {\mathrm{hb}} \newcommand \PayoutsChallengeBits {\Heartbeat_\mathrm{bits}} \newcommand \PayoutsChallengeGracePeriod {\Heartbeat_\mathrm{grace}} \newcommand \PayoutsChallengeInterval {\Heartbeat_r} \newcommand \PayoutMaxMarkAbsent {B_{N_\mathrm{a},\max}} $$

Blocks

A block is a data structure that specifies the transition between states.

The data in a block is divided between the block header and its block body.

Block Header

The block header contains the following components:

Round

The block’s round, which matches the round of the state it is transitioning into. (The block with round \( 0 \) is special in that this block specifies not a transition but rather the entire initial state, which is called the genesis state. This block is correspondingly called the genesis block). The round is stored under msgpack key rnd.

Genesis Identifier

The block’s genesis identifier and genesis hash, which match the genesis identifier and hash of the states it transitions between (i.e., they stay constant since the initial state forwards). The genesis identifier is stored under msgpack key gen, and the genesis hash is stored under msgpack key gh.

Upgrade Vote

The block’s upgrade vote, which results in the new upgrade state. The block also duplicates the upgrade state of the state it transitions into. The msgpack representations of the upgrade vote components are described in detail below.

Timestamp

The block’s timestamp, which matches the timestamp of the state it transitions into. The timestamp is stored under msgpack key ts.

Seed

The block’s seed, which matches the seed of the state it transitions into. The seed is stored under msgpack key seed.

Reward Updates

The block’s reward updates, which results in the new reward state. The block also duplicates the reward state of the state it transitions into. The msgpack representations of the reward updates components are described in detail below.

Transaction Commitments

Cryptographic commitments to the block’s transaction sequence, described below (referred also as payset), using:

• SHA-512/256 hash function, stored under msgpack key txn;

• SHA-256 hash function, stored under msgpack key txn256;

• SHA512 hash function, stored under msgpack key txn512.

Previous Hash

The block’s previous hash, which is the cryptographic hash of the previous Block Header in the sequence, using:

• SHA-512/256 hash function, stored under msgpack key prev;

• SHA512 hash function, stored under msgpack key prev512.

The previous hash of the genesis block is \( 0 \)).

Transaction Counter

The block’s transaction counter, which is the total number of transactions issued prior to this block. This count starts from the first block with a protocol version that supports the transaction counter. The counter is stored in msgpack field tc.

Proposer

The block’s proposer, which is the address of the account that proposed the block. The proposer is stored in msgpack field prp.

Fees Collected

The block’s fees collected is the sum of all fees paid by transactions in the block and is stored in msgpack field fc.

Bonus

The potential bonus incentive is the amount, in μALGO, that may be paid to the proposer of this block beyond the amount available from fees. It is stored in msgpack field bi. It may be set during a consensus upgrade, or else it must be equal to the value from the previous block in most rounds, or be \( 99 \% \) of the previous value (rounded down) if the round of this block is \( 0 \mod \BonusDecayInterval \).

Proposer Payout

The proposer payout is the actual amount that is moved from the \( I_f \) to the proposer, and is stored in msgpack field pp. If the proposer is not eligible, as described below, the proposer payout MUST be \( 0 \). The proposer payout MUST NOT exceed

• The sum of the bonus incentive and half of the fees collected.
• The fee sink balance minus \( \MinBalance \).

Expired Participation Accounts

The block’s expired participation accounts, which contains an optional list of account addresses. These accounts’ participation key expire by the end of the current round, with exact rules below. The list is stored in msgpack key partupdrmv.

Suspended Participation Accounts

The block’s suspended participation accounts, which contains an optional list of account addresses. These accounts have not recently demonstrated that they are available and participating, with exact rules below. The list is stored in msgpack key partupdabs.

A proposer is eligible for bonus payouts if the account’s IncentiveEligible flag is true and its online balance is between \( \PayoutsMinBalance \) and \( \PayoutsMaxBalance \).

The expired participation accounts list is valid as long as:

• The participation keys of all the accounts in the slice are expired by the end of the round;

• The accounts themselves would have been online at the end of the round if they were not included in the list;

• The number of elements in the list is less than or equal to \( \MaxProposedExpiredOnlineAccounts \). A block proposer may not include all such accounts in the list and may even omit the list completely.

The suspended participation accounts list is valid if, for each included address, the account is:

• Online;
• Incentive eligible;
• Either absent or failing a challenge as of the current round.

An account is absent if its LastHeartbeat and LastProposed rounds are both more than \( 20n \) rounds before current, where \( n \) is the reciprocal of the account’s fraction of online stake.

An account is failing a challenge if:

• The first \( \PayoutsChallengeBits \) bits of the account’s address matches the first \( \PayoutsChallengeBits \) bits of an active challenge round’s block seed;
• The active challenge round is between \( \PayoutsChallengeGracePeriod \) and \( 2\PayoutsChallengeGracePeriod \) rounds before the current round.

An active challenge round is a round that is \( 0 \mod \PayoutsChallengeInterval \).

The length of the list MUST not exceed \( \PayoutMaxMarkAbsent \).

A block proposer MAY NOT include all such accounts in the list and MAY even omit the list completely.

Block Body

The block body is the block’s transaction sequence (also known as payset), which describes the sequence of updates (transactions) to the account state and box state.

Block Validity

A block is valid if each component is also valid. (The genesis block is always valid).

Applying a valid block to a state produces a new state by updating each of its components.

The rest of this document defines block validity and state transitions by describing them for each component.

Round

The round or round number is a 64-bit unsigned integer that indexes into the sequence of states and blocks.

The round \( r \) of each block is one greater than the round of the previous block (\( r_i = r_{i-1} + 1 \)).

Given a Ledger \( L \), the round of a block exclusively identifies it.

The rest of this document describes components of states and blocks with respect to some implicit Ledger. Thus, the round exclusively describes some component, and we denote the round of a component with a subscript. For instance, the timestamp of state/block \( r \) is denoted \( t_r \).

$$ \newcommand \Genesis {\mathrm{Genesis}} \newcommand \GenesisID {\Genesis{\mathrm{ID}}} \newcommand \Hash {\mathrm{Hash}} \newcommand \GenesisHash {\Genesis\Hash} $$

Genesis

Genesis Identifier

The genesis identifier is a short string that identifies an instance of a Ledger \( L \).

The genesis identifier of a valid block is the identifier of the block in the previous round. In other words, \( \GenesisID_{r+1} = \GenesisID_{r} \).

Genesis Hash

The genesis hash is a cryptographic hash of the genesis configuration, used to unambiguously identify an instance of the Ledger \( L \).

The genesis hash is set in the genesis block (or the block at which an upgrade to a protocol supporting \( \GenesisHash \) occurs), and MUST be preserved identically in all subsequent blocks.

$$ \newcommand \Prev {\mathrm{Prev}} \newcommand \Hash {\mathrm{Hash}} $$

Previous Hash

The previous hash is a cryptographic hash of the previous block header in the sequence of blocks.

The sequence of previous hashes in each block header forms an authenticated, linked-list of the reversed sequence.

Let \( B_r \) represent the block header in round \( r \), and let \( \Hash \) be some cryptographic hash function.

Then the previous hash \( \Prev_{r+1} \) in the block for round \( r+1 \) is \( \Prev_{r+1} = \Hash(B_r) \).

In the reference implementation, \( \Hash \) is the SHA512/256 hash function.

$$ \newcommand \MaxVersionStringLen {V_{\max}} \newcommand \DefaultUpgradeWaitRounds {\delta_x} \newcommand \MaxUpgradeWaitRounds {\delta_{x_{\max}}} \newcommand \MinUpgradeWaitRounds {\delta_{x_{\min}}} \newcommand \UpgradeThreshold {\tau} \newcommand \UpgradeVoteRounds {\delta_d} $$

Protocol Upgrade State

A protocol version \( v \) is a string no more than \( \MaxVersionStringLen \) bytes long. It corresponds to parameters used to execute some version of the Algorand protocol.

The upgrade vote in each block consists of:

• A protocol version \( v_r \);
• A 64-bit unsigned integer \( x_r \) which indicates the delay between the acceptance of a protocol version and its execution;
• A single bit \( b \) indicating whether the block proposer supports the given protocol version.

The upgrade state in each block/state consists of:

• The current protocol version \( v_r^{\ast} \);
• The next proposed protocol version \( v_r^{\prime} \);
• A 64-bit round number \( s_r \) counting the number of votes for the next protocol version;
• A 64-bit round number \( d_r \) specifying the deadline for voting on the next protocol version;
• A 64-bit round number \( x_r^{\prime} \) specifying when the next proposed protocol version would take effect, if passed.

An upgrade vote \( (v_r, x_r, b) \) is valid given the upgrade state \( (v_r^{\ast}, v_r^{\prime}, s_r, d_r, x_r^{\prime}) \) if \( v_r \) is the empty string or \( v_r^{\prime} \) is the empty string, \( \MinUpgradeWaitRounds \leq x_r \leq \MaxUpgradeWaitRounds \), and either:

• \( b = 0 \) or
• \( b = 1 \) with \( r < d_r \) and either
  • \( v_r^{\prime} \) is not the empty string or
  • \( v_r \) is not the empty string.

If the vote is valid, then the new upgrade state is

$$ (v_{r+1}^{\ast}, v_{r+1}^{\prime}, s_{r+1}, d_{r+1}, x_{r+1}) $$

Where

• \( v_{r+1}^{\ast} \) is \( v_r^{\prime} \) if \( r = x_r^{\prime} \) and \( v_r^{\ast} \) otherwise.

• \( v^{\prime}_{r+1} \) is

  • the empty string if \( r = x_r^{\prime} \) or both \( r = s_r \) and \( s_r + b < \UpgradeThreshold \),
  • \( v_r \) if \( v_r^{\prime} \) is the empty string, and
  • \( v_r^{\prime} \) otherwise.

• \( s_{r+1} \) is

  • \( 0 \) if \( r = x_r^{\prime} \) or both \( r = s_r \) and \( s_r + b < \UpgradeThreshold \), and
  • \( s_r + b \) otherwise

• \( d_{r+1} \) is

  • \( 0 \) if \( r = x_r^{\prime} \) or both \( r = s_r \) and \( s_r + b < \UpgradeThreshold \),
  • \( r + \UpgradeVoteRounds \) if \( v_r^{\prime} \) is the empty string and \( v_r \) is not the empty string, and
  • \( d_r \) otherwise.

• \( x_{r+1} \) is

  • \( 0 \) if \( r = x_r^{\prime} \) or both \( r = s_r \) and \( s_r + b < \UpgradeThreshold \),
  • \( r + \UpgradeVoteRounds + \delta \) if \( v_r^{\prime} \) is the empty string and \( v_r \) is not the empty string (where \( \delta = \DefaultUpgradeWaitRounds \) if \( x_r = 0 \) and \( \delta = x_r \) if \( x_r \neq 0 \)), and
  • \( x_r^{\prime} \) otherwise.

$$ \newcommand \MaxTimestampIncrement {\Delta t_{\max}} $$

Timestamp

The timestamp \( t \) is a 64-bit signed integer.

The timestamp is purely informational and states when a block was first proposed, expressed in the number of seconds since the Unix epoch (00:00:00 UTC on Thursday, 1 January 1970).

The timestamp \( t_{r+1} \) of a block in round \( r \) is valid if:

• \( t_{r} = 0 \) or
• \( t_{r+1} > t_{r} \) and \( t_{r+1} < t_{r} + \MaxTimestampIncrement \).

📎 EXAMPLE

Suppose the block production stalls on round \( r \) for a prolonged time. When correct operations resume, a certain number \( n \) of blocks has to be committed until the timestamp catches up to external time references. If \( t^{\ast} \) is the current external time reference, then:

$$ n = \left\lceil \frac{t^{\ast} - t_{r}}{\MaxTimestampIncrement} \right\rceil $$

$$ \newcommand \Seed {\mathrm{Seed}} $$

Cryptographic Seed

The seed is a 256-bit integer.

Seeds are validated and updated according to the specification of the Algorand Byzantine Fault Tolerance protocol.

The \( \Seed \) procedure specified there returns the seed from the desired round.

$$ \newcommand \Tx {\mathrm{Tx}} \newcommand \TxID {\Tx\mathrm{ID}} \newcommand \TxSeq {\Tx\mathrm{Seq}} \newcommand \TxCommit {\Tx\mathrm{Commit}} \newcommand \TxTail {\Tx\mathrm{Tail}} \newcommand \Hash {\mathrm{Hash}} \newcommand \SHATFS {\mathrm{SHA256}} \newcommand \SHAFOT {\mathrm{SHA512}} \newcommand \Sig {\mathrm{Sig}} \newcommand \STIB {\mathrm{STIB}} \newcommand \Genesis {\mathrm{Genesis}} \newcommand \GenesisID {\Genesis{\mathrm{ID}}} \newcommand \GenesisHash {\Genesis\Hash} \newcommand \ApplyData {\mathrm{ApplyData}} \newcommand {\abs}[1] {\lvert #1 \rvert} \newcommand \MaxTxnBytesPerBlock {B_{\max}} \newcommand \MaxTxTail {\mathrm{TxTail}_{\max}} $$

Transaction Sequences, Sets, and Tails

Transaction Sequence

Each block contains a transaction sequence, an ordered sequence of transactions in that block.

The transaction sequence of block \( r \) is denoted \( \TxSeq_r \).

Each valid block contains a transaction commitment \( \TxCommit_r \) which is a Merkle Tree Commitment to this sequence.

The leaves in the Merkle Tree are hashed as:

$$ \Hash(\texttt{TL}, \TxID, \Hash(\STIB)) $$

Where:

• \( \Hash \) is the cryptographic SHA-512-256 hash function;

• The \( \TxID \) is the 32-byte transaction identifier;

• The \( \Hash(\STIB) \) is a 32-byte hash of the signed transaction and ApplyData for the transaction, hashed with the domain-separation prefix STIB (signed transaction in block).

Signed transactions in a block \( \STIB \) are encoded in a slightly different way than standalone transactions \( \Tx \), for efficiency:

If a standalone transaction \( \Tx \) contains a \( \GenesisID \) value, then:

• The transaction’s \( \GenesisID \) MUST match the block’s \( \GenesisID \);

• The transaction’s \( \GenesisID \) value MUST be omitted from the \( \STIB \) transaction’s msgpack encoding in the block;

• The \( \STIB \) transaction’s msgpack encoding in the block MUST indicate the \( \GenesisID \) value was omitted by including a key hgi with the boolean value True.

Since transactions MUST include a \( \GenesisHash \) value, the \( \GenesisHash \) value of each transaction in a block MUST match the block’s \( \GenesisHash \), and the \( \GenesisHash \) value is omitted from the \( \STIB \) transaction as encoded in a block.

• Signed transactions in a block are also augmented with the \( \ApplyData \) that reflect how that transaction was applied to the Account State.

The transaction commitment (\( \TxCommit \)) for a block covers the transaction encodings with the changes described above.

Individual transaction signatures cover the original encoding of transactions as standalone transactions (\( \Tx \)).

In addition to the transaction commitment, each block contains SHA-256 and SHA-512 transaction commitments. They allow a verifier not supporting SHA-512/256 function to verify proof of membership for transactions.

To construct these commitments, we use a Vector Commitment.

The leaves in the Vector Commitment tree are hashed respectively as:

$$ \SHATFS(\texttt{TL}, \SHATFS(\TxID), \SHATFS(\STIB)) $$

and

$$ \SHAFOT(\texttt{TL}, \SHAFOT(\TxID), \SHAFOT(\STIB)) $$

Where:

• \( \SHATFS \) is the cryptographic SHA-256 hash function;

• \( \SHATFS(\TxID) = \SHATFS(\texttt{TX} || \Tx) \)

• \( \SHATFS(\STIB) = \SHATFS(\texttt{STIB} || \Sig(\Tx) || \ApplyData) \)

• \( \SHAFOT \) is the cryptographic SHA-512 hash function;

• \( \SHAFOT(\TxID) = \SHAFOT(\texttt{TX} || \Tx) \)

• \( \SHAFOT(\STIB) = \SHAFOT(\texttt{STIB} || \Sig(\Tx) || \ApplyData) \)

These Vector Commitments use SHA-256 and SHA-512 for internal nodes as well.

A valid transaction sequence \( \TxSeq \) contains no duplicates: each transaction in the transaction sequence MUST appear exactly once.

We can call the set of these transactions the transaction set (for convenience, we may also write \( \TxSeq_r \) to refer unambiguously to the set in this block).

For a block to be valid, its transaction sequence \( \TxSeq_r \) MUST be valid (i.e., no duplicate transactions may appear there).

All transactions have a size in bytes. The size of the transaction \( \Tx \) is denoted \( \abs{\Tx} \).

For a block to be valid, the sum of the sizes of each transaction in a transaction sequence MUST NOT exceed \( \MaxTxnBytesPerBlock \); in other words:

$$ \sum_{\Tx \in \TxSeq_r} \abs{\Tx} \leq \MaxTxnBytesPerBlock $$

Transaction Tails

The transaction tail \( \TxTail \) for a given round \( r \) is a set produced from the union of the transaction identifiers \( \TxID \) of each transaction in the last \( \MaxTxTail \) transaction sets and is used to detect duplicate transactions.

In other words,

$$ \TxTail_r = \bigcup_{r-\MaxTxTail \leq s \leq r-1} {\Hash(\Tx) | \Tx \in \TxSeq_s}. $$

As a result, the transaction tail for round \( r+1 \) is computed as follows:

$$ \TxTail_{r+1} = \TxTail_r \setminus {\Hash(\Tx) | \Tx \in \TxSeq_{r-T_{\max}}} \cup {\Hash(\Tx) | \Tx \in \TxSeq_r}. $$

The transaction tail is part of the Ledger state but is distinct from the account state and is not committed to in the block.

$$ \newcommand \Record {\mathrm{Record}} \newcommand \PartKey {\mathrm{PartKey}} \newcommand \Eligibility {\mathrm{A_e}} \newcommand \Stake {\mathrm{Stake}} \newcommand \Units {\mathrm{Units}} $$

Account State

The balances are a set of mappings from addresses, 256-bit integers, to balance records.

A balance record contains the following fields:

• The account raw balance in μALGO,
• The account status,
• The block incentive eligibility flag,
• The account last_proposed round,
• The account last_heartbeat round,
• The account rewards base and total awarded amount in μALGO,
• The account spending key,
• The account participation keys.

In the rest of this section, all references to Reward calculation are with respect to the legacy distribution rewards system. They are kept here for completeness and for backward compatibility.

The account raw balance \( a_I \) is a 64-bit unsigned integer which determines how much μALGO the address has.

The account rewards base \( a^\prime_I \) and total-awarded amount \(a^\ast_I \) are 64-bit unsigned integers.

Combined with the account balance, the reward base and total awarded amount are used to distribute rewards to accounts lazily.

The account stake is a function which maps a given account and round to the account’s balance in that round and is defined as follows:

$$ \Stake(r, I) = a_I + (T_r - a^\ast_I) \left\lfloor \frac{a_I}{A} \right\rfloor $$

unless \( p_I = 2 \) (see below), in which case:

$$ \Stake(r, I) = a_I $$

\( \Units(r) \) is a function that computes the total number of whole earning units present in a system at round \( r \).

A user owns \( \left\lfloor \frac{a_I}{A} \right\rfloor \) whole earning units, so the total number of earning units in the system is:

$$ \Units(r) = \sum_I \left\lfloor \frac{a_I}{A} \right\rfloor $$

for the \( a_I \) corresponding to round \( r \).

In this sum, online and offline accounts are taken into consideration.

The account status \( p_I \) is an 8-bit unsigned integer which is either \( 0, 1, 2 \):

• A status of 0 corresponds to an offline account,
• A status of 1 corresponds to an online account,
• A status of 2 corresponds to a non-participating account.

Combined with the account stake, the account status determines how much voting stake an account has, which is a 64-bit unsigned integer defined as follows:

• The account balance, if the account is online.
• 0 otherwise.

The account’s spending key determines how transactions from this account must be authorized (e.g., what public key to verify transaction signatures against).

Transactions from this account must have this value (or, if this value zero, the account’s address) as their authorization address. This is described in the Authorization and Signatures section.

The account’s participation keys \( \PartKey \) are defined in Algorand’s specification of participation keys.

The account’s eligibility \( \Eligibility \) is a flag that determines whether the account has elected to receive payouts for proposing blocks (assuming it meets balance requirements at the time of block proposal).

An account’s participation keys and voting stake from a recent round is returned by the \( \Record \) procedure in the Byzantine Agreement Protocol.

There exist two special addresses:

• \( I_\mathrm{pool} \), the address of the incentive pool,

• \( I_f \), the address of the fee sink.

For both of these accounts, \( p_I = 2 \).

$$ \newcommand \App {\mathrm{App}} \newcommand \MaxAppProgramCost {\App_{c,\max}} \newcommand \ExtraProgramPages {\mathrm{ExtraProgramPages}} \newcommand \MaxGlobalSchemaEntries {\App_{\mathrm{GS},\max}} \newcommand \MaxLocalSchemaEntries {\App_{\mathrm{LS},\max}} \newcommand \MaxAppTotalProgramLen {\App_{\mathrm{prog},t,\max}} \newcommand \MaxExtraAppProgramPages {\App_{\mathrm{page},\max}} \newcommand \MinBalance {b_{\min}} \newcommand \AppFlatOptInMinBalance {\App_{\mathrm{optin},\MinBalance}} \newcommand \AppFlatParamsMinBalance {\App_{\mathrm{create},\MinBalance}} \newcommand \MaxAppKeyLen {\App_{\mathrm{k},\max}} \newcommand \SchemaBytesMinBalance {\App_{\mathrm{b},\MinBalance}} \newcommand \SchemaMinBalancePerEntry {\App_{\mathrm{s},\MinBalance}} \newcommand \SchemaUintMinBalance {\App_{\mathrm{u},\MinBalance}} \newcommand \Box {\mathrm{Box}} \newcommand \MaxBoxSize {\Box_{\max}} \newcommand \BoxByteMinBalance {\Box_{\mathrm{byte},\MinBalance}} \newcommand \BoxFlatMinBalance {\Box_{\mathrm{flat},\MinBalance}} $$

Applications

Each account can create applications, each named by a globally-unique 64-bit unsigned integer (the application ID).

Applications are associated with a set of application parameters, which can be encoded as a msgpack struct:

• A mutable stateful “Approval” program (ApprovalProgram), whose result determines whether an ApplicationCall transaction referring to this application ID is to be allowed. This program executes for all ApplicationCall transactions referring to this application ID except for those whose OnCompletion == ClearState, in which case the ClearStateProgram is executed instead. This program may modify the local or global state associated with this application. This field is encoded with msgpack field approv.

  • For AVM Version 3 or lower, the program’s cost as determined by the Stateful Check function MUST NOT exceed \( \MaxAppProgramCost \).

  • For AVM Version 4 or higher programs, the program’s cost during execution MUST NOT exceed \( \MaxAppProgramCost \).

• A mutable stateful “Clear State” program (ClearStateProgram), executed when an opted-in user forcibly removes the local application state associated with this application from their account data. This happens when an ApplicationCall transaction referring to this application ID is executed with OnCompletion == ClearState. This program, when executed, is not permitted to cause the transaction to fail. This program may modify the local or global state associated with this application. This field is encoded with msgpack field clearp.

  • For AVM Version 3 or lower, the program’s cost as determined by the Stateful Check function MUST NOT exceed \( \MaxAppProgramCost \).

  • For AVM Version 4 or higher programs, the program’s cost during execution MUST NOT exceed \( \MaxAppProgramCost \).

• An immutable “global state schema” (GlobalStateSchema), which sets a limit on the size of the global Key/Value Store that may be associated with this application (see State Schemas). This field is encoded with msgpack field gsch.

  • The maximum number of values that this schema may permit is \( \MaxGlobalSchemaEntries \).

• An immutable “local state schema” (LocalStateSchema), which sets a limit on the size of a Key/Value Store that this application will allocate in the account data of an account that has opted in (see “State Schemas”). This field is encoded with msgpack field lsch.

  • The maximum number of values that this schema may permit is \( \MaxLocalSchemaEntries \).

• An immutable “extra pages” value (ExtraProgramPages), which limits the total size of the application programs. The sum of the lengths of ApprovalProgram and ClearStateProgram may not exceed \( \MaxAppTotalProgramLen \times (1+\ExtraProgramPages) \) bytes. This field is encoded with msgpack field epp and may not exceed \( \MaxExtraAppProgramPages \). This ExtraProgramPages field is taken into account on application update as well.

• An “application version” (Version) value that begins at \( 0 \) when an Application is created or when the protocol version including this field goes into effect whichever is later. This field is encoded with msgpack field v.

• The “global state” (GlobalState) associated with this application, stored as a Key/Value Store. This field is encoded with msgpack field gs.

Each application created increases the minimum balance requirement of the creator by \( \AppFlatParamsMinBalance \times (1+\ExtraProgramPages) \) μALGO, plus the GlobalStateSchema minimum balance contribution.

Each application opted in to increases the minimum balance requirements of the opting-in account by \( \AppFlatOptInMinBalance \) μALGO plus the LocalStateSchema minimum balance contribution.

Key/Value Stores

A Key/Value Store, or KV, is an associative array mapping keys of type byte-array to values of type byte-array or 64-bit unsigned integer.

The values in a KV are either:

• Bytes, representing a byte-array,
• Uint, representing an unsigned 64-bit integer value.

The maximum length of a key in a KV is \( \MaxAppKeyLen \) bytes.

State Schemas

A state schema represents limits on the number of each value type that may appear in a Key/Value Store.

State schemas control the maximum size of global and local state KVs.

A state schema is composed of two fields:

• NumUint represents the maximum number of integer values that may appear in some KV.
• NumByteSlice represents the maximum number of byte-array values that may appear in some KV.

App Minimum Balance Changes

When an account opts in to an application or creates an application, the minimum balance requirements for that account increases. The minimum balance requirement is decreased equivalently when an account closes out or deletes an app.

When opting in to an application, there is a base minimum balance increase of \( \AppFlatOptInMinBalance \) μALGO. There is an additional minimum balance increase, in μALGO, based on the LocalStateSchema for that application, described by the following formula:

$$ (\SchemaMinBalancePerEntry + \SchemaUintMinBalance) \times \mathrm{NumUint} + (\SchemaMinBalancePerEntry + \SchemaBytesMinBalance) \times \mathrm{NumByteSlice} $$

When creating an application, there is a base minimum balance increase of \( \AppFlatParamsMinBalance \) μALGO. There is an additional minimum balance increase of \( \AppFlatParamsMinBalance \times \ExtraProgramPages \) μALGO. Finally, there is an additional minimum balance increase, in μALGO, based on the GlobalStateSchema for that application, described by the following formula:

$$ (\SchemaMinBalancePerEntry + \SchemaUintMinBalance) \times \mathrm{NumUint} + (\SchemaMinBalancePerEntry + \SchemaBytesMinBalance) \times \mathrm{NumByteSlice} $$

Boxes

The Box store is an associative array mapping keys of type: (uint64 x []byte) to values of type []byte.

• The key is a pair in which the first value corresponds to an Application ID, and the second is a box name, \( 1 \) to \( \MaxAppKeyLen \) bytes in length. Unlike Global/Local State keys, an empty array is not a valid Box name. However, empty Box names may appear in transactions to increase the I/O budget or allow creation of Boxes whose Application ID is not known at transaction group construction time (see below).

• The value is a byte-array of length not greater than \( \MaxBoxSize \).

When an application executes an opcode that creates, resizes, or destroys a box, the minimum balance of the associated application account (whose address is the hash of the application ID) is modified.

When a box with name \( n \) and size \( s \) is created, the minimum balance requirement is raised by \( \BoxFlatMinBalance + \BoxByteMinBalance \times (\mathrm{len}(n) + s) \). The same amount is decremented from the minimum balance when the box is destroyed.

$$ \newcommand \MinBalance {b_{\min}} \newcommand \Asset {\mathrm{Asa}} \newcommand \MaxAssetDecimals {\Asset_{d,\max}} \newcommand \MaxAssetNameBytes {\Asset_{n,\max}} \newcommand \MaxAssetUnitNameBytes {\Asset_{u,\max}} \newcommand \MaxAssetURLBytes {\Asset_{r,\max}} $$

Assets

Each account can create assets, named by a globally-unique 64-bit unsigned integer (the asset ID).

Assets are associated with a set of asset parameters, which can be encoded as a msgpack struct:

• The total number of units of the asset created, encoded with msgpack field t. This value MUST be between \( 0 \) and \( 2^{64}-1 \).

• The number of digits after the decimal place to be used when displaying the asset, encoded with msgpack field dc. The divisibility of the asset is given by \( 10^{-\mathrm{dc}} \). A dc value of \( 0 \) represents an asset that is not divisible, while a value of \( 1 \) represents an asset divisible into tenths, \( 2 \) into hundredths, etc. This value MUST be between \( 0 \) and \( \MaxAssetDecimals \) (inclusive) (because \( 2^{64}-1 \) is \( 20 \) decimal digits integer).

• Whether holdings of that asset are frozen by default, a boolean flag encoded with msgpack field df.

• A string representing the unit name of the asset for display to the user, encoded with msgpack field un. This field does not uniquely identify an asset; multiple assets can have the same unit name. The maximum length of this field is \( \MaxAssetUnitNameBytes \) bytes.

• A string representing the name of the asset for display to the user, encoded with msgpack field an. This does not uniquely identify an asset; multiple assets can have the same name. The maximum length of this field is \( \MaxAssetNameBytes \) bytes.

• A string representing a URL that further describes the asset, encoded with msgpack field au. This does not uniquely identify an asset; multiple assets can have the same URL. The maximum length of this field is \( \MaxAssetURLBytes \) bytes.

• A 32-byte hash specifying a commitment to asset-specific metadata, encoded with msgpack field am. This does not uniquely identify an asset; multiple assets can have the same commitment.

• An address of a manager account, encoded with msgpack field m. The manager address is used to update the addresses in the asset parameters using an asset configuration transaction. The manager can destroy the asset if the creator account holds its total supply entirely.

• An address of a reserve account, encoded with msgpack field r. The reserve address is not used in the protocol, and is used purely by client software for user display purposes.

• An address of a freeze account, encoded with msgpack field f. The freeze address is used to issue asset freeze transactions.

• An address of a clawback account, encoded with msgpack field c. The clawback address is used to issue asset transfer transactions from arbitrary source addresses.

Parameters for assets created by an account are stored alongside the account state, denoted by a pair (address, asset ID).

Accounts can create and hold any number of assets.

An account must hold every asset that it created (even if it holds \( 0 \) units of that asset), until that asset is destroyed.

An account’s asset holding is simply a map from asset IDs to an integer value indicating how many units of that asset are held by the account, and a boolean flag indicating if the holding is frozen or unfrozen.

An account that holds any asset cannot be closed.

Asset Minimum Balance Changes

When an account opts in to an asset or creates an asset, the minimum balance requirements for that account increases. The minimum balance requirement is decreased equivalently when an account closes out or deletes an asset.

When opting in to an asset, there is a base minimum balance increase of \( \MinBalance \) μALGO.

When creating an asset, there is a base minimum balance increase of \( \MinBalance \) μALGO.

Consensus Participation Updates

Participation updates contain two lists of account addresses for which changes are made to their consensus participation status.

The first list contains accounts that have been deemed to be expired. An account is said to be expired when the last valid vote round in its participation key is strictly less than the current round that is being processed. Once included in this list, an account will be marked offline as part of applying the block changes to the Ledger.

The second list contains accounts that have been deemed to be suspended. An account is said to be suspended according to the rules specified above for suspended participation accounts list. Once included in this list, an account will be marked offline, but its voting keys will be retained in the account state, as part of applying the block changes to the Ledger. The IncentiveEligible flag of the account will be set to false.

$$ \newcommand \StateProof {\mathrm{SP}} \newcommand \StateProofInterval {\delta_\StateProof} $$

Light Block Header

A light block header is a structure containing a subset of fields from Algorand’s block header and the commitment of said block header.

Light block header contains the following components:

• The block’s seed, under msgpack key 0.

• The block’s hash, under msgpack key 1.

• The block’s genesis hash, under msgpack key gh.

• The block’s round, under msgpack key r.

• The block’s SHA-256 transaction commitment, under msgpack key tc.

Commitment

The light block header commitment for rounds \( (X \cdot \StateProofInterval, \ldots, (X+1) \cdot \StateProofInterval] \) for some number \( X \), defined as the root of a vector commitment whose leaves are light block headers for rounds \( X \cdot \StateProofInterval, \ldots, (X+1) \cdot \StateProofInterval \) respectively.

The hash function SHA-256 is used to create this vector commitment.

$$ \newcommand \Proven {\mathrm{Proven}} \newcommand \W {\mathrm{Weight}} \newcommand \StateProof {\mathrm{SP}} \newcommand \StateProofInterval {\delta_\StateProof} \newcommand \StateProofVotersLookback {\delta_{\StateProof,b}} \newcommand \StateProofTopVoters {N_\StateProof} \newcommand \StateProofStrengthTarget {KQ_\StateProof} \newcommand \StateProofWeightThreshold {f_\StateProof} \newcommand \RewardUnit {U_r} $$

State Proofs

Message

A State Proof message for rounds \( (X \cdot \StateProofInterval, \ldots, (X+1) \cdot \StateProofInterval] \) for some number \( X \), contains the following components:

• Light block headers commitment for rounds \( (X \cdot \StateProofInterval, \ldots, (X+1) \cdot \StateProofInterval] \), under msgpack key b.

• First attested round which would be equal to \( X \cdot \StateProofInterval + 1 \), under msgpack key f.

• Last attested round which would be equal to \( (X+1) \cdot \StateProofInterval \), under msgpack key l.

• Participant commitment used to verify state proof for rounds \( ((X+1) \cdot \StateProofInterval, \ldots, (X+2) \cdot \StateProofInterval] \), under msgpack key v.

• The value \( \ln(Proven\W) \) with \( 16 \) bits of precision that would be used to verify State Proof for rounds \( ((X+1) \cdot \StateProofInterval, \ldots, (X+2) \cdot \StateProofInterval] \), under msgpack key P. This field is calculated based on the total weight of the participants see state-proof-transaction

Tracking

Each block header keeps track of the state needed to construct, validate, and record State Proofs.

This tracking data is stored in a map under the msgpack key spt in the block header. The type of the State Proof indexes the map; at the moment, only type \( 0 \) is supported. In the future, other types of state proofs might be added.

For type \( 0 \):

• \( \StateProofStrengthTarget = 256 \),
• \( \StateProofWeightThreshold = 2^{32} \times \frac{30}{100} \) (as the fraction numerator out of \( 2^{32} \)),
• \( \StateProofTopVoters = 1024 \),
• \( \StateProofInterval = 256 \),
• \( \StateProofVotersLookback = 16 \).

The value of the tracking data is a msgpack map with three elements:

• Under key n, the next expected round of a State Proof should be formed. When upgrading from an earlier consensus protocol to a protocol that supports State Proofs, the n field is set to the lowest value such that n is a multiple of \( \StateProofInterval \) and so that the n is at least the first round of the new protocol (supporting State Proofs) plus \( \StateProofVotersLookback + \StateProofInterval \). This field is set in every block.

• Under key v, the root of the vector commitment to an array of participants that are eligible to vote in the State Proof at round \( \StateProofInterval \) from the current block. Only blocks whose round number is a multiple of \( \StateProofInterval \) have a non-zero v field.

• Under key t, the total online stake at round \( \StateProofInterval \) (with pending rewards).

The participants committed to by the vector commitment are chosen in a specific fashion:

• First off, because it takes some time to collect all of the online participants (more than the target assembly time for a block), the set of participants and total online non-expired stake appearing in a commitment in block at round \( r \) are actually based on the account state from round \( r-\StateProofVotersLookback \).

• The participants are sorted by the number of μALGO they currently hold (including any pending rewards). This enables more compact proofs of pseudorandomly chosen participants weighted by their μALGO holdings. Only accounts in the online state are included in this list of participants.

• To limit the worst-case size of this vector commitment, the array of participants contains just the top \( \StateProofTopVoters \) participants. Efficiently computing the top \( \StateProofTopVoters \) accounts by their μALGO balance is difficult in the presence of pending rewards. Thus, to make this top-\( \StateProofTopVoters \) calculation more efficient, we choose the top accounts based on a normalized balance, denoted below by \( n_I \).

The normalized balance is a hypothetical balance: consider an account \( I \) with current balance \( a_I \). If an account had a balance \( n_I \) in the genesis block, and did not perform any transactions since then, then its balance by the current round (when rewards are included) will be \( a_I \), except perhaps due to rounding effects.

In more detail, let \( r^\ast_I \) be the last round in which a transaction touched account \( I \) (and therefore all pending rewards were added to it). Consider the following quantities, as defined in the Account State:

• The raw balance \( a_I \) of the account \( I \) at round \( r^\ast_I \) is its total balance on that round.

• The rewards base \( a^\prime_I \) is meant to capture the total rewards allocated to all accounts up to round \( r^\ast_I \), expressed as a fraction of the total stake (with limited precision as described below).

Given these two quantities, the normalized balance of an online account \( I \) is \( \frac{a_I}{(1+a^\prime_I)} \).

📎 EXAMPLE

For example, if the total amount of rewards distributed up to round \( r^\ast_I \) is \( 20\% \) of the total stake, then the normalized balance is \( \frac{a_I}{1.2} \).

To limit the required precision in this calculation, the system uses a parameter \( \RewardUnit \) that specifies the rewards-earning unit, namely, accounts only earn rewards for a whole number of \( \RewardUnit \) μALGO. (Currently \( \RewardUnit = 1{,}000{,}000 \), so the rewards-earning unit is \( 1 \) ALGO.)

The parameter \(a^\prime_I \) above is an integer such that \( \frac{a^\prime_I}{\RewardUnit} \) is the desired fraction, rounded down to the precision of \( \frac{1}{\RewardUnit} \).

The normalized balance is computed as:

$$ n_I = \left\lfloor \frac{a_I \cdot \RewardUnit}{(a^\prime_I + \RewardUnit)} \right\rfloor. $$

Parameters

• To limit the resources allocated for creating State Proofs, State Proof parameters are set to \( \StateProofTopVoters = 1024 \), \( \StateProofInterval = 256 \), and \( \StateProofVotersLookback = 16 \).

• Setting \( \StateProofStrengthTarget = \mathrm{target_{PQ}} \) to achieve post-quantum security for State Proofs. For further details, refer to the State Proofs [normative

• specification](../crypto/crypto-state-proofs.md).

• Algorand assumes that at least \( 70\% \) of the participating stake is honest. Under this assumption, there can’t be a malicious State Proof that the verifier would accept and have a signed weight of more than \( 30\% \) of the total online stake. Hence, we set \( \StateProofWeightThreshold = 2^{32} \times \frac{30}{100} \) (as the numerator of a fraction out of \( 2^{32} \)).

$$ \newcommand \Tx {\mathrm{Tx}} \newcommand \TxSeq {\mathrm{TxSeq}} \newcommand \TxTail {\mathrm{TxTail}} \newcommand \TxType {\mathrm{TxType}} \newcommand \TxCommit {\mathrm{TxCommit}} \newcommand \vpk {\mathrm{vpk}} \newcommand \spk {\mathrm{spk}} \newcommand \sppk {\mathrm{sppk}} \newcommand \vf {\mathrm{vf}} \newcommand \vl {\mathrm{vl}} \newcommand \vkd {\mathrm{vkd}} \newcommand \Hash {\mathrm{Hash}} \newcommand \nonpart {\mathrm{nonpart}} \newcommand \RekeyTo {\mathrm{RekeyTo}} \newcommand \FirstValidRound {r_\mathrm{fv}} \newcommand \LastValidRound {r_\mathrm{lv}} \newcommand \Genesis {\mathrm{Genesis}} \newcommand \GenesisID {\Genesis\mathrm{ID}} \newcommand \GenesisHash {\Genesis\Hash} \newcommand \Group {\Tx\mathrm{G}} \newcommand \RekeyTo {\mathrm{RekeyTo}} \newcommand \MaxTxnNoteBytes {T_{m,\max}} $$

Transactions

Just as a block represents a transition between two Ledger states, a transaction \( \Tx \) represents a transition between two account states.

Algorand transactions have different transaction types.

Transaction fields are divided into a:

• A header, common to any type,

• A body, which is type-specific.

Transaction fields are REQUIRED unless specified as OPTIONAL.

The cryptographic hash of the transaction fields, including the transaction specific fields of the body, is called the transaction identifier. This is written as \( \Hash(\Tx) \).

Transaction Header

A transaction header contains the following fields:

Transaction Type

The transaction type \( \TxType \) is a short string indicating the type of transaction.

The following transaction types are supported:

Sender

The sender \( I \) identifies the account that authorized the transaction.

Fee

The fee \( f \) specifies the processing fee the sender pays to execute the transaction, expressed in μALGO.

The fee MAY be set to \( 0 \) if the transaction is part of a group.

First and Last Valid Round

The first valid round \( \FirstValidRound \) and last valid round \( \LastValidRound \), define a round interval for which the transaction MAY be executed.

Genesis Hash

The genesis hash \( \GenesisHash \) defines the Ledger for which this transaction is valid.

Genesis Identifier

The genesis identifier \( \GenesisID \) (OPTIONAL) defines the Ledger for which this transaction is valid.

Lease

The lease \( x \) (OPTIONAL) specifies transactions’ mutual exclusion. If \( x \neq 0 \) (i.e., \( x \) is set) and this transaction is confirmed, then this transaction prevents another transaction from the same sender and with the same lease from being confirmed until \( \LastValidRound \) is confirmed.

Group

The group \( \Group \) (OPTIONAL) is a commitment whose meaning is described in the Transaction Groups section.

Rekey-to

The rekey to \( \RekeyTo \) (OPTIONAL) is an address. If nonzero, the transaction will set the sender account’s authorization address field to this value. If the \( \RekeyTo \) address matches the sender address, then the authorization address is instead set to zero, and the original spending keys are re-established.

The rekey functionally works as if the account replaces its private spending keys, while its address remains the same. The account is now controlled by the authorization address (i.e., transaction signatures are checked against this address).

Note

The note \( N \) (OPTIONAL) contains arbitrary data appended to the transaction.

• The note byte length MUST NOT exceed \( \MaxTxnNoteBytes \).

Semantic

TODO

Validation

TODO

Payment Transaction

Fields

A payment transaction additionally has the following fields:

Amount

The amount \( a \) indicates the number of μALGO being transferred by the payment transaction.

If the amount is omitted (\( a = 0 \)), the number of μALGO transferred is zero.

Receiver

The receiver \( I^\prime \) specifies the receiver of the amount in the payment transaction.

If the receiver is omitted (\( I^\prime = 0 \)), the amount is transferred to the zero address.

Close-to

The close to address \( I_0 \) (OPTIONAL) collects all remaining μALGO in the sender account after the payment transfer.

If the close to address is omitted (\( I_0 = 0 \)), the field has no effect.

Semantic

TODO

Validation

TODO

$$ \newcommand \PartKey {\mathrm{PartKey}} \newcommand \VoteKey {\mathrm{vpk}} \newcommand \SelectionKey {\mathrm{spk}} \newcommand \StateProofKey {\mathrm{sppk}} \newcommand \VoteFirstValid {v_\mathrm{fv}} \newcommand \VoteLastValid {v_\mathrm{lv}} \newcommand \KeyDilution {\mathrm{KeyDilution}} \newcommand \NonPart {\mathrm{nonpart}} \newcommand \LastValidRound {r_\mathrm{lv}} \newcommand \MaxKeyregValidPeriod {K_{\Delta r,\max}} $$

Key Registration Transaction

Fields

A key registration transaction additionally has the following fields:

Vote Public Key

The vote public key \( \VoteKey \) is the (root) Ed25519 public authentication key of an account’s participation keys (\( \PartKey \)).

Selection Public Key

The selection public key \( \SelectionKey \) is the public VRF key of an account’s participation keys (\( \PartKey \)).

State Proof Public Key

The state proof public key \( \StateProofKey \) is the public commitment to the account’s State Proof keys \( \StateProofKey \).

If \( \VoteKey \), \( \SelectionKey \), and \( \StateProofKey \) are all omitted, the transaction deregisters the account’s participation key set, and as a result marks the account as offline (that is, non-participating in the agreement).

Vote First

The vote first \( \VoteFirstValid \) indicates first valid round (inclusive) of an account’s participation key sets.

Vote Last

The vote last \( \VoteLastValid \) indicates last valid round (inclusive) of an account’s participation key sets.

Vote Key Dilution

The vote key dilution defines the number of rounds for generating a new (second-level) ephemeral participation key. The higher the number, the more “dilution” is added to the authentication key’s security.

For further details on the two-level ephemeral key scheme used for consensus participation authentication, refer to the Algorand Participation Key Specification.

Non-Participation

The non-participation \( \NonPart \) (OPTIONAL) is flag which, when deregistering keys, specifies whether to mark the account just as offline (if \( \NonPart \) is false) or as non-participatory (if \( \NonPart \) is true).

The non-participatory status is set to true the account is irreversibly excluded from consensus participation (i.e., can no longer be marked as online) and from the legacy distribution rewards mechanism.

Semantic

TODO

Validation

For a key registration transaction to be valid, the following conditions MUST apply:

• The elements of the set \( (\VoteKey, \SelectionKey, \StateProofKey, \KeyDilution) \) are REQUIRED to be all present, or all omitted (clear).

Providing the default value or the empty value, for any of the set members, would be interpreted as if these values were omitted.

• \( \VoteFirstValid \leq \VoteLastValid \).

• If the set \( (\VoteKey, \SelectionKey, \StateProofKey, \KeyDilution) \) is clear, then \( \VoteFirstValid \) and \( \VoteLastValid \) MUST be clear as well.

• If the set \( (\VoteKey, \SelectionKey, \StateProofKey, \KeyDilution) \) is not clear, the following MUST apply:

• \( \VoteFirstValid \leq r + 1 \) and \( \VoteLastValid > r \), where \( r \) is the current network round (the round of the last block committed).

• \( \VoteFirstValid \leq \LastValidRound + 1 \).

• \( \VoteLastValid - \VoteFirstValid < \MaxKeyregValidPeriod \).

It is RECOMMENDED that \( \VoteLastValid - \VoteFirstValid \leq 3{,}000{,}000 \) rounds for security reasons, to ensure safe rotation of participation keys.

$$ \newcommand \Asset {\mathrm{Asa}} \newcommand \MaxAssetDecimals {\Asset_{d,\max}} \newcommand \MaxAssetNameBytes {\Asset_{n,\max}} \newcommand \MaxAssetUnitNameBytes {\Asset_{u,\max}} \newcommand \MaxAssetURLBytes {\Asset_{r,\max}} $$

Asset Configuration Transaction

Fields

An asset configuration transaction additionally has the following fields:

Asset ID

The asset ID \( \Asset_\mathrm{cfg,ID} \) identifies the asset being configured.

If the asset ID is omitted (zero), this transaction is creating an asset.

Asset Parameters

The asset parameters are the parameters for configuring the asset.

These asset parameters is structure containing:

• The decimals MUST NOT exceed \( \MaxAssetDecimals \).

• The unit name byte length MUTS NOT exceed \( \MaxAssetUnitNameBytes \).

• The asset name byte length MUST NOT exceed \( \MaxAssetNameBytes \).

• The URL byte length MUST NOT exceed \( \MaxAssetURLBytes \).

If the asset parameters are omitted (struct of zero values), this transaction is deleting the asset.

Semantic

TODO

Validation

TODO

$$ \newcommand \Asset {\mathrm{Asa}} $$

Asset Transfer Transaction

Fields

An asset transfer transaction additionally has the following fields:

Asset ID

The asset ID \( \Asset_\mathrm{xfer,ID} \) identifies the asset being transferred.

Asset Amount

The asset amount \( \Asset_a \) (OPTIONAL) indicates the number of asset units being transferred.

If the asset amount is omitted (\( \Asset_a = 0 \)), the number of asset units transferred is zero.

Asset Sender

The asset sender \( \Asset_I \) (OPTIONAL) identifies the source address for the asset transfer (non-zero if the transaction is a clawback).

If the asset sender is omitted (\( \Asset_I = 0 \)), the source address of the asset transfer is the sender of the transaction.

Asset Receiver

The asset receiver \( \Asset_{I^\prime} \) identifies the destination address for the asset transfer.

Asset Close-to Address

The asset close to address \( \Asset_{I_0}\) (OPTIONAL) collects all remaining asset units in the sender account after the asset transfer.

If the asset close to address is omitted (\( \Asset_{I_0}\)), the field has no effect.

Semantic

TODO

Validation

TODO

$$ \newcommand \Asset {\mathrm{Asa}} $$

Asset Freeze Transaction

Fields

An asset freeze transaction additionally has the following fields:

Asset ID

The asset ID \( \Asset_\mathrm{frz,ID} \) identifies the asset being frozen or unfrozen.

Freeze Address

The freeze address \( I_\mathrm{frz} \) identifies the account whose holdings of the asset ID should be frozen or unfrozen.

Frozen Status

The frozen status \( \Asset_f \) is a flag setting of whether the freeze address holdings of asset ID should be frozen (true) or unfrozen (false).

Semantic

TODO

Validation

TODO

$$ \newcommand \App {\mathrm{App}} \newcommand \MaxAppTotalTxnReferences {\App_{r,\max}} \newcommand \MaxExtraAppProgramPages {\App_{\mathrm{page},\max}} \newcommand \MaxAppProgramLen {\App_{\mathrm{prog},\max}} \newcommand \MaxGlobalSchemaEntries {\App_{\mathrm{GS},\max}} \newcommand \MaxLocalSchemaEntries {\App_{\mathrm{LS},\max}} \newcommand \MaxAppArgs {\App_{\mathrm{arg},\max}} \newcommand \MaxAppTotalArgLen {\App_{\mathrm{ay},\max}} \newcommand \MaxAppTxnAccounts {\App_{\mathrm{acc},\max}} \newcommand \MaxAppTxnForeignApps {\App_{\mathrm{app},\max}} \newcommand \MaxAppTxnForeignAssets {\App_{\mathrm{asa},\max}} \newcommand \MaxAppAccess {\App_{\mathrm{access},\max}} \newcommand \Box {\mathrm{Box}} \newcommand \MaxAppBoxReferences {\App_{\Box,\max}} \newcommand \MaxAppKeyLen {\App_{\mathrm{k},\max}} $$

Application Call Transaction

Fields

An application call transaction additionally has the following fields:

The sum of the elements in foreign accounts (apat), foreign applications (apfa), foreign assets (apas), and box references (apbx) MUST NOT exceed \( \MaxAppTotalTxnReferences \).

Application ID

The application ID identifies the application being called.

If the application ID is omitted (zero), this transaction is creating an application.

On Completion Action

The on completion action specifies an additional effect of this transaction on the application’s state in the sender or application creator’s account data.

The apan field values are enumerated as follows:

Approval Program

The approval program (OPTIONAL) contains the approval program bytecode.

This field is used for application creation and updates, and sets the corresponding application’s Approval Program.

Clear State Program

The clear state program (OPTIONAL) contains the clear state program bytecode.

This field is used for application creation and updates, and sets the corresponding application’s Clear State Program.

• The Approval Program and the Clear State Program MUST have the same version number if either is \( 6 \) or higher.

Reject Version

The reject version (OPTIONAL), if set to a positive number, specifies that the application call MUST fail unless the reject version value exceeds the Application Version.

For further details on Application Versions, refer to the Applications Specifications.

Extra Program Pages

A program page (OPTIONAL) is a chunk of application program bytecode. The extra program pages define the number of program pages besides the first one.

This field is only used during application creation, and requests an increased maximum size for the Approval Program or Clear State Program.

• There MUST NOT be more than \( \MaxExtraAppProgramPages \) extra program pages,

• The program page byte length MUST NOT exceed \( \MaxAppProgramLen \).

Global State Schema

The global state schema (OPTIONAL) defines the global state allocated into the creator account that of the application ID.

The global state schema is a structure containing:

This field is only used during application creation, and sets bounds on the size of the global state associated with this application.

• There MUST NOT be more than \( \MaxGlobalSchemaEntries \) global variables for the application.

TODO: Restrictions on key-value lengths

Local State Schema

The local state schema (OPTIONAL) defines the local state allocated into the accounts that opt-in the application ID.

The local state schema is a structure containing:

This field is only used during application creation, and sets bounds on the size of the local state for accounts that opt in to this application.

• There MUST NOT be more than \( \MaxLocalSchemaEntries \) local variables for the application.

TODO: Restrictions on key-value lengths

Arguments

The application arguments (OPTIONAL) list provides byte-array arguments to the application being called.

• There MUST NOT be more than \( \MaxAppArgs \) entries in this list,

• The sum of their byte lengths MUST NOT exceed \( \MaxAppTotalArgLen \).

Foreign Accounts

The foreign accounts (OPTIONAL) list specifies the accounts, besides the sender, whose local states MAY be referred to by executing the Approval Program or the Clear State Program. These accounts are referred to by their 32-byte addresses.

• There MUST NOT be more than \( \MaxAppTxnAccounts \) entries in this list.

Foreign Applications

The foreign applications (OPTIONAL) list specifies the application IDs, besides the application whose Approval Program or Clear State Program is executing, that the executing program MAY read global state from. These applications are referred to by their 64-bit unsigned integer IDs.

• There MUST NOT be more than \( \MaxAppTxnForeignApps \) entries in this list.

Foreign Assets

The foreign assets (OPTIONAL) list specifies the asset IDs from which the executing Approval Program or Clear State Program MAY read asset parameters. These assets are referred to by their 64-bit unsigned integer IDs.

• There MUST NOT be more than \( \MaxAppTxnForeignAssets \) entries in this list.

Box References

The box references (OPTIONAL) list specifies the boxes that the executing Approval Program (with AVM Version 9 or later), or any other Approval Program in the same group, MAY access for reading or writing when the box reference matches the running program application IDs.

For further details on AVM resource availability, refer to the AVM Specifications.

Each element of the box reference encodes a structure containing:

An omitted index (i) is interpreted as the application ID of this transaction (apid, or the ID allocated for the created application when apid is \( 0 \)).

• There MUST NOT be more than \( \MaxAppBoxReferences \) entries in this list.

• The box name byte length MUST NOT exceed \( \MaxAppKeyLen \).

Access List

The access list (OPTIONAL) specifies resources (accounts, application IDs, asset IDs, and box references) that the executing Approval Program (with AVM Version 9 or later), or any other Approval Program in the same group, MAY access for reading or writing.

For further details on AVM resource availability, refer to the AVM Specifications.

Each element of the access list encodes one of the following resources:

The subfields of h, l, b refer to Accounts, Assets, and Applications by using an \( 1 \)-based index into the Access List.

An omitted d indicates the sender of the transaction.

An omitted app (p or i) indicates the called Application.

The access list MUST be empty if any of the foreign arrays (apat, apfa, apas), or box reference list (apbx) fields are populated.

• There MUST NOT be more than \( \MaxAppAccess \) entries in this list.

Validation

TODO

Semantic

TODO

$$ \newcommand \Proven {\mathrm{Proven}} \newcommand \Total {\mathrm{Total}} \newcommand \W {\mathrm{Weight}} \newcommand \StateProof {\mathrm{SP}} \newcommand \StateProofInterval {\delta_\StateProof} \newcommand \StateProofWeightThreshold {f_\StateProof} \newcommand \Offset {\mathrm{Offset}} $$

State Proof Transaction

The state proof is a special transaction used to disseminate and store State Proofs.

Fields

A state proof transaction additionally has the following fields:

State Proof Type

The state proof type identifies the type of the State Proof.

Currently, always \( 0 \).

State Proof

The state proof structure as defined in the State Proof specification.

Message

The message is a structure that composes the State Proof message, whose hash is being attested to by the State Proof.

The message structure is defined in the State Proof message section.

Validation

In order for a state proof transaction to be valid, the following conditions MUST be meet:

• The transaction type MUST be stpf.

• The sender MUST be equal to a special address, which is the hash of the domain-separation prefix SpecialAddr (see the corresponding section in the Algorand Cryptographic Primitive Specification) with the string constant StateProofSender.

• The fee MUST be \( 0 \).

• The lease MUST be omitted.

• The group MUST be omitted.

• The rekey to MUST be omitted.

• The note MUST be omitted.

• The transaction MUST NOT have any signature.

• The state proof round (defined in the message structure) MUST be exactly equal to the next expected State Proof round in the block header, as described in the State Proof tracking section.

• The state proof verification code MUST return true (see State Proof validity), given the State Proof message and the State Proof transaction fields.

In addition, the verifier should also be given a trusted commitment to the participant array and \( \Proven\W \) value. The trusted data SHOULD be taken from the Ledger at the relevant round.

To encourage the formation of shorter State Proof, the rule for validity of state proof transactions is dependent on the first valid round in the transaction.

In particular, the signed weight of a State Proof MUST be:

• Equal to the total online stake, \( \Total\W \), if the first valid round on the transaction is no greater than the state proof round (defined in the message structure) plus \( \frac{\StateProofInterval}{2} \).

• At least \( \Proven\W + (\Total\W - \Proven\W) \times \frac{\Offset}{\frac{\StateProofInterval}{2}} \), if the first valid round on the transaction is the state proof round (defined in the message structure) plus \( \frac{\StateProofInterval}{2} + \Offset \).

• At least the minimum weight being proven by the proof, \( \Proven\W \), if the first valid round on the transaction is no less than state proof round (defined in the message structure) plus \( \StateProofInterval \).

Where \( \Proven\W = \frac{\Total\W \times \StateProofWeightThreshold}{2^{32}} \)

When a state proof transaction is applied to the state, the next expected State Proof round for that type of State Proof is incremented by \( \StateProofInterval \).

A node should be able to verify a state proof transaction at any time, even if the transaction first valid round is greater than the next expected State Proof round in the block header.

Semantic

TODO

Heartbeat Transaction

The heartbeat is a special transaction used to challenge the liveness of an online account.

Fields

A heartbeat transaction additionally has the following fields:

Heartbeat Address

The heartbeat address is an account address that this heartbeat transaction proves liveness for.

Heartbeat Seed

The heartbeat seed is a block seed.

• It MUST be the block seed found in the first valid round of the transaction.

Heartbeat Vote ID

The heartbeat vote id is a public key.

• It MUST be the current public key of the root voting key of the heartbeat address’s account state.

Heartbeat Key Dilution

The heartbeat key dilution is a key dilution parameter (see Algorand Participation Keys specification).

• It MUST be the current key dilution of the heartbeat address’s account state.

Heartbeat Proof

The heartbeat proof MUST contain a valid signing of the heartbeat seed using the heartbeat vote id and the heartbeat key dilution using the voting signature scheme defined in the Algorand Participation Keys specification.

Validation

TODO

Semantic

TODO

$$ \newcommand \Hash {\mathrm{Hash}} \newcommand \MaxTxGroupSize {GT_{\max}} \newcommand \MinTxnFee {T_{\Fee,\min}} \newcommand \BytesPerBoxReference {\Box_{\mathrm{IO}}} \newcommand \LogicSigMaxSize {\LogicSig_{\max}} $$

Transaction Groups

A transaction MAY include a group field (msgpack codec grp), a 32-byte hash that specifies what transaction group the transaction belongs to.

Informally, a transaction group is an ordered list of transactions that MUST all be confirmed together, in the specified order, and included in the same block. If any transaction in the group fails to be confirmed, none of them will be.

The group field, in each transaction part of the same group, is set to the hash representing a commitment to the entire group. This group hash is computed by creating an ordered list of the hashes of all transactions in the group. When computing each transaction’s hash for this purpose, its own group field is omitted to avoid circular dependency.

📎 EXAMPLE

A user wants to require transaction \( A \) to confirm if and only if transactions \( B \) and \( C \) confirm in a certain order. The user performs the following procedure:

1. Specifies transactions’ order: \( [A, B, C] \);

2. Computes the hashes of each transaction in the list (without their group field set): \( [\Hash(A), \Hash(B), \Hash(C)] \);

3. Hash them together in the specified order, getting the group hash: \( G = \Hash([\Hash(A), \Hash(B), \Hash(C)]) \);

4. Set the group field of all the transactions to the group hash (\( G \)) before signing them.

A group MAY contain no more than \( \MaxTxGroupSize \) transactions.

More formally, when evaluating a block, the \( i \)-th and \( i+1 \)-th transactions in the payset are considered to belong to the same transaction group if the group fields of the two transactions are equal and non-zero.

The block may now be viewed as an ordered sequence of transaction groups, where each transaction group is a contiguous sublist of the payset consisting of one or more transactions with equal group field.

For each transaction group where the transactions have non-zero group, compute the group hash as follows:

• Take the hash of each transaction in the group, but with its group field omitted.

• Hash this ordered list of hashes. More precisely, hash the canonical msgpack encoding of a structure with a field txlist containing the list of hashes, using TG as domain separation prefix.

If the group hash of any transaction group in a block does not match the group field of the transactions in that group (and that group field is non-zero), then the block is invalid.

Additionally, if a block contains a transaction group of more than \( \MaxTxGroupSize \) transactions, the block is invalid.

If the sum of the fees paid by the \( n \) transactions in a transaction group is less than \( n \times \MinTxnFee )\, then the block is invalid. There are two exceptions to this fee requirement:

1. State Proof transactions require no fee;

2. Heartbeat transactions require no fee if they have a zero group field, and the heartbeat address was challenged between \( 100 \) and \( 200 \) rounds ago, and has not proposed or heartbeat since that challenge.

Further explanation of this rule is found in Heartbeat transaction semantics section.

If the sum of the lengths of the boxes denoted by the box references in a transaction group exceeds \( \BytesPerBoxReference \) times the total number of box references in the transaction group, then the block is invalid. Call this limit the I/O Budget for the group. Box references with an empty name are counted toward the total number of references, but add nothing to the sum of lengths.

If the sum of the lengths of the boxes modified (by creation or modification) in a transaction group exceeds the I/O Budget of the group at any time during evaluation (see Application Call transaction semantics), then the block is invalid.

If the sum of the lengths of all the logic signatures and their arguments in a transaction group exceeds the number of transactions in the group times \( \LogicSigMaxSize \), then the block in invalid.

Beyond the group field, group minimum fee, group I/O Budget, and group logic sig size checks, each transaction in a group is evaluated separately and MUST be valid on its own, as described in the Validity and State Changes section.

📎 EXAMPLE

An account with balance \( 50 \) ALGO could not spend \( 100 \) ALGO in transaction \( A \) and afterward receive \( 500 \) in transaction \( B \), even if transactions \( A \) and \( B \) are in the same group, because transaction \( A \) would overspend the account’s balance.

$$ \newcommand \Hash {\mathrm{Hash}} \newcommand \pk {\mathrm{pk}} \newcommand \MSigPrefix {\texttt{MultisigAddr}} $$

Authorization and Signatures

Transactions are not valid unless they are somehow authorized by the sender account (for example, with a signature).

The authorization information is not considered part of the transaction and does not affect the transaction ID (TXID).

Rather, when serializing a transaction for submitting to a node or including in a block, the transaction and its authorization appear together in a structure called a SignedTxn.

The SignedTxn struct contains:

• The transaction (in msgpack field txn);

• An OPTIONAL authorizer address (field sgnr);

• Exactly one of a signature (field sig), multisignature (field msig), or logic signature (field lsig).

The authorizer address, a 32-byte address, determines against what to verify the sig / msig / lsig, as described below.

If the sgnr field is omitted (or zero), then the authorizer address defaults to the transaction sender address.

At the time the transaction is applied to the Ledger, the authorizer address MUST match the transaction sender account’s spending key (or the sender address, if the account’s spending key is zero). If it does not match, then the transaction was improperly authorized and is invalid.

Signatures

• A valid signature (sig) is a (64-byte) valid Ed25519 signature of the transaction (encoded in canonical msgpack and with domain separation prefix TX) where the public key is the authorizer address (interpreted as an Ed25519 public key).

• A valid multisignature (msig) is an object containing the following fields and which hashes to the authorizer address as described in the Multisignature section:

  • The subsig array of subsignatures, each consisting of a signer address and a 64-byte signature of the transaction. Note that transaction signed by a multisignature account MUST contain all signer’s addresses in the subsig array even if the transaction has not been signed by that address.

  • The threshold thr that is a minimum number of REQUIRED signatures.

  • The multisignature version v (current value is \( 1 \)).

• A valid logic signature (lsig) is an object containing the following fields:

  • The logic l which is versioned bytecode (see AVM specifications).

  • An OPTIONAL single signature sig of 64-bytes valid from the authorizer address of the transaction which has signed the bytes in l.

  • An OPTIONAL multisignature lmsig from the authorizer address of the transaction over the bytes of the authorizer address and the bytes in l.

  • An OPTIONAL array of byte strings arg which are arguments supplied to the program in l (arg bytes are not covered by sig or msig).

The logic signature is valid if exactly one of sig or msig is a valid signature of the program by the authorizer address of the transaction, or if neither sig nor msig is set and the hash of the program is equal to the authorizer address.

Also the program MUST execute and finish with a single non-zero value on the AVM stack (see AVM specifications for details on program execution semantics).

Multisignature

Multisignature term describes a special multisignature address, signing and validation procedures.

In contrast with a single signature address that may be understood as a public key, multisignature address is a hash of a constant string identifier for:

• The \( \MSigPrefix \) prefix,

• A version \( v \),

• The multisignature authorization threshold \( t \),

• All \( n \) addresses (\( \pk \)) used for multisignature address creation.

$$ \mathrm{MSig} = \Hash(\MSigPrefix, v, t, \pk_1, \ldots \pk_n) $$

One address MAY be specified multiple times in multisignature address creation. In this case, every occurrence is counted independently in validation.

The repetition of the same address in the multisignature defines the “weight” of the address.

The multisignature validation process checks that:

1. All non-empty signatures are valid;

2. The valid signatures count is not less than the threshold.

Validation fails if any of the signatures is invalid, even if the count of all remaining correct signatures is greater or equals than the threshold.

$$ \newcommand \ApplyData {\mathrm{ApplyData}} \newcommand \ClosingAmount {\mathrm{ClosingAmount}} \newcommand \AssetClosingAmount {\mathrm{AssetClosingAmount}} $$

ApplyData

Each transaction is associated with some information about how it is applied to the Account State. This information is called \( \ApplyData \), and contains the fields based on the transaction type (type).

Payment Transaction

• The closing amount, \( \ClosingAmount \), encoded as msgpack field ca, specifies how many μALGO were transferred to the close-to address (close).

Asset Transfer Transaction

• The asset closing amount \( \AssetClosingAmount \), encoded as msgpack field aca, specifies how many of the asset units were transferred to the asset close-to address (aclose).

Application Call Transaction

• The eval delta, encoded as msgpack field dt, is associated with the successful execution of the corresponding application’s Approval Program or Clear State Program. It contains the following fields:

  • A global delta, encoded as msgpack field gd, encoding the changes to the global state of the called application. This field is a State Delta;

  • Zero or more local deltas, encoded as msgpack field ld, encoding changes to some local states associated with the called application. The local delta ld maps an “account offset” to a State Delta. Account offset \( 0 \) is the transaction’s sender. Account offsets \( 1 \) and greater refer to the account specified at that offset minus one in the transaction’s foreign accounts (apat). An account would have a ld entry as long as there is at least a single change in that set.

  • Zero or more logs, encoded as msgpack array lg, recording the arguments to each call of the log opcode in the called application. The order of the entries follows the execution order of the log opcode invocations. The total number of log calls MUST NOT exceed \( 32 \), and the total size of all logged bytes is MUST NOT exceed \( 1024 \). No logs are included if a Clear State Program fails.

  • Zero or more inner transactions, encoded as msgpack array itx. Each element of itx records a successful inner transaction. Each element will contain the transaction fields, encoded under the msgpack field txn, in the same way that the regular (top-level) transaction is encoded, recursively, including \( ApplyData \) that applies to the inner transaction.

    • The recursive depth of inner transactions is MUST NOT exceed \( 8 \);
    • In Program Version 5, the inner transactions MUST NOT exceed \( 16 \). From Program Version 6, the count of all inner transactions across the transaction group MUST NOT exceed \( 256 \).
    • Before Program Version 6, the inner transaction types (type) are limited to pay, axfer, acfg, and afrz. From Program Version 6, keyreg and appl are allowed.
    • A Clear State Program execution MUST NOT have any inner transaction.

Distribution Rewards

The following \( ApplyData \) item refers to the legacy Distribution Reward system.

• The amount of rewards distributed to each of the accounts touched by this transaction, encoded as three msgpack fields rs, rr, and rc, representing amount of reward distributed respectively to:

  • The sender address,
  • The receiver address,
  • The cose-to addresses.

The fields have integer values representing μALGO.

If any of the addresses are the same (e.g., the sender and receiver are the same), then that account received the sum of the respective reward distributions (i.e., rs plus rr).

⚙️ IMPLEMENTATION

In the reference implementation, one of these two fields will be zero in that case.

Inner Transactions

TODO (Similarities and differences with respect to regular transactions)

State Deltas

A state delta represents an update to a Key/Value Store (KV). It is constructed as an associative array mapping a byte-array key to a single value delta. It represents a series of actions that, when applied to the previous state of the Key/Value store, will yield the new state. These state deltas are included in the Application Call \( ApplyData \) structure under the field eval delta (dt).

A _value delta_is composed of three fields:

• An action, encoded as msgpack field at, which specifies how the value for this key has changed. It has three possible values:

  • SetUintAction (value = 1), indicating that the value for this key should be set to the value delta’s Uint field.
  • SetBytesAction (value = 2), indicating that the value for this key should be set to the value delta’s Bytes field.
  • DeleteAction (value = 3), indicating that the value for this key should be deleted.

• Bytes, encoded as msgpack field bs, which specifies a byte slice value to set.

• Uint, encoded as msgpack field ui, which specifies a 64-bit unsigned integer value to set.

$$ \newcommand \MinBalance {b_{\min}} $$

Asset Transaction Semantics

Asset Configuration

An asset configuration transaction has the following semantics:

• If the asset ID is zero, create a new asset with an ID corresponding to one plus this transaction’s unique counter value. The transaction’s counter value is the transaction counter field from the block header plus the positional index of this transaction in the block (starting from \( 0 \)).

On asset creation, the asset parameters for the created asset are stored in the creator’s account under the newly allocated asset ID. The creating account also allocates space to hold asset units of the newly allocated asset. All units of the newly created asset (i.e., the total specified in the parameters) are held by the creator. When the creator holding is initialized, it ignores the _default frozen_flag and is always initialized to unfrozen.

• If the asset ID is non-zero, the transaction MUST be issued by the asset manager (based on the asset’s current parameters). A zero manager address means no such transaction can be issued.

  • If the asset parameters are omitted (the zero value), the asset is destroyed. This is allowed only if the asset creator holds all of the units of that asset (i.e., equal to the total in the parameters).

  • If the asset parameters are not omitted, any non-zero key in the asset’s current parameters (as stored in the asset creator’s account) is updated to the key specified in the asset parameters. This applies to the manager, reserve, freeze, and clawback keys. Once a key is set to zero, it cannot be updated. Other parameters are immutable.

Asset Transfer

An asset transfer transaction has the following semantics:

• If the asset sender field is non-zero, the transaction MUST be issued by the asset’s clawback address, and this transaction can neither allocate nor close out holdings of an asset (i.e., the asset close-to field MUST NOT be specified, and the source account MUST already have allocated space to store holdings of the asset in question). In this clawback case, freezes MUST be bypassed on both the source and destination of this transfer.

• If the asset sender field is zero, the asset sender is assumed to be the transaction’s sender, and freezes MUST NOT be bypassed.

• If the asset amount is \( 0 \), the transaction allocates space in the sender’s account to store the asset ID. The holdings are initialized with a zero number of units of that asset, and the default frozen flag from the asset’s parameters. Space cannot be allocated for asset IDs that have never been created, or that have been destroyed, at the time of space allocation. Space can remain allocated, however, after the asset is destroyed.

• The transaction moves the specified number of units of the asset from the asset sender to the asset receiver.

  • If either account is frozen, and freezes are not bypassed, the transaction fails to execute.

  • If either account has no space allocated to hold units of this asset, the transaction fails to execute.

  • If the asset sender has fewer than the specified number of units of that asset, the transaction fails to execute.

• If the asset close-to field is specified, the transaction transfers all remaining units of the asset to the close-to address.

  • If the close-to address is not the creator address, then neither the asset sender’s holdings of this asset nor the close-to address’s holdings can be frozen; otherwise, the transaction fails to execute.

  • Closing to the asset creator is always allowed, even if the source and/or creator account’s holdings are frozen.

  • If the asset sender or close-to address does not have allocated space for the asset in question, the transaction fails to execute.

  • After transferring all outstanding units of the asset, space for the asset is deallocated from the sender account.

Asset Freeze

An asset freeze transaction has the following semantics:

• If the transaction is not issued by the freeze address in the specified asset’s parameters, the transaction fails to execute.

• If the specified asset ID does not exist in the specified account, the transaction fails to execute.

• The freeze flag of the specified asset in the specified account is updated to the frozen status flag value from the freeze transaction.

Asset Allocation

When an asset transaction allocates space in an account for an asset, whether by creation or opt-in, the sender’s minimum balance requirement is incremented by \( \MinBalance \).

When the space is deallocated, whether by asset destruction or asset close-to, the minimum balance requirement of the sender is decremented by \( \MinBalance \).

$$ \newcommand \Box {\mathrm{Box}} \newcommand \BytesPerBoxReference {\Box_{\mathrm{IO}}} $$

Application Call Transaction Semantics

When an application call transaction is evaluated, it is processed according to the following procedure.

The transaction effects MUST NOT be visible to other transactions until the points marked SUCCEED below.

FAIL indicates that any modifications to state up to that point MUST be discarded and the entire transaction rejected.

Procedure

Step 1

• If the application ID specified by the transaction is zero, create a new application with ID equal to one plus the system transaction counter (this is the same ID selection algorithm as used by Assets).

  When creating an application, the application parameters specified by the transaction (Approval Program, Clear State Program, Global State Schema, Local State Schema, and Extra Program Pages) are allocated into the sender’s account data, keyed by the new application ID.

  Continue to Step 2.

• If the application ID specified by the transaction is nonzero, continue to Step 2.

Step 2

• If the on completion action is equal to ClearStateOC, then:

  • Check if the transaction’s sender is opted in to this application ID. If not, FAIL.

  • Check if the application parameters still exist in the creator’s account data.

    • If the application does not exist, delete the sender’s local state for this application (marking them as no longer opted in), and SUCCEED.

    • If the application does exist, continue to Step 3.

• If the on completion action is not equal to ClearStateOC, continue to Step 4.

Step 3

• Execute the Clear State Program.

  • If the program execution returns PASS == true, apply the local/global key/value store deltas generated by the program’s execution.

  • If the program execution returns PASS == false, do not apply any local/global key/value store deltas generated by the program’s execution.

  • Delete the sender’s local state for this application (marking them as no longer opted in). SUCCEED.

Step 4

• If on completion action is equal to OptInOC, then at this point during execution we will allocate a local key/value store for the sender for this application ID, marking the sender as opted in.

  Continue to Step 5.

Step 5

• Execute the Approval Program.

  • If the program execution returns PASS == true, apply any local/global key/value store deltas generated by the program’s execution. Continue to Step 6.

  • If the program execution returns PASS == false, FAIL.

Step 6

• If on completion action is equal to NoOpOC

  • SUCCEED.

• If on completion action is equal toOptInOC

  • This was handled above. SUCCEED.

• If on completion action is equal to CloseOutOC

  • Check if the transaction’s sender is opted in to this application ID. If not, FAIL.

  • Delete the sender’s local state for this application (marking them as no longer opted in). SUCCEED.

• If on completion action is equal to ClearStateOC

  • This was handled above (unreachable).

• If on completion action is equal to DeleteApplicationOC

  • Delete the application’s parameters from the creator’s account data. (Note: this does not affect any local state). SUCCEED.

• If on completion action is equal to UpdateApplicationOC

  • If an existing program is version 4 or higher, and the supplied program is a downgrade from the existing version. FAIL.

  • Update the Approval Program and Clear State Program for this application according to the programs specified in this application call transaction and increment the Application Version. The new programs are not executed in this transaction. SUCCEED.

Application Stateful Execution Semantics

• Before the execution of the first application call transaction in a group, the combined size of all boxes referred to in the box references of all transactions in the group MUST NOT exceed the I/O budget (i.e., \( \BytesPerBoxReference \) times the total number of box references in the group), or else the group fails.

• During the execution of an Approval Program or Clear State Program, the application’s Local State Schema and Global State Schema SHALL never be violated. The program’s execution will fail on the first instruction that would cause the relevant schema to be violated. Writing a Bytes value to a local or global Key/Value Store such that the sum of the lengths of the key and value in bytes exceeds \( \MaxAppBytesValueLen \), or writing any value to a key longer than \( \MaxAppKeyLen \) bytes, will likewise cause the program to fail on the offending instruction.

• During the execution of an Approval Program, the total size of all boxes that are created or modified in the group MUST NOT exceed the I/O budget. The program’s execution will fail on the first instruction that would cause the constraint to be violated. If a box is deleted after creation or modification, its size is not considered in this sum.

• An attempt to access resources that are not available will cause the program execution to fail.

• Boxes MAY NOT be accessed by an application’s Clear State Program.

• In addition to the group’s named Boxes, transactions MAY also access the Boxes of Applications that were previously created in the same group. Across the execution of the entire group, the group can access as many of these unnamed boxes as the group has empty box references.

For further details on AVM Resource Availability, refer to the AVM Specifications.

$$ \newcommand \Fee {\mathrm{fee}} \newcommand \MinTxnFee {T_{\Fee,\min}} \newcommand \RekeyTo {\mathrm{RekeyTo}} \newcommand \Heartbeat {\mathrm{hb}} \newcommand \PayoutsChallengeBits {\Heartbeat_\mathrm{bits}} $$

Heartbeat Transaction Semantics

If a heartbeat transaction’s group is empty, and the fee is less than \( \MinTxnFee \), the transaction FAILS to execute unless:

• The note \( N \) is empty;

• The lease \( x \) is empty;

• The rekey to address \( \RekeyTo \) is empty;

• The heartbeat_address, \( a \), is Online;

• The heartbeat_address, \( a \), eligibility flag (ie) is True;

• The heartbeat_address, \( a \), is at risk of suspension.

An account is at risk of suspension if the current round (\( r \)) is

$$ 100\mod1000 \leq r \leq 200\mod1000, $$

and the block seed of the most recent round that is \( 0 \mod 1000 \) matches \( a \) in the first \( \PayoutsChallengeBits \) bits.

If successful, the LastHeartbeat of the specified heartbeat address \( a \) is updated to the current round.

$$ \newcommand \Genesis {\mathrm{Genesis}} \newcommand \GenesisID {\Genesis\mathrm{ID}} \newcommand \pk {\mathrm{pk}} \newcommand \spk {\mathrm{spk}} \newcommand \Tx {\mathrm{Tx}} \newcommand \TxType {\mathrm{TxType}} \newcommand \TxTail {\Tx\mathrm{Tail}} \newcommand \Hash {\mathrm{Hash}} \newcommand \FirstValidRound {r_\mathrm{fv}} \newcommand \LastValidRound {r_\mathrm{lv}} \newcommand \sppk {\mathrm{sppk}} \newcommand \nonpart {\mathrm{nonpart}} \newcommand \MaxTxTail {\mathrm{TxTail}_{\max}} \newcommand \abs[1] {\lvert #1 \rvert} \newcommand \floor[1] {\left \lfloor #1 \right \rfloor } $$

$$ \newcommand \MaxTxnNoteBytes {T_{m,\max}} \newcommand \Stake {\mathrm{Stake}} \newcommand \Fee {\mathrm{fee}} \newcommand \MinTxnFee {T_{\Fee,\min}} \newcommand \PayoutsGoOnlineFee {B_{p,\Fee}} \newcommand \Eligibility {\mathrm{A_e}} \newcommand \Units {\mathrm{Units}} \newcommand \MinBalance {b_{\min}} $$

Validity and State Changes

The new Ledger’s state that results from applying a valid block is the account state that results from applying each transaction in that block, in sequence.

For a block to be valid, each transaction in its transaction sequence MUST be valid at the block’s round \( r \) and for the block’s genesis identifier \( \GenesisID_B \).

For a transaction

$$ \Tx = (\GenesisID, \TxType, \FirstValidRound, \LastValidRound, I, I^\prime, I_0, f, a, x, N, \pk, \sppk, \nonpart, \ldots) $$

(where \( \ldots \) represents fields specific to transaction types besides payand keyreg) to be valid at the intermediate state \( \rho \) in round \( r \) for the genesis identifier \( \GenesisID_B \), the following conditions MUST all hold:

• It MUST represent a transition between two valid account states.

• Either \( \GenesisID = \GenesisID_B \) or \( \GenesisID \) is the empty string.

• \( \TxType \) is either pay, keyreg, acfg, axfer, afrz, appl, stpf, or hb.

• There are no extra fields that do not correspond to \( \TxType \).

• \( 0 \leq \LastValidRound - \FirstValidRound \leq \MaxTxTail \).

• \( \FirstValidRound \leq r \leq \LastValidRound \).

• \( \abs{N} \leq \MaxTxnNoteBytes \).

• \( I \neq I_\mathrm{pool} \), \( I \neq I_f \), and \( I \neq 0 \).

• \( \Stake(r+1, I) \geq f \geq \MinTxnFee \).

• The transaction is properly authorized as described in the Authorization and Signatures section.

• \( \Hash(\Tx) \notin \TxTail_r \).

• If \( x \neq 0 \), there exists no \( \Tx^\prime \in \TxTail \) with sender \( I^\prime \), lease value \( x^\prime \), and last valid round \( \LastValidRound^\prime \) such that \( I^\prime = I \), \( x^\prime = x \), and \( \LastValidRound^\prime \geq r \).

• If \( \TxType \) is pay,

  • \( I \neq I_k \) or both \( I^\prime \neq I_\mathrm{pool} \) and \( I_0 \neq 0 \).

  • \( \Stake(r+1, I) - f > a \) if \( I^\prime \neq I \) and \( I^\prime \neq 0 \).

  • If \( I_0 \neq 0 \), then \( I_0 \neq I \).

  • If \( I_0 \neq 0 \), \( I \) cannot hold any assets.

• If \( \TxType \) is keyreg,

  • \( p_{\rho, I} \ne 2 \) (i.e., nonparticipatory accounts may not issue keyreg transactions)

  • If \( \nonpart \) is True then \( \spk = 0 \), \( \pk = 0 \) and \( \sppk = 0 \)

Given that a transaction is valid, it produces the following updated account state for intermediate state \( \rho+1 \):

• For \( I \):

  • If \( I_0 \neq 0 \) then \( a_{\rho+1, I} = a^\prime_{\rho+1, I} = a^\ast_{\rho+1, I} = p_{\rho+1, I} = \pk_{\rho+1, I} = 0 \);

  • otherwise,

    • \( a_{\rho+1, I} = \Stake(\rho+1, I) - a - f \) if \( I^\prime \neq I \) and \( a_{\rho+1, I} = \Stake(\rho+1, I) - f \) otherwise.
    • \( a^\prime_{\rho+1, I} = T_{r+1} \).
    • \( a^\ast_{\rho+1, I} = a^\ast_{\rho, I} + (T_{r+1} - a^\prime_{\rho, I}) \floor{\frac{a_{\rho, I}}{A}} \).
    • If \( \TxType \) is pay, then \( \pk_{\rho+1, I} = \pk_{\rho, I} \) and \( p_{\rho+1, I} = p_{\rho, I} \)
    • Otherwise (i.e., if \( \TxType \) is keyreg),
      • \( \pk_{\rho+1, I} = \pk \)
      • \( p_{\rho+1, I} = 0 \) if \( \pk = 0 \) and \( \nonpart = \texttt{False} \)
      • \( p_{\rho+1, I} = 2 \) if \( \pk = 0 \) and \( \nonpart = \texttt{True} \)
      • \( p_{\rho+1, I} = 1 \) if \( \pk \ne 0 \)
      • If \( f > \PayoutsGoOnlineFee \), then \( \Eligibility{\rho+1, I} = \texttt{True} \)

• For \( I^\prime \) if \( I \neq I^\prime \) and either \( I^\prime \neq 0 \) or \( a \neq 0 \):

  • \( a_{\rho+1, I^\prime} = \Stake(\rho+1, I^\prime) + a \).

  • \( a^\prime_{\rho+1, I^\prime} = T_{r+1} \).

  • \( a^\ast_{\rho+1, I^\prime} = a^\ast_{\rho, I^\prime} + (T_{r+1} - a^\prime_{\rho, I^\prime}) \floor{\frac{a_{\rho, I^\prime}}{A}} \).

• For \( I_0 \) if \( I_0 \neq 0 \):

  • \( a_{\rho+1, I_0} = \Stake(\rho+1, I_0) + \Stake(\rho+1, I) - a - f \).

  • \( a^\prime_{\rho+1, I_0} = T_{r+1} \).

  • \( a^\ast_{\rho+1, I_0} = a^\ast_{\rho, I_0} + (T_{r+1} - a^\prime_{\rho, I_0}) \floor{\frac{a_{\rho, I_0}}{A}} \).

• For all other \( I^\ast \neq I \), the account state is identical to that in view \( \rho \).

For transaction types other than pay and keyreg, account state is updated based on the reference logic described in the Transaction section.

Additionally, for all types of transactions, if the rekey to address of the transaction is nonzero and does not match the transaction sender address, then the transaction sender account’s spending key is set to the rekey to address. If the rekey to address of the transaction does match the transaction sender address, then the transaction sender account’s spending key is set to zero.

The rest of this section describes the legacy Distribution Rewards system. If the \( R_r \) rewards rate parameter is \( 0 \), all computations keep values constant and no legacy reward distribution is carried out.

The final intermediate account \( \rho_k \) state changes the balance of the incentive pool as follows:

$$ a_{\rho_k, I_\mathrm{pool}} = a_{\rho_{k-1}, I_\mathrm{pool}} - R_r(\Units(r)) $$

An account state in the intermediate state \( \rho+1 \) and at round \( r \) is valid if all following conditions hold:

• For all addresses \( I \notin \{I_\mathrm{pool}, I_f\} \), either \( \Stake(\rho+1, I) = 0 \) or \( \Stake(\rho+1, I) \geq \MinBalance \times (1 + N_A) \), where \( N_A \) is the number of assets held by that account.

• \( \sum_I \Stake(\rho+1, I) = \sum_I \Stake(\rho, I) \).

$$ \newcommand \Stake {\mathrm{Stake}} \newcommand \Units {\mathrm{Units}} \newcommand \floor [1]{\left \lfloor #1 \right \rfloor } \newcommand \MinBalance {b_{\min}} $$

Reward State

The reward state consists of three 64-bit unsigned integers:

• The total amount of money distributed to each earning unit since the genesis state \( T_r \),

• The amount of money to be distributed to each earning unit at the next round \( R_r\),

• The amount of money left over after distribution \( B^\ast_r \).

The reward state depends on:

• The address of the incentive pool \( I_\mathrm{pool} \),

• The functions \( \Stake(r, I_\mathrm{pool}) \)

• \( \Units(r) \).

These are defined as part of the Account State.

Informally, every \( \omega_r \) rounds, the rate \( R_r \) is updated such that rewards given over the next \( \omega_r \) rounds will drain the incentive pool, leaving it with the minimum balance \( \MinBalance \).

The rewards residue \( B^\ast_r \) is the amount of leftover rewards that should have been given in the previous round but could not be evenly divided among all reward units. The residue carries over into the rewards to be given in the next round.

The actual draining of the incentive pool account is described in the Validity and State Changes section.

More formally, let \( Z = \Units(r) \).

Given a reward state \( (T_r, R_r, B^\ast_r) \), the new reward state is \( (T_{r+1}, R_{r+1}, B^\ast_{r+1}) \), where:

• \( R_{r+1} = \floor{\frac{\Stake(r, I_{pool}) - B^\ast_r - \MinBalance}{\omega_r}} \) if \(R_r \equiv 0 \bmod \omega_r \) or \( R_{r+1} = R_r \) otherwise, and

• \( T_{r+1} = T_r + \floor{\frac{R_r}{Z}} \) if \( Z \neq 0 \) or \( T_{r+1} = T_r \) otherwise, and

• \( B^\ast_{r+1} = (B^\ast_r + R_r) \bmod Z \) if \(Z \neq 0\) or \( B^\ast_{r+1} = B^\ast_r \) otherwise.

A valid block’s reward state matches the expected reward state.

Algorand Ledger Overview

The following is a non-normative specification of the Algorand Ledger.

The Algorand Ledger consists of

• The Account Table, which records the current state of the Ledger as an aggregation of individual accounts’ states,

• The Blockchain, which records the history of the accounts’ states updates since the genesis block up to the current state.

This chapter aids implementors and readers in understanding the Ledger component, as well as bridging the gap between the normative specification and the go-algorand reference implementation.

Whenever possible, we illustrate how specific subcomponents may be implemented, providing design patterns from the reference implementation.

Besides the actual Ledger as an ordered sequence of blocks, several subcomponents are defined to look up, commit, validate, and assemble said blocks and their corresponding certificates.

Some constructs are built to optimize specific fields look up in these blocks for a given round, or to get the state implicitly defined by an aggregate of their history up to a certain round. These constructs are called Trackers, and their usage and implementation details are addressed in the corresponding section.

This chapter also includes the Transaction Pool, a queue of transactions that plays a key role in the assembly of a new block, the Transaction Tail used for efficient deduplication, and a dive into the protocol Rewards system.

Blocks

Blocks are data structures that store accounts’ state transitions in the blockchain, global state fields, and information related to the agreement protocol.

A block defines a state transition of the Ledger.

Algorand block size is \( 5 \) MB.

Each block consists of a header and a body.

• The header contains metadata such as details about the block itself, the current round, various hashes, rewards, etc.,

• The body holds transaction data and account updates.

For further details on the block header, refer to the Ledger normative specification.

⚙️ IMPLEMENTATION

Block header reference implementation.

The Ledger package in the go-algorand reference implementation includes functions to effectively manage and interact with blocks.

Blocks are assembled in two steps: first by the MakeBlock function and then by the WithSeed.

⚙️ IMPLEMENTATION

MakeBlock reference implementation.

WithSeed reference implementation.

The following sections provide a brief explanation and examples for each field in the block structure.

For a formal specification of these fields, refer to the Ledger normative specification.

$$ \newcommand \VRF {\mathrm{VRF}} \newcommand \RewardsRate {\mathrm{RewardsRate}} \newcommand \RewardUnits {\mathrm{RewardUnits}} $$

Block Header

An Algorand Ledger can be minimally defined by a sequence of block headers linked by the prevHash field, as the header contains a cryptographic commitment to the contents of the block body (the payset).

The following diagram illustrates the minimal Ledger definition:

Genesis Identifier and Genesis Hash

A string and a 32-byte array, respectively.

They ensure the block belongs to the correct blockchain. These match the genesis information about the chain’s state.

📎 EXAMPLE

For the MainNet:

• Genesis ID: mainnet-v1.0
• Genesis Hash: wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8= (base64 encoding of the 32-byte array).

For the TestNet:

• Genesis ID: testnet-v1.0
• Genesis Hash: SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI= (base64 encoding of the 32-byte array).

Previous Hash

Cryptographic commitment (hash) of the previous block header, linking blocks into a chain. The genesis block has this field set to \( 0 \).

Round

A 64-bit unsigned integer value that identifies the block’s round. The genesis block has round \( 0 \). For all other cases, it must be equal to the round of the previous block plus one (that is, they must be sequential and monotonically increasing).

Seed

A 32-byte array holding a random value used as a seed for cryptographic processes (e.g., block proposer selection).

The seed calculation algorithm (see ABFT normative specification) defines implicitly a sequence of seeds, whose values alternate according to:

• The seed lookup constant \( \delta_s \),

• Some round-specific computation that depends, amongst other things, on the seed refresh interval \( \delta_r \), the period \( p \) during which the block was assembled, and on the \( \VRF \) value obtained by the block proposer.

📎 EXAMPLE

Example a valid seed chain computation.

Timestamp

A 64-bit unsigned integer.

The timestamp is purely informational and states when a block was proposed, expressed in seconds since UNIX Epoch (00:00:00 Thursday, 1 January 1970, at UTC).

The difference between consecutive timestamps cannot be greater than \( t_{\delta} = 25 \) seconds

See the formal definition in the Ledger normative specification.

📎 EXAMPLE

In the reference implementation, checks on the timestamp are performed during block assembly. See the MakeBlock function.

Consensus protocol does not guarantee the accuracy of the timestamp!

Transaction Commitment

Cryptographic commitments (hash) to the block’s transaction sequence. Internally, it uses a Merkle Tree and commits to the tree’s root.

Two different hashes are provided:

• SHA512/256,
• SHA256.

⚙️ IMPLEMENTATION

Transactions (payset) commit reference implementation.

Proposer Payout

The amount in μALGO paid to the proposer is the sum of a fee component and a bonus component. The payout is subject to eligibility criteria and protocol limits.

For further details, refer to the rewards non-normative specification.

• FeeCollected
  Total transaction fees collected in the block expressed in μALGO.

• Bonus
  A potential extra reward component of the block proposer payout, in addition to the fee component, expressed in μALGO. Subject to change during upgrades and to decrease every millionth round, according to an exponential decay curve.

Proposer

Address of the account that proposed this block.

Rewards

A structure representing the reward state. It contains the following fields:

• FeeSink
  A 32-byte array holding a constant address. This address collects transaction fees and pays block rewards.

📎 EXAMPLE

MainNet FeeSink address: Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA.

This legacy rewards distribution mechanism is currently inactive. See the non-normative section for further details on the active reward mechanism.

• RewardsPool (legacy)
  A 32-byte array holding a constant address. This address pays distribution rewards (legacy system, currently inactive).

📎 EXAMPLE

MainNet RewardsPool address: 737777777777777777777777777777777777777777777777777UFEJ2CI.

• RewardsLevel (legacy)
  A 64-bit unsigned integer holding the amount of μALGO distributed to each participant account since the genesis block.

• RewardsRate (legacy)
  A 64-bit unsigned integer indicating the amount of μALGO added to the participation stake from the RewardsPool in the next round (legacy system, currently set to \( 0 \) for every block).

• RewardsResidue (legacy)
  A 64-bit unsigned integer holding the leftover amount of μALGO after the distribution of \( \frac{\RewardsRate}{\RewardUnits} \) for every reward unit in the next round.

• RewardsRecalculationRound (legacy)
  A 64-bit unsigned integer holding the round at which the \( \RewardsRate \) will be recalculated.

Transaction Counter

A 64-bit unsigned integer counting transactions committed before this block. It is initialized at \( 0 \) or \( 1000 \) in the genesis block, depending on the AppForbidLowResources consensus parameter.

Upgrade State

This field tracks the protocol upgrade state machine. It contains a link to the currently active version of this specification.

• CurrentProtocol
  A link to the commit in the Algorand Formal Specification repository of the currently active protocol version.

• NextProtocol
  A link to the commit in the Algorand Formal Specification repository of a new protocol version being voted on.

• NextProtocolApprovals
  An uint64 integer that represents the vote count for a next protocol upgrade. Set to 0 unless a vote is ongoing.

• NextProtocolSwitchOn
  Round number at which the next protocol would be adopted. Set to 0 unless a vote is ongoing.

• NextProtocolVoteBefore
  Round number before which a vote for the next protocol version should be issued and computed. Set to 0 unless a vote is ongoing.

Upgrade Vote

This field represents the vote of the block proposer on the new protocol version.

It contains two fields:

• UpgradeApprove
  A boolean flag that indicates an affirmative vote for the new protocol version. Usually set to false unless a protocol upgrade vote is ongoing.

• UpgradeDelay
  The delay in rounds between the approval of a new protocol version and its execution. Usually set to \( 0 \) unless an upgrade vote is ongoing.

Participation Updates

A structure with two optional fields:

• Expired Participation Accounts
  An optional list of account addresses to be removed from consensus participation, due to expired participation keys (from the end of this round). Limited to \( 32 \) accounts.

• Absent Participation Accounts
  An optional list of online account addresses to be removed from consensus participation, due to long-lasting absenteeism in the expected block proposals. Limited to \( 32 \) accounts.

Block Header Examples

With Protocol Upgrade Proposal, Without Payout

{
    "genesis-hash":"wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=",
    "genesis-id":"mainnet-v1.0",
    "previous-block-hash":"owhv6q/adgf0AvSNw9cC6Va7blSQUeCRaNaVKb0bqY0=",
    "round":46000000,
    "seed":"6Sv0nt/y7Wltt+nbwMpPZwLADmNURXmFHkrihTpqKYE=",
    "timestamp":1736228624,
    "transactions-root":"4V2mkvL+vDuQcN2Vq8x4HJzZCtNd/+pChJfFW9YVxNU=",
    "transactions-root-sha256":"/nZs/lsL98Lw9NaqdT+3rdlKsFJyLqM8u4AKm42yIzg=",
    "rewards":{
        "fee-sink":"Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA",
        "rewards-calculation-round":46500000,
        "rewards-level":218288,
        "rewards-pool":"737777777777777777777777777777777777777777777777777UFEJ2CI",
        "rewards-rate":0,
        "rewards-residue":6886250026
    },
    "state-proof-tracking":[
        {
            "next-round":45999872,
            "online-total-weight":0,
            "type":0
        }
    ],
    "txn-counter":2667677491,
    "upgrade-state":{
        "current-protocol":"https://github.com/algorandfoundation/specs/tree/925a46433742afb0b51bb939354bd907fa88bf95",
        "next-protocol":"https://github.com/algorandfoundation/specs/tree/236dcc18c9c507d794813ab768e467ea42d1b4d9",
        "next-protocol-approvals":2,
        "next-protocol-switch-on":46210138,
        "next-protocol-vote-before":46002138
    },
    "upgrade-vote":{
        "upgrade-approve":false,
        "upgrade-delay":0
    }
}

Without Protocol Upgrade Proposal, With Payout

{
    "genesis-hash":"wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=",
    "genesis-id":"mainnet-v1.0",
    "previous-block-hash":"kl2qk0j7kUVQIfB53HeQMXr0aVjSQpUfLqlD0o9s/rE=",
    "round":49920000,
    "seed":"dwdIvSTHCglZ17+C/ukJMgj6zRMsh50H+4SlLaa9mO0=",
    "timestamp":1747224224,
    "transactions-root":"kgdfSAlEK8escojfUfgsiINgrVZcjghYLGBfyfDVL6Y=",
    "transactions-root-sha256":"bpefFXuYuJ2SdzUIHk8zZ9WhVd+qNMwriFjIUMNpz2Q=",
    "bonus":9702990,
    "fees-collected":673000,
    "proposer":"2R5FTTVDIAQ55I5SPW5BE6R2SVYY45O5W64XGIVBLHQYWMZARRXTO4VIHQ",
    "proposer-payout":10039490,
    "rewards":{
        "fee-sink":"Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA",
        "rewards-calculation-round":50000000,
        "rewards-level":218288,
        "rewards-pool":"737777777777777777777777777777777777777777777777777UFEJ2CI",
        "rewards-rate":0,
        "rewards-residue":6886250026
    },
    "state-proof-tracking":[
        {
            "next-round":49920000,
            "online-total-weight":1950063504685967,
            "type":0,
            "voters-commitment":"Zw1ruItyLxO/Y8L8iFaOZhW6yUOMO1KeCVDOPyK9kPvGxFRF5c/kCxihruqVsiO9ptYcqq6FnRx9X6sZpS1PBw=="
        }
    ],
    "txn-counter":2993570351,
    "upgrade-state":{
        "current-protocol":"https://github.com/algorandfoundation/specs/tree/236dcc18c9c507d794813ab768e467ea42d1b4d9",
        "next-protocol-approvals":0,
        "next-protocol-switch-on":0,
        "next-protocol-vote-before":0
    },
    "upgrade-vote":{
        "upgrade-approve":false,
        "upgrade-delay":0
    }
}

Genesis Block

This section is directly derived from the go-algorand reference implementation.

The genesis block defines the Algorand “universe”, which is initialized with:

• The initial account states (GenesisAllocation), which includes the ALGO balance and the initial consensus participation state (and keys),

• The initial consensus protocol version (GenesisProto),

• The special addresses (FeeSink and RewardsPool),

• The schema of the Ledger.

⚙️ IMPLEMENTATION

Genesis type definition in the reference implementation.

⚙️ IMPLEMENTATION

GenesisBalances type definition in the reference implementation. It contains the information needed to generate a new Ledger:

• Balances: a map with the account data for each address,
• FeeSink: address where fees are collected,
• RewardsPool: address holding distribution rewards (legacy),
• Timestamp: time when the object is created.

Genesis Block Example

The following is the Algorand MainNet genesis block:

{
  "alloc": [
    {
      "addr": "737777777777777777777777777777777777777777777777777UFEJ2CI",
      "comment": "RewardsPool",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA",
      "comment": "FeeSink",
      "state": {
        "algo": 1000000,
        "onl": 2
      }
    },
    {
      "addr": "ALGORANDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIN5DNAU",
      "comment": "A BIT DOES E NOT BUT E STARTS EVERYTHING LIFE A MANY FORTUNE R BUILD SIMPLER BE THE STARTS PERSEVERES FAVORS A ENOUGH RIPROVANDO POSSIBLE JOURNEY VICTORIA HE BOLD U WITHOUT MEN A K OF BORDERS WHO HE E RACES TOMORROW BUT WHO SINGLE PURPOSE GEOGRAPHICAL PROVANDO A KNOW SUFFOCATES NOT SCIENCE STEP MATHEMATICS OF OR A BRIDGES WALLS TECHNOLOGY TODAY AND WITH AS ET MILES OF THOUSAND VITA SIMPLE TOO MUST AS NOT MADE NOT",
      "state": {
        "algo": 1000000,
        "onl": 2
      }
    },
    {
      "addr": "XQJEJECPWUOXSKMIC5TCSARPVGHQJIIOKHO7WTKEPPLJMKG3D7VWWID66E",
      "comment": "AlgorandCommunityAnnouncement",
      "state": {
        "algo": 10000000,
        "onl": 2
      }
    },
    {
      "addr": "VCINCVUX2DBKQ6WP63NOGPEAQAYGHGSGQX7TSH4M5LI5NBPVAGIHJPMIPM",
      "comment": "AuctionsMaster",
      "state": {
        "algo": 1000000000,
        "onl": 2
      }
    },
    {
      "addr": "OGP6KK5KCMHT4GOEQXJ4LLNJ7D6P6IH7MV5WZ5EX4ZWACHP75ID5PPEE5E",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "AYBHAG2DAIOG26QEV35HKUBGWPMPOCCQ44MQEY32UOW3EXEMSZEIS37M2U",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "2XKK2L6HOBCYHGIGBS3N365FJKHS733QOX42HIYLSBARUIJHMGQZYAQDRY",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "ZBSPQQG7O5TR5MHPG3D5RS2TIFFD5NMOPR77VUKURMN6HV2BSN224ZHKGU",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "7NQED6NJ4NZU7B5HGGFU2ZEC2UZQYU2SA5S4QOE2EXBVAR4CNAHIXV2XYY",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "RX2ZKVJ43GNYDJNIOB6TIX26U7UEQFUQY46OMHX6CXLMMBHENJIH4YVLUQ",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "RHSKYCCZYYQ2BL6Z63626YUETJMLFGVVV47ED5D55EKIK4YFJ5DQT5CV4A",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "RJS6FDZ46ZZJIONLMMCKDJHYSJNHHAXNABMAVSGH23ULJSEAHZC6AQ6ALE",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "AZ2KKAHF2PJMEEUVN4E2ILMNJCSZLJJYVLBIA7HOY3BQ7AENOVVTXMGN3I",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "CGUKRKXNMEEOK7SJKOGXLRWEZESF24ELG3TAW6LUF43XRT2LX4OVQLU4BQ",
      "comment": "",
      "state": {
        "algo": 300000000000000,
        "onl": 2
      }
    },
    {
      "addr": "VVW6BVYHBG7MZQXKAR3OSPUZVAZ66JMQHOBMIBJG6YSPR7SLMNAPA7UWGY",
      "comment": "",
      "state": {
        "algo": 250000000000000,
        "onl": 2
      }
    },
    {
      "addr": "N5BGWISAJSYT7MVW2BDTTEHOXFQF4QQH4VKSMKJEOA4PHPYND43D6WWTIU",
      "comment": "",
      "state": {
        "algo": 1740000000000000,
        "onl": 2
      }
    },
    {
      "addr": "MKT3JAP2CEI5C4IX73U7QKRUF6JR7KPKE2YD6BLURFVPW6N7CYXVBSJPEQ",
      "comment": "",
      "state": {
        "algo": 158000000000000,
        "onl": 2
      }
    },
    {
      "addr": "GVCPSWDNSL54426YL76DZFVIZI5OIDC7WEYSJLBFFEQYPXM7LTGSDGC4SA",
      "comment": "",
      "state": {
        "algo": 49998988000000,
        "onl": 1,
        "sel": "lZ9z6g0oSlis/8ZlEyOMiGfX0XDUcObfpJEg5KjU0OA=",
        "vote": "Kk+5CcpHWIXSMO9GiAvnfe+eNSeRtpDb2telHb6I1EE=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "M7XKTBQXVQARLS7IVS6NVDHNLJFIAXR2CGGZTUDEKRIHRVLWL5TJFJOL5U",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "Z5gE/m2E/WSuaS5E8aYzO2DugTdSWQdc5W5BroCJdms=",
        "vote": "QHHw03LnZQhKvjjIxVj3+qwgohOij2j3TBDMy7V9JMk=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "QFYWTHPNZBKKZ4XG2OWVNEX6ETBISD2VJZTCMODIZKT3QHQ4TIRJVEDVV4",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "NthIIUyiiRVnU/W13ajFFV4EhTvT5EZR/9N6ZRD/Z7U=",
        "vote": "3KtiTLYvHJqa+qkGFj2RcZC77bz9yUYKxBZt8B24Z+c=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "DPOZQ6HRYLNNWVQL3I4XV4LMK5UZVROKGJBRIYIRNZUBMVHCU4DZWDBHYE",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "PBZ/agWgmwMdmWgt/W0NvdTN/XSTrVhPvRSMjmP5j90=",
        "vote": "FDONnMcq1acmIBjJr3vz4kx4Q8ZRZ8oIH8xXRV5c4L8=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "42GALMKS3HMDB24ZPOR237WQ5QDHL5NIRC3KIA4PCKENJZAD5RP5QPBFO4",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "p7axjoy3Wn/clD7IKoTK2Zahc5ZU+Qkt2POVHKugQU4=",
        "vote": "PItHHw+b01XplxRBFmZniqmdm+RyJFYd0fDz+OP4D6o=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "OXWIMTRZA5TVPABJF534EBBERJG367OLAB6VFN4RAW5P6CQEMXEX7VVDV4",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "RSOWYRM6/LD7MYxlZGvvF+WFGmBZg7UUutdkaWql0Xo=",
        "vote": "sYSYFRL7AMJ61egushOYD5ABh9p06C4ZRV/OUSx7o3g=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "AICDUO6E46YBJRLM4DFJPVRVZGOFTRNPF7UPQXWEPPYRPVGIMQMLY5HLFM",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "0vxjPZqEreAhUt9PHJU2Eerb7gBhMU+PgyEXYLmbifg=",
        "vote": "fuc0z/tpiZXBWARCJa4jPdmDvSmun4ShQLFiAxQkOFI=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "DYATVHCICZA7VVOWZN6OLFFSKUAZ64TZ7WZWCJQBFWL3JL4VBBV6R7Z6IE",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "KO2035CRpp1XmVPOTOF6ICWCw/0I6FgelKxdwPq+gMY=",
        "vote": "rlcoayAuud0suR3bvvI0+psi/NzxvAJUFlp+I4ntzkM=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "6XJH2PJMAXWS4RGE6NBYIS3OZFOPU3LOHYC6MADBFUAALSWNFHMPJUWVSE",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "PgW1dncjs9chAVM89SB0FD4lIrygxrf+uqsAeZw8Qts=",
        "vote": "pA4NJqjTAtHGGvZWET9kliq24Go5kEW8w7f1BGAWmKY=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "EYOZMULFFZZ5QDDMWQ64HKIMUPPNEL3WJMNGAFD43L52ZXTPESBEVJPEZU",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 1,
        "sel": "sfebD2noAbrn1vblMmeCIeGB3BxLGKQDTG4sKSNibFs=",
        "vote": "Cuz3REj26J+JhOpf91u6PO6MV5ov5b1K/ii1U1uPD/g=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "I3345FUQQ2GRBHFZQPLYQQX5HJMMRZMABCHRLWV6RCJYC6OO4MOLEUBEGU",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "MkH9KsdwiFgYtFFWFu48CeejEop1vsyGFG4/kqPIOFg=",
        "vote": "RcntidhQqXQIvYjLFtc6HuL335rMnNX92roa2LcC+qQ=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "6LQH42A4QJ3Y27FGKJWERY3MD65SXM4QQCJJR2HRJYNB427IQ73YBI3YFY",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "nF3mu9Bu0Ad5MIrT31NgTxxrsZOXc4u1+WCvaPQTYEQ=",
        "vote": "NaqWR/7FzOq/MiHb3adO6+J+kvnQKat8NSqEmoEkVfE=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "3V2MC7WJGAFU2EHWBHEETIMJVFJNAT4KKWVPOMJFJIM6ZPWEJRJ4POTXGI",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "3i4K8zdmnf1kxwgcNmI3x50iIwAxDmLMvoQEhjzhado=",
        "vote": "wfJWa0kby76rqX2yvCD/aCfJdNt+qItylDPQiuAWFkQ=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "FTXSKED23VEXNW442T2JKNPPNUC2WKFNRWBVQTFMT7HYX365IVLZXYILAI",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "icuL7ehcGonAcJ02Zy4MIHqcT+Sp1R1UURNCYJQHmo4=",
        "vote": "tmFcj3v7X5DDxKI1IDbGdhXh3a5f0Ab1ftltM7TgIDE=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "IAOW7PXLCDGLKMIQF26IXFF4THSQMU662MUU6W5KPOXHIVKHYFLYRWOUT4",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "zTn9rl/8Y2gokMdFyFP/pKg4eP02arkxlrBZIS94vPI=",
        "vote": "a0pX68GgY7u8bd2Z3311+Mtc6yDnESZmi9k8zJ0oHzY=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "4NRNE5RIGC2UGOMGMDR6L5YMQUV3Q76TPOR7TDU3WEMJLMC6BSBEKPJ2SY",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "orSV2VHPY8m5ckEHGwK0r+SM9jq4BujAICXegAUAecI=",
        "vote": "NJ9tisH+7+S29m/uMymFTD8X02/PKU0JUX1ghnLCzkw=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "E2EIMPLDISONNZLXONGMC33VBYOIBC2R7LVOS4SYIEZYJQK6PYSAPQL7LQ",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "XM2iW9wg9G5TyOfVu9kTS80LDIqcEPkJsgxaZll3SWA=",
        "vote": "p/opFfDOsIomj5j7pAYU+G/CNUIwvD2XdEer6dhGquQ=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "APDO5T76FB57LNURPHTLAGLQOHUQZXYHH2ZKR4DPQRKK76FB4IAOBVBXHQ",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "5k2vclbUQBE6zBl45F3kGSv1PYhE2k9wZjxyxoPlnwA=",
        "vote": "3dcLRSckm3wd9KB0FBRxub3meIgT6lMZnv5F08GJgEo=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "3KJTYHNHK37G2JDZJPV55IHBADU22TX2FPJZJH43MY64IFWKVNMP2F4JZE",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "o5e9VLqMdmJas5wRovfYFHgQ+Z6sQoATf3a6j0HeIXU=",
        "vote": "rG7J8pPAW+Xtu5pqMIJOG9Hxdlyewtf9zPHEKR2Q6OE=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "IVKDCE6MS44YVGMQQFVXCDABW2HKULKIXMLDS2AEOIA6P2OGMVHVJ64MZI",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "XgUrwumD7oin/rG3NKwywBSsTETg/aWg9MjCDG61Ybg=",
        "vote": "sBPEGGrEqcQMdT+iq2ududNxCa/1HcluvsosO1SkE/k=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "2WDM5XFF7ONWFANPE5PBMPJLVWOEN2BBRLSKJ37PQYW5WWIHEFT3FV6N5Y",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "Lze5dARJdb1+Gg6ui8ySIi+LAOM3P9dKiHKB9HpMM6A=",
        "vote": "ys4FsqUNQiv+N0RFtr0Hh9OnzVcxXS6cRVD/XrLgW84=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "EOZWAIPQEI23ATBWQ5J57FUMRMXADS764XLMBTSOLVKPMK5MK5DBIS3PCY",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "jtmLcJhaAknJtA1cS5JPZil4SQ5SKh8P0w1fUw3X0CE=",
        "vote": "pyEtTxJAas/j+zi/N13b/3LB4UoCar1gfcTESl0SI2I=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "REMF542E5ZFKS7SGSNHTYB255AUITEKHLAATWVPK3CY7TAFPT6GNNCHH6M",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "8ggWPvRpSkyrjxoh1SVS9PiSjff2azWtH0HFadwI9Ck=",
        "vote": "Ej/dSkWbzRf09RAuWZfC4luRPNuqkLFCSGYXDcOtwic=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "T4UBSEAKK7JHT7RNLXVHDRW72KKFJITITR54J464CAGE5FGAZFI3SQH3TI",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "eIB8MKaG2lyJyM9spk+b/Ap/bkbo9bHfvF9f8T51OQk=",
        "vote": "7xuBsE5mJaaRAdm5wnINVwm4SgPqKwJTAS1QBQV3sEc=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "YUDNQMOHAXC4B3BAMRMMQNFDFZ7GYO2HUTBIMNIP7YQ4BL57HZ5VM3AFYU",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "CSTCDvvtsJB0VYUcl3oRXyiJfhm3CtqvRIuFYZ69Z68=",
        "vote": "uBK1TH4xKdWfv5nnnHkvYssI0tyhWRFZRLHgVt9TE1k=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "4SZTEUQIURTRT37FCI3TRMHSYT5IKLUPXUI7GWC5DZFXN2DGTATFJY5ABY",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "THGOlrqElX13xMqeLUPy6kooTbXjiyrUoZfVccnHrfI=",
        "vote": "k4hde2Q3Zl++sQobo01U8heZd/X0GIX1nyqM8aI/hCY=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "UEDD34QFEMWRGYCBLKZIEHPKSTNBFSRMFBHRJPY3O2JPGKHQCXH4IY6XRI",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "jE+AUFvtp2NJsfNeUZeXdWt0X6I58YOgY+z/HB17GDs=",
        "vote": "lmnYTjg1FhRNAR9TwVmOahVr5Z+7H1GO6McmvOZZRTQ=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "HHZQOGQKMQDLBEL3HXMDX7AGTNORYVZ4JFDWVSL5QLWMD3EXOIAHDI5L7M",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "Hajdvzem2rR2GjLmCG+98clHZFY5Etlp0n+x/gQTGj0=",
        "vote": "2+Ie4MDWC6o/SfFSqev1A7UAkzvKRESI42b4NKS6Iw8=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "XRTBXPKH3DXDJ5OLQSYXOGX3DJ3U5NR6Y3LIVIWMK7TY33YW4I2NJZOTVE",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "5qe7rVoQfGdIUuDbhP2ABWivCoCstKbUsjdmYY76akA=",
        "vote": "3J3O9DyJMWKvACubUK9QvmCiArtZR7yFHWG7k7+apdQ=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "JJFGCPCZPYRLOUYBZVC4F7GRPZ5CLB6BMTVRGNDP7GRGXL6GG4JEN7DL54",
      "comment": "",
      "state": {
        "algo": 24000000000000,
        "onl": 1,
        "sel": "YoRFAcTiOgJcLudNScYstbaKJ8anrrHwQMZAffWMqYE=",
        "vote": "VQFKlDdxRqqqPUQ/mVoF8xZS9BGxUtTnPUjYyKnOVRA=",
        "voteKD": 10000,
        "voteLst": 3000000
      }
    },
    {
      "addr": "4VNSA2GZVUD5ZNO62OVVNP4NEL2LIEE5N3MZEK4BKH62KGKRLVINFZYTZM",
      "comment": "",
      "state": {
        "algo": 100000000000000,
        "onl": 2
      }
    },
    {
      "addr": "IVCEEIH2Q32DZNRTS5XFVEFFAQGERNZHHQT6S4UPY7ORJMHIQDSTX7YM4E",
      "comment": "",
      "state": {
        "algo": 408400000000000,
        "onl": 2
      }
    },
    {
      "addr": "PLFHBIRGM3ZWGAMCXTREX2N537TWOMFIQXHFO2ZGQOEPZU473SYBVGVA5M",
      "comment": "",
      "state": {
        "algo": 1011600000000000,
        "onl": 2
      }
    },
    {
      "addr": "KF7X4ZABZUQU7IFMHSKLDKWCS4F3GZLOLJRDAK5KMEMDAGU32CX36CJQ5M",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "BTEESEYQMFLWZKULSKLNDELYJTOOQK6ZT4FBCW3TOZQ55NZYLOO6BRQ5K4",
      "comment": "",
      "state": {
        "algo": 36199095000000,
        "onl": 2
      }
    },
    {
      "addr": "E36JOZVSZZDXKSERASLAWQE4NU67HC7Q6YDOCG7P7IRRWCPSWXOI245DPA",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "I5Q6RRN44OZWYMX6YLWHBGEVPL7S3GBUCMHZCOOLJ245TONH7PERHJXE4A",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "2GYS272T3W2AP4N2VX5BFBASVNLWN44CNVZVKLWMMVPZPHVJ52SJPPFQ2I",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "D5LSV2UGT4JJNSLJ5XNIF52WP4IHRZN46ZGWH6F4QEF4L2FLDYS6I6R35Y",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "UWMSBIP2CGCGR3GYVUIOW3YOMWEN5A2WRTTBH6Y23KE3MOVFRHNXBP6IOE",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "OF3MKZZ3L5ZN7AZ46K7AXJUI4UWJI3WBRRVNTDKYVZUHZAOBXPVR3DHINE",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "2PPWE36YUMWUVIFTV2A6U4MLZLGROW4GHYIRVHMUCHDH6HCNVPUKPQ53NY",
      "comment": "",
      "state": {
        "algo": 440343426000000,
        "onl": 2
      }
    },
    {
      "addr": "JRGRGRW4HYBNAAHR7KQLLBAGRSPOYY6TRSINKYB3LI5S4AN247TANH5IQY",
      "comment": "",
      "state": {
        "algo": 362684706000000,
        "onl": 2
      }
    },
    {
      "addr": "D7YVVQJXJEFOZYUHJLIJBW3ATCAW46ML62VYRJ3SMGLOHMWYH4OS3KNHTU",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "PZJKH2ILW2YDZNUIYQVJZ2MANRSMK6LCHAFSAPYT6R3L3ZCWKYRDZXRVY4",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "3MODEFJVPGUZH3HDIQ6L2MO3WLJV3FK3XSWKFBHUGZDCHXQMUKD4B7XLMI",
      "comment": "",
      "state": {
        "algo": 130000000000000,
        "onl": 2
      }
    },
    {
      "addr": "WNSA5P6C5IIH2UJPQWJX6FRNPHXY7XZZHOWLSW5ZWHOEHBUW4AD2H6TZGM",
      "comment": "",
      "state": {
        "algo": 130000000000000,
        "onl": 2
      }
    },
    {
      "addr": "OO65J5AIFDS6255WL3AESTUGJD5SUV47RTUDOUGYHEIME327GX7K2BGC6U",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "DM6A24ZWHRZRM2HWXUHAUDSAACO7VKEZAOC2THWDXH4DX5L7LSO3VF2OPU",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "NTJJSFM75RADUOUGOBHZB7IJGO7NLVBWA66EYOOPU67H7LYIXVSPSI7BTA",
      "comment": "",
      "state": {
        "algo": 18099548000000,
        "onl": 2
      }
    },
    {
      "addr": "DAV2AWBBW4HBGIL2Z6AAAWDWRJPTOQD6BSKU2CFXZQCOBFEVFEJ632I2LY",
      "comment": "",
      "state": {
        "algo": 1000000000000,
        "onl": 2
      }
    },
    {
      "addr": "M5VIY6QPSMALVVPVG5LVH35NBMH6XJMXNWKWTARGGTEEQNQ3BHPQGYP5XU",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "WZZLVKMCXJG3ICVZSVOVAGCCN755VHJKZWVSVQ6JPSRQ2H2OSPOOZKW6DQ",
      "comment": "",
      "state": {
        "algo": 45248869000000,
        "onl": 2
      }
    },
    {
      "addr": "XEJLJUZRQOLBHHSOJJUE4IWI3EZOM44P646UDKHS4AV2JW7ZWBWNFGY6BU",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "OGIPDCRJJPNVZ6X6NBQHMTEVKJVF74QHZIXVLABMGUKZWNMEH7MNXZIJ7Q",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "G47R73USFN6FJJQTI3JMYQXO7F6H4LRPBCTTAD5EZWPWY2WCG64AVPCYG4",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "PQ5T65QB564NMIY6HXNYZXTFRSTESUEFIF2C26ZZKIZE6Q4R4XFP5UYYWI",
      "comment": "",
      "state": {
        "algo": 5000000000000,
        "onl": 2
      }
    },
    {
      "addr": "R6S7TRMZCHNQPKP2PGEEJ6WYUKMTURNMM527ZQXABTHFT5GBVMF6AZAL54",
      "comment": "",
      "state": {
        "algo": 1000000000000,
        "onl": 2
      }
    },
    {
      "addr": "36LZKCBDUR5EHJ74Q6UWWNADLVJOHGCPBBQ5UTUM3ILRTQLA6RYYU4PUWQ",
      "comment": "",
      "state": {
        "algo": 5000000000000,
        "onl": 2
      }
    },
    {
      "addr": "JRHPFMSJLU42V75NTGFRQIALCK6RHTEK26QKLWCH2AEEAFNAVEXWDTA5AM",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "64VZVS2LFZXWA5W3S657W36LWGP34B7XLMDIF4ROXBTPADD7SR5WNUUYJE",
      "comment": "",
      "state": {
        "algo": 171945701000000,
        "onl": 2
      }
    },
    {
      "addr": "TXDBSEZPFP2UB6BDNFCHCZBTPONIIQVZGABM4UBRHVAAPR5NE24QBL6H2A",
      "comment": "",
      "state": {
        "algo": 60000000000000,
        "onl": 2
      }
    },
    {
      "addr": "XI5TYT4XPWUHE4AMDDZCCU6M4AP4CAI4VTCMXXUNS46I36O7IYBQ7SL3D4",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "Y6ZPKPXF2QHF6ULYQXVHM7NPI3L76SP6QHJHK7XTNPHNXDEUTJPRKUZBNE",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "6LY2PGUJLCK4Q75JU4IX5VWVJVU22VGJBWPZOFP3752UEBIUBQRNGJWIEA",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "L7AGFNAFJ6Z2FYCX3LXE4ZSERM2VOJF4KPF7OUCMGK6GWFXXDNHZJBEC2E",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "RYXX5U2HMWGTPBG2UDLDT6OXDDRCK2YGL7LFAKYNBLRGZGYEJLRMGYLSVU",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "S263NYHFQWZYLINTBELLMIRMAJX6J5CUMHTECTGGVZUKUN2XY6ND2QBZVY",
      "comment": "",
      "state": {
        "algo": 21647524000000,
        "onl": 2
      }
    },
    {
      "addr": "AERTZIYYGK3Q364M6DXPKSRRNSQITWYEDGAHXC6QXFCF4GPSCCSISAGCBY",
      "comment": "",
      "state": {
        "algo": 19306244000000,
        "onl": 2
      }
    },
    {
      "addr": "34UYPXOJA6WRTWRNH5722LFDLWT23OM2ZZTCFQ62EHQI6MM3AJIAKOWDVQ",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "EDVGNQL6APUFTIGFZHASIEWGJRZNWGIKJE64B72V36IQM2SJPOAG2MJNQE",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    },
    {
      "addr": "RKKLUIIGR75DFWGQOMJB5ZESPT7URDPC7QHGYKM4MAJ4OEL2J5WAQF6Z2Q",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "M4TNVJLDZZFAOH2M24BE7IU72KUX3P6M2D4JN4WZXW7WXH3C5QSHULJOU4",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "WQL6MQS5SPK3CR3XUPYMGOUSCUC5PNW5YQPLGEXGKVRK3KFKSAZ6JK4HXQ",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "36JTK4PKUBJGVCWKXZTAG6VLJRXWZXQVPQQSYODSN6WEGVHOWSVK6O54YU",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "YFOAYI4SNXJR2DBEZ3O6FJOFSEQHWD7TYROCNDWF6VLBGLNJMRRHDXXZUI",
      "comment": "",
      "state": {
        "algo": 30000000000000,
        "onl": 2
      }
    },
    {
      "addr": "XASOPHD3KK3NNI5IF2I7S7U55RGF22SG6OEICVRMCTMMGHT3IBOJG7QWBU",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "H2AUGBLVQFHHFLFEPJ6GGJ7PBQITEN2GE6T7JZCALBKNU7Q52AVJM5HOYU",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "GX3XLHSRMFTADVKJBBQBTZ6BKINW6ZO5JHXWGCWB4CPDNPDQ2PIYN4AVHQ",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "VBJBJ4VC3IHUTLVLWMBON36Y5MPAMPV4DNGW5FQ47GRLPT7JR5PQOUST2E",
      "comment": "",
      "state": {
        "algo": 4524887000000,
        "onl": 2
      }
    },
    {
      "addr": "7AQVTOMB5DJRSUM4LPLVF6PY3Y5EBDF4RZNDIWNW4Z63JYTAQCPQ62IZFE",
      "comment": "",
      "state": {
        "algo": 50000000000000,
        "onl": 2
      }
    },
    {
      "addr": "B4ZIHKD4VYLA4BAFEP7KUHZD7PNWXW4QLCHCNKWRENJ2LYVEOIYA3ZX6IA",
      "comment": "",
      "state": {
        "algo": 40000000000000,
        "onl": 2
      }
    },
    {
      "addr": "G5RGT3EENES7UVIQUHXMJ5APMOGSW6W6RBC534JC6U2TZA4JWC7U27RADE",
      "comment": "",
      "state": {
        "algo": 10000000000000,
        "onl": 2
      }
    },
    {
      "addr": "5AHJFDLAXVINK34IGSI3JA5OVRVMPCWLFEZ6TA4I7XUZ7I6M34Q56DUYIM",
      "comment": "",
      "state": {
        "algo": 20000000000000,
        "onl": 2
      }
    }
  ],
  "fees": "Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA",
  "id": "v1.0",
  "network": "mainnet",
  "proto": "https://github.com/algorandfoundation/specs/tree/5615adc36bad610c7f165fa2967f4ecfa75125f0",
  "rwd": "737777777777777777777777777777777777777777777777777UFEJ2CI",
  "timestamp": 1560211200
}

Block Verification

After the block is assembled or a block is received from the network, a series of checks are performed to verify the integrity of the block.

• Validate that all transactions are Alive (can be applied to the Ledger) for the round,

• Validate that the payset has valid signatures and the underlying transactions are properly constructed.

Transactions

A transaction defines a state transition of Accounts.

Algorand has \( 8 \) transaction types.

Transactions consist of:

• A header (common to any type),

• A body (type-specific).

⚙️ IMPLEMENTATION

Transaction package.

Transaction Levels

Algorand transactions have two execution levels:

• Top Level: transactions are signed and cannot be duplicated in the Ledger,

• Inner Level: transactions are not signed and may be duplicated in the Ledger.

Transaction Types

The transaction type is identified with a short string of at most 7 characters:

For a formal definition of all transaction fields, refer to the normative section.

⚙️ IMPLEMENTATION

The reference implementation also defines the unknown transaction type.

Transaction types definition.

⚙️ IMPLEMENTATION

Transaction types reference implementation.

Transaction Header

The transaction header, equal for all transaction types, consists of:

• TransactionType Identifies the transaction type and the related body required fields.

• Sender
  That signs the transaction.

• Fee
  The amount paid by the sender to execute the transaction. Fees can be delegated (set to \( 0 \)) within a transaction Group.

• FirstValidRound \( \r_F \) and LastValidRound \( \r_L \)
  The difference \( (r_L - r_F) \) cannot be greater than \( 1000 \) rounds.

• Note (Optional)
  Contains up to \( 1 \) kB of arbitrary data.

• GenesisHash
  Ensures the transaction targets a specific Ledger (e.g., wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8= for MainNet).

• GenesisID (Optional)
  Like the Genesis Hash, it ensures that the transaction targets a specific Ledger (e.g., mainnet-v1.0 for MainNet).

• Group (Optional)
  A cryptographic commitment to the group this transaction is part of.

• Lease (Optional)
  32-byte array that enforces mutual exclusion of transactions. If this field is set, it acquires a Lease(Sender, Lease), valid until the LastValidRound \( r_L \) expires. While the transaction maintains the Lease, no other transaction with the same Lease can be committed.

A typical use case of the Lease is a batch of signed transactions, with the same Lease, sent to the network to ensure only one is executed.

• RekeyTo
  An Algorand address (32-byte). If non-zero, the transaction will set the Sender account’s spending key to this address as last transaction effect. Therefore, future transactions sent by the Sender account must now be signed with the secret key of the address.

The transaction header verification ensures that a transaction:

• Is signed adequately by the Sender (either SingleSig, MultiSig, or LogicSig),

• It is submitted to the right Ledger (GenesisHash);

• Pays the MinFee (\( 1000 \) μALGO) or PerByteFee (if network is congested);

  • Fee act as an anti-spam mechanism (grows exponentially if the network is congested or decays if there is spare block capacity);
  • Fee prioritization is not enforced by consensus (although a node does that);
  • Inner Transaction costs always the MinFee (regardless of network congestion);
  • Fee are pooled in Group transactions;
  • Fee is independent of the TransactionType or usage (i.e., no local fee market);

• Round’s validity is not expired (\( 1000 \) rounds at most);

• FirstValidRound can be delayed in the future;

• Round’s validity handles transactions’ idempotency, letting Non-Archival nodes participate in consensus;

• It is not leased (combination of Sender and Lease) in its validity range.

Trackers

The Ledger module includes a collection of auxiliary components known as Trackers.

Trackers are state machines that evolve by consuming blocks from the blockchain.

Although logically stateless, meaning Trackers can rebuild their state from scratch by replaying all blocks since the genesis block every time, the reference implementation designs them to persist their state to speed up Ledger reconstruction.

Trackers are widely used in go-algorand to maintain efficient, read-optimized views over different aspects of Ledger state.

Below is an overview of the main Trackers and their responsibilities:

• Account Tracker
  Maintains account states up to a given round. Key methods include:

  • Lookup(round, address): Retrieves the state of the account (address) at the specified round.

  • AllBalances(round): Returns all account states at the specified round.

  • Totals(round): Returns aggregate account totals for a given round, which is useful when querying for total account balance in the cryptographic sortition. >

• Recent Transactions Tracker
  Uses the Transaction Tail to efficiently check whether a given transaction ID (txid) was included in a recent block.

• State Proof Verification Tracker
  Maintains the necessary context to verify State Proofs (see State Proof normative specification.

• Voters Tracker
  Tracks the vector commitment representing the most recent set of online accounts participating in the State Proofs.

• Catchpoint Tracker
  Monitors the Catch-Up process used during node synchronization (see the non-normative specification).

Trackers API

Each Tracker exposes tracker-specific APIs to access the state it maintains.

⚙️ IMPLEMENTATION

Tracker reference implementation.

Trackers can access the Ledger via a restricted interface called ledgerForTracker, which grants access to the Ledger’s SQLite database, recent blocks, and other read-only functionality.

In the other direction, the Ledger communicates with Trackers using the ledgerTracker interface, which includes the following key methods:

• loadFromDisk(ledgerForTracker)
  Initializes the state of the Tracker. The Tracker can use the ledgerForTracker argument to:

  • Load persistent state (e.g., for the accounts database),
  • Query recent blocks, if its state depends only on recent history (e.g., the one that tracks recently committed transactions).

• newBlock(rnd, delta)
  Notifies the Tracker of a newly added block at round rnd. The accompanying delta parameter contains the state changes introduced by this block (see block evaluation section).

• committedUpTo(rnd)
  Informs the Tracker that all blocks up to and including rnd are written to persistent storage. This call is crucial for stateful trackers, as it ensures correct state recovery and enables responses to queries about older blocks if recent uncommitted ones are lost after a crash.

• close()
  Releases any resources or memory held by the Tracker.

The reference implementation ensures that all updates to Trackers are thread-safe using a reader-writer lock.

Protocol Rewards

The Algorand protocol has two reward systems:

1. Distribution Rewards (Legacy)

2. Staking Rewards

Rewards are distributed during the final stage of block assembly (in both systems).

The rewards systems are not mutually exclusive.

Distribution Rewards (Legacy)

The first reward system grants ALGO rewards to all the accounts, unless opted out of rewards, through a passive distribution of ALGO from the Rewards Pool, regardless of their participation in the consensus. The reward amount is proportional to the accounts’ ALGO balance.

Rewards distributed through this system are claimed and added to the account’s balance on each account state change (e.g., sending or receiving a transaction).

This system is disabled on MainNet and is kept for legacy and retro-compatibility reasons.

⚙️ IMPLEMENTATION

Distribution rewards reference implementation.

Staking Rewards

The second reward system grants ALGO rewards to accounts actively participating in the consensus protocol, if they meet eligibility criteria when selected as block proposers (see the following section for further details). The reward amount per block depends on the fee collected from the transactions included in the block, and an exponentially decaying bonus.

Rewards distributed through this system are instantly added to the block proposer balance, in the proposed block.

Staking rewards reference implementation.

Staking Rewards

This section is derived directly from the go-algorand documentation.

Running a validator node on Algorand is a relatively lightweight operation. Therefore, participation in consensus was not compensated. There was an expectation that financially motivated holders of Algos would run nodes in order to help secure their holdings.

Although simple participation is not terribly resource intensive, running any service with high uptime becomes expensive when one considers that it should be monitored for uptime, be somewhat over-provisioned to handle unexpected load spikes, and plans need to be in place to restart in the face of hardware failure (or the accounts should leave consensus properly).

With those burdens in mind, fewer Algo holders chose to run participation nodes than would be preferred to provide security against well-financed bad actors. To alleviate this problem, a mechanism to reward block proposers has been created. With these block payouts in place, Algo holders are incentivized to run participation nodes in order to earn more Algos, increasing security for the entire Algorand network.

With the financial incentive to run participation nodes comes the risk that some nodes may be operated without sufficient care. Therefore, a mechanism to suspend nodes that appear to be performing poorly (or not at all) is required. Appearances can be deceiving, however. Since Algorand is a probabilistic consensus protocol, pure chance might lead to a node appearing to be delinquent. A new transaction type, the heartbeat, allows a node to explicitly indicate that it is online even if it does not propose blocks due to “bad luck”.

Payouts

Payouts are made in every block, if the proposer has opted into receiving them, has an Algo balance in an appropriate range, and has not been suspended for poor behavior since opting-in. The size of the payout is indicated in the block header, and comes from the FeeSink. The block payout consists of two components. First, a portion of the block fees (currently 50%) are paid to the proposer. This component incentivizes fuller blocks which lead to larger payouts. Second, a bonus payout is made according to an exponentially decaying formula. This bonus is (intentionally) unsustainable from protocol fees. It is expected that the Algorand Foundation will seed the FeeSink with sufficient funds to allow the bonuses to be paid out according to the formula for several years. If the FeeSink has insufficient funds for the sum of these components, the payout will be as high as possible while maintaining the FeeSink’s minimum balance. These calculations are performed in endOfBlock in eval/eval.go.

To opt-in to receive block payouts, an account includes an extra fee in the keyreg transaction. The amount is controlled by the consensus parameter Payouts.GoOnlineFee. When such a fee is included, a new account state bit, IncentiveEligible is set to true.

Even when an account is IncentiveEligible there is a proposal-time check of the account’s online stake. If the account has too much or too little, no payout is performed (though IncentiveEligible remains true). As explained below, this check occurs in agreement code in payoutEligible(). The balance check is performed on the online stake, that is the stake from 320 rounds earlier, so a clever proposer can not move Algos in the round it proposes in order to receive the payout. Finally, in an interesting corner case, a proposing account could be closed at proposal time, since voting is based on the earlier balance. Such an account receives no payout, even if its balance was in the proper range 320 rounds ago.

A surprising complication in the implementation of these payouts is that when a block is prepared by a node, it does not know which account is the proposer. Until now, algod could prepare a single block which would be used by any of the accounts it was participating for. The block would be handed off to agreement which would manipulate the block only to add the appropriate block seed (which depended upon the proposer). That interaction between eval and agreement was widened (see WithProposer()) to allow agreement to modify the block to include the proper Proposer, and to zero the ProposerPayout if the account that proposed was not actually eligible to receive a payout.

Suspensions

Accounts can be suspended for poor behavior. There are two forms of poor behavior that can lead to suspension. First, an account is considered absent if it fails to propose as often as it should. Second, an account can be suspended for failing to respond to a challenge issued by the network at random.

Absenteeism

An account can be expected to propose once every n = TotalOnlineStake/AccountOnlineStake rounds. For example, a node with 2% of online stake ought to propose once every 50 rounds. Of course the actual proposer is chosen by random sortition. To make false positive suspensions unlikely, a node is considered absent if it fails to produce a block over the course of 20n rounds.

The suspension mechanism is implemented in generateKnockOfflineAccountsList in eval/eval.go. It is closely modeled on the mechanism that knocks accounts offline if their voting keys have expired. An absent account is added to the AbsentParticipationAccounts list of the block header. When evaluating a block, accounts in AbsentParticipationAccounts are suspended by changing their Status to Offline and setting IncentiveEligible to false, but retaining their voting keys.

Keyreg and LastHeartbeat

As described so far, 320 rounds after a keyreg to go online, an account suddenly is expected to have proposed more recently than 20 times its new expected interval. That would be impossible, since it was not online until that round. Therefore, when a keyreg is used to go online and become IncentiveEligible, the account’s LastHeartbeat field is set 320 rounds into the future. In effect, the account is treated as though it proposed in the first round it is online.

Large Algo increases and LastHeartbeat

A similar problem can occur when an online account receives Algos. 320 rounds after receiving the new Algos, the account’s expected proposal interval will shrink. If, for example, such an account increases by a factor of 10, then it is reasonably likely that it will not have proposed recently enough, and will be suspended immediately. To mitigate this risk, any time an online, IncentiveEligible account balance doubles from a single Pay, its LastHeartbeat is incremented to 320 rounds past the current round.

Challenges

The absenteeism checks quickly suspend a high-value account if it becomes inoperative. For example, an account with 2% of stake can be marked absent after 500 rounds (about 24 minutes). After suspension, the effect on consensus is mitigated after 320 more rounds (about 15 minutes). Therefore, the suspension mechanism makes Algorand significantly more robust in the face of operational errors.

However, the absenteeism mechanism is very slow to notice small accounts. An account with 30,000 Algos might represent 1/100,000 or less of total stake. It would only be considered absent after a million or more rounds without a proposal. At current network speeds, this is about a month. With such slow detection, a financially motivated entity might make the decision to run a node even if they lack the wherewithal to run the node with excellent uptime. A worst case scenario might be a node that is turned off daily, overnight. Such a node would generate profit for the runner, would probably never be marked offline by the absenteeism mechanism, yet would impact consensus negatively. Algorand can’t make progress with 1/3 of nodes offline at any given time for a nightly rest.

To combat this scenario, the network generates random challenges periodically. Every Payouts.ChallengeInterval rounds (currently 1000), a random selected portion (currently 1/32) of all online accounts are challenged. They must heartbeat within Payouts.ChallengeGracePeriod rounds (currently 200), or they will be subject to suspension. With the current consensus parameters, nodes can be expected to be challenged daily. When suspended, accounts must keyreg with the GoOnlineFee in order to receive block payouts again, so it becomes unprofitable for these low-stake nodes to operate with poor uptimes.

Heartbeats

The absenteeism mechanism is subject to rare false positives. The challenge mechanism explicitly requires an affirmative response from nodes to indicate they are operating properly on behalf of a challenged account. Both of these needs are addressed by a new transaction type — Heartbeat. A Heartbeat transaction contains a signature (HbProof) of the blockseed (HbSeed) of the transaction’s FirstValid block under the participation key of the account (HbAddress) in question. Note that the account being heartbeat for is not the Sender of the transaction, which can be any address. Signing a recent block seed makes it more difficult to pre-sign heartbeats that another machine might send on your behalf. Signing the FirstValid’s blockseed (rather than FirstValid-1) simply enforces a best practice: emit a transaction with FirstValid set to a committed round, not a future round, avoiding a race. The node you send transactions to might not have committed your latest round yet.

It is relatively easy for a bad actor to emit Heartbeats for its accounts without actually participating. However, there is no financial incentive to do so. Pretending to be operational when offline does not earn block payouts. Furthermore, running a server to monitor the blockchain to notice challenges and gather the recent blockseed is not significantly cheaper than simply running a functional node. It is already possible for malicious, well-resourced accounts to cause consensus difficulties by putting significant stake online without actually participating. Heartbeats do not mitigate that risk. Heartbeats have rather been designed to avoid motivating such behavior, so that they can accomplish their actual goal of noticing poor behavior stemming from inadvertent operational problems.

Free Heartbeats

Challenges occur frequently, so it important that algod can easily send Heartbeats as required. How should these transactions be paid for? Many accounts, especially high-value accounts, would not want to keep their spending keys available for automatic use by algod. Further, creating (and keeping funded) a low-value side account to pay for Heartbeats would be an annoying operational overhead. Therefore, when required by challenges, heartbeat transactions do not require a fee. Therefore, any account, even an unfunded logicsig, can send heartbeats for an account under challenge.

The conditions for a free Heartbeat are:

1. The Heartbeat is not part of a larger group, and has a zero GroupID.
2. The HbAddress is Online and under challenge with the grace period at least half over.
3. The HbAddress is IncentiveEligible.
4. There is no Note, Lease, or RekeyTo.

Heartbeat Service

The Heartbeat Service (heartbeat/service.go) watches the state of all accounts for which algod has participation keys. If any of those accounts meets the requirements above, a heartbeat transaction is sent, starting with the round following half a grace period from the challenge. It uses the (presumably unfunded) logicsig that does nothing except preclude rekey operations.

The heartbeat service does not heartbeat if an account is unlucky and threatened to be considered absent. We presume such false positives to be so unlikely that, if they occur, the node must be brought back online manually. It would be reasonable to consider in the future:

1. Making heartbeats free for accounts that are “nearly absent”.

or

1. Allowing for paid heartbeats by the heartbeat service when configured with access to a funded account’s spending key.

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \TxTail {\mathrm{TxTail}} \newcommand \CheckDuplicate {\mathrm{CheckDuplicate}} \newcommand \Tx {\mathrm{Tx}} \newcommand \ID {\mathrm{ID}} \newcommand \Lease {\mathrm{Lease}} \newcommand \FirstValid {\mathrm{FirstValid}} \newcommand \LastValid {\mathrm{LastValid}} \newcommand \LowWaterMark {\mathrm{LowWaterMark}} \newcommand \FirstChecked {\mathrm{FirstChecked}} \newcommand \LastChecked {\mathrm{LastChecked}} \newcommand \RecentLeaseMap {\mathrm{RecentLeaseMap}} \newcommand \LastValidMap {\mathrm{LastValidMap}} $$

Transaction Tail

The Transaction Tail \( \TxTail \) is a data structure responsible for deduplication and recent history lookups. It can be considered a rolling window of recent transactions and block headers observed in a reduced history of rounds, optimized for lookup and retrieval.

⚙️ IMPLEMENTATION

Transaction tail reference implementation.

It provides the following fields:

• recentLeaseMap
  A mapping of round -> (TXLease -> round) that saves the transaction Lease by observation round, and the mapping uses TXLease as keys to store the Lease expiring round.

• blockHeaderData
  Contains recent block header data. The expected availability range is [Latest - MaxTxnLife, Latest], allowing MaxTxnLife + 1 rounds of lookback ( \( 1001 \) with current parameters).

• lastValidMap
  A mapping of round -> (txid -> uint16) that enables the lookup of all transactions expiring in a given round. For each round, the inner map stores txids mapped to 16-bit unsigned integers representing the difference between the transaction’s lastValid field and the round it was confirmed (lastValid > confirmationRound for all confirmed transactions).

• lowWaterMark
  An unsigned 64-bit integer representing a round number such that for any transactions where the lastValid field is lastValid < lowWaterMark, the node can quickly assert that it is not present in the \( \TxTail \).

Deduplication Check

A duplication check is the core functionality of \( \TxTail \).

\( \textbf{Algorithm 1} \text{: Check Duplicate} \)

$$ \begin{aligned} &\text{1: } \PSfunction \CheckDuplicate(\Tx_r, \FirstValid, \LastValid, \Tx_{\ID}, \Tx_{\Lease}) \\ &\text{2: } \quad \PSif \LastValid < \TxTail.\LowWaterMark \PSthen \\ &\text{3: } \quad \quad \PSreturn \Tx_{\ID} \text{ is not in } \TxTail \\ &\text{4: } \quad \PSendif \\ &\text{5: } \quad \PSif \Tx_{\Lease} \neq \emptyset \PSthen \\ &\text{6: } \quad \quad \FirstChecked \gets \FirstValid \\ &\text{7: } \quad \quad \LastChecked \gets \LastValid \\ &\text{8: } \quad \quad \PSfor r \in [\FirstChecked, \LastChecked] \PSdo \\ &\text{9: } \quad \quad \quad \PSif \Tx_{\Lease} \in \RecentLeaseMap(\Tx_r).\Lease \land r \leq \Tx_{\Lease}.\mathrm{Expiration} \PSthen \\ &\text{10:} \quad \quad \quad \quad \PSreturn \Lease \text{ is a duplicate} \\ &\text{11:} \quad \quad \quad \PSendif \\ &\text{12:} \quad \quad \PSendfor \\ &\text{13:} \quad \PSendif \\ &\text{14:} \quad \PSif \Tx_{\ID} \in \TxTail.\LastValidMap(\LastValid).\Tx_{\ID} \PSthen \\ &\text{15:} \quad \quad \PSreturn \Tx_{\ID} \text{ is a duplicate transaction} \\ &\text{16:} \quad \PSendif \\ &\text{17:} \quad \PSreturn \\ &\text{18: } \PSendfunction \end{aligned} $$

The algorithm receives four fields of a transaction:

• The transaction round \( \Tx_r \),

• The transaction validity round fields \( \FirstValid \) and \( \LastValid \),

• The transaction identifier \( \Tx_{\ID} \),

• The transaction lease \( \Tx_{\Lease} \) (if set).

An early check is performed, where the \( \LowWaterMark \) field is used to quickly discard transactions too far back in history and already purged from the \( \ TxTail \).

In case a \( \Tx_{\Lease} \) is set, the \( \RecentLeaseMap \) field is used to deduplicate by \( \Lease \).

After checking for the \( \Lease \), the \( \LastValidMap \) is used and the transaction is deduplicated through a lookup of \( \Tx_{\ID} \) by its \( \LastValid \) round.

If the transaction is not found on the \( \TxTail \), the node can assume it is not a duplicate, otherwise the validity interval would be too far back in the past for the transaction to be confirmed anyway.

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \Tx {\mathrm{Tx}} \newcommand \LastValid {\mathrm{LastValid}} \newcommand \BlockEval {\mathrm{BlockEvaluator}} $$

Transaction Pool

The Transaction Pool \( \TP \) is a Ledger component that maintains a queue of transactions received by the node.

This section presents an implementor-oriented definition of \( \TP \) and is based on the reference implementation to clarify how it is constructed and operated by a node.

The \( \TP \) implementation makes use of two distinct queues to aid the processes of pruning already observed transactions and block commitment:

• The remembered queue \( \TP_{rq} \),

• The pending queue \( \TP_{pq} \).

The pending queue \( \TP_{pq} \) is the main structure used to supply transactions to the active pending \( \BlockEval \), which evaluates transactions for the next block.

⚙️ IMPLEMENTATION

Pending block evaluator reference implementation.

⚙️ IMPLEMENTATION

Here we provide some implementation details about the remembered queue \( \TP_{rq} \) and the pending queue \( \TP_{pq} \) structures used in the \( \TP \).

Whenever a new block is confirmed and committed to the Ledger, the node triggers OnNewBlock.

This function may rebuild the pending \( \BlockEval \) (except for a future round’s pending \( \BlockEval \)). As part of this process, the pending queue \( \TP_{pq} \) is synchronized with the remembered queue \( \TP_{rq} \) by replacing its contents entirely.

In contrast, when the Remember function is called, the verified transaction group is first appended to the remembered queue \( \TP_{rq} \). Then the entire \( \TP_{rq} \) is appended to \( \TP_{pq} \) rather than replacing it. This causes the two queues to diverge temporarily until the next OnNewBlock call resyncs them.

Example of Remember function used by the txnHandler to enqueue a verified transaction group in the reference implementation.

For more detail, see the rememberCommit(bool flush) function, which controls how \( \TP_{pq} \) is updated from \( \TP_{rq} \).

If flush=true, \( \TP_{pq} \) is completely overwritten; if flush=false, \( \TP_{rq} \) is appended.

In summary:

• OnNewBlock → calls rememberCommit(true) → replaces \( \TP_{pq} \) with \( \TP_{rq} \).

• Remember → appends to \( \TP_{rq} \), then calls rememberCommit(false) → appends \( \TP_{rq} \) to \( \TP_{pq} \).

Temporary queue divergence is expected and resolved at the next block confirmation.

Given a properly signed and well-formed transaction group \( gtx \in \TP_{pq} \), we say that \( gtx \) is remembered when it is pushed into \( \TP_{rq} \) if:

• Its aggregated fee is sufficiently high,

• Its state changes are consistent with the prior transactions in \( \TP_{rq} \).

Note that a single transaction can be viewed as a group \( gtx \) containing only one transaction.

\( \TP_{rq} \) is structured as a two-dimensional array. Each element in this array holds a list of well-formed, signed transactions.

To improve efficiency, the node also uses a key-value mapping where the keys are transaction IDs and the values are the corresponding signed transactions. This map duplicates the data in the queue, which adds a small computational cost when updating the queue (for insertions and deletions), but it enables fast, constant-time \( \mathcal{O}(1) \) lookup of any enqueued transaction by its ID.

Additionally, \( \TP_{pq} \) serves as another layer of optimization. It stores transaction groups that are prepared in advance for the next block assembly process. In a multithreaded system with strict timing constraints, this setup allows \( \TP_{rq} \) to be pruned as soon as a new block is committed, even while the next block is being assembled concurrently.

Transaction Pool Functions

The following is a list of abstracted minimal functionalities that the \( \TP \) should provide.

Prioritization

An algorithm that decides which transactions should be retained and which ones should be dropped, especially important when the \( \TP \) becomes congested (i.e., when transactions are arriving faster than they can be processed, de-enqueued in a block, or observed in a committed block and pruned). A simple approach could be a “first-come, first-served” policy. However, the go-algorand reference implementation uses a more selective method: a threshold-based fee prioritization algorithm, which prioritizes transactions paying higher fees.

Update

This process is triggered when a new block is observed as committed. At this point, transactions are pruned if they meet either of the following conditions:

• They have already been included in a committed block (as determined by the OnNewBlock function), or
• Their LastValid field has expired. Specifically, if the current round \( r > \Tx_{\LastValid}\).

In addition to pruning outdated or committed transactions, this step also updates the internal variables used for the prioritization.

Ingestion

This component handles the ingestion of new transaction groups (\( gtx \)) that are to be remembered (enqueued to \( \TP_{rq} \)). Before enqueuing, it verifies that each transaction group is internally valid and consistent in the context of transactions already present in \( \TP_{rq} \). Once transactions pass these checks, they are forwarded to any active Block Evaluator, so they can be considered for inclusion in blocks currently being assembled.

BlockAssembly

This process builds a new block’s payset (the body with block’s transactions) by selecting valid transaction groups \( gtx \) dequeued from the \( \TP \), all within a deadline. A (pending) Block Evaluator is responsible for processing the transactions, while the BlockAssembly function coordinates with it. The assembly process halts as soon as the time constraints are reached.

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \AD {\mathrm{assemblyDeadline}} \newcommand \AW {\mathrm{assemblyWait}} \newcommand \NB {\mathrm{newBlock}} \newcommand \FeeMul {\mathrm{feeThresholdMultiplier}} \newcommand \FeeExp {\mathrm{expFeeFactor}} \newcommand \FeePB {\mathrm{feePerByte}} \newcommand \ExpiredHistory {\mathrm{expiredHistory}} $$

In the context of this section, the phrase “giving up” refers to finalizing the current block under assembly; this includes completing the payset and calculating all associated metadata that depends on it.

Parameters

This section presents a list of some relevant parameters that govern the behavior of the \( \TP \).

In the case that there are leftover transactions in the \( \TP_{pq} \), the \( \TP \) saves them for the next block assembly.

\( \TP.\mathrm{Size} \)

A consensus parameter that defines the maximum number of transactions the transaction pool queue can hold. When this limit is reached, any new incoming transactions, even if valid, are not enqueued and are instead dropped.

⚙️ IMPLEMENTATION

In the go-algorand reference implementation, this limit is set to \( 75{,}000 \) transactions.

\( \FeeMul \)

This dynamic parameter is updated each time a new block is observed. Under normal conditions, when the \( \TP \) is not congested, its value is \( 0 \). However, if the queues become congested, this parameter increases. As it grows, it raises the minimum fee threshold required for transactions to be accepted into \( \TP \).

For more details, see the update and fee prioritization sections.

\( \FeeExp \)

A consensus parameter, denoted as TxPoolExponentialIncreaseFactor, which determines how sharply the required transaction fee increases based on the number of full blocks pending (an indicator of \( \TP \) congestion). This factor amplifies the fee threshold in congested conditions. The default value in go-algorand consensus parameters is currently set to \( 2 \).

\( \FeePB \)

A dynamically computed parameter that defines the current minimum number of μALGO per byte that a transaction must pay to be accepted into the \( \TP \). When the \( \TP \) is not heavily congested, this parameter remains well below the minTxnFee, meaning the base fee requirement still controls the admission threshold. Under normal conditions (no congestion), this value is set to \( 0 \).

\( \delta_{\AD}\)

A consensus parameter that sets a strict deadline for the BlockAssembly process to stop constructing a payset. This ensures block assembly completes within the required time frame.

⚙️ IMPLEMENTATION

In the go-algorand reference implementation, \( \delta_{\AD} = \mathrm{ProposalAssemblyTime} = 0.5 \) seconds.

\( \epsilon_{\AW} \)

An additional time buffer that the BlockAssembly algorithm waits after the official deadline before “giving up”. This grace period allows slightly delayed transactions to be included if possible.

⚙️ IMPLEMENTATION

In the go-algorand reference implementation, \( \epsilon_{\AW} = 150 \) milliseconds.

\( \ExpiredHistory \)

A multiplier that determines how many rounds of historical data on expired transactions are retained. Specifically, the node keeps \( (\ExpiredHistory \times \mathrm{maxTxnLife}) \) rounds of history. Maintaining this history helps dynamically adjust transaction prioritization based on fee structures, as it provides insight into network congestion (e.g., if many transactions are expiring without being included in a block).

⚙️ IMPLEMENTATION

In the go-algorand reference implementation, expiredHistory is set to \( 10 \), therefore, the node keeps \( 10 \times 1000 = 10{,}000 \) rounds of history.

\( \delta_{\NB}\)

A time constant that defines how long the system should wait when processing a new block that appears to be committed to the Ledger. This timeout is used within the Ingestion function to ensure timely handling of new blocks.

⚙️ IMPLEMENTATION

In the go-algorand reference implementation, this limit is set to \( 1 \) second.

Constants

The following two time constants are used to estimate how long it would take to properly complete a block after the system has “given up” on assembling the payset.

These estimates work together with \( \delta_{\AD} \) and \( \epsilon_{\AW} \) to ensure that block finalization occurs within the required timeframe for proposal generation.

• generateBlockBaseDuration, currently set to \( 2 \) milliseconds.

• generateBlockTransactionDuration, currently set to \( 2155 \) nanoseconds.

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \FeePB {\mathrm{feePerByte}} \newcommand \FeeMul {\mathrm{feeThresholdMultiplier}} \newcommand \FeeExp {\mathrm{expFeeFactor}} \newcommand \PendingFB {\mathrm{pendingFullBlocks}} \newcommand \ComputeFeePerByte {\mathrm{ComputeFeePerByte}} $$

Prioritization

When the \( \TP \) becomes congested, a fee prioritization algorithm determines which transactions are enqueued into the pool and which are rejected.

The key parameter in this process is \( \FeePB \), which is calculated dynamically based on the number of pending blocks awaiting evaluation.

The \( \PendingFB \) is an unsigned integer that represents the number of uncommitted full blocks present in the \( \TP_{pq} \).

The function computeFeePerByte below demonstrates how this value is computed:

\( \textbf{Algorithm 2} \text{: Compute Fee per Byte} \)

$$ \begin{aligned} &\text{1: } \PSfunction \ComputeFeePerByte() \\ &\text{2: } \quad \FeePB \gets \FeeMul \\ &\text{3: } \quad \PSif \FeePB = 0 \land \TP.\PendingFB > 1 \PSthen \\ &\text{4: } \quad \quad \FeePB \gets 1 \\ &\text{5: } \quad \PSendif \\ &\text{6: } \quad \PSfor i {\textbf{ from }} 0 \textbf{ to } \TP.\PendingFB \PSdo \\ &\text{7: } \quad \quad \FeePB \gets \FeePB \cdot \TP.\FeeExp \\ &\text{8: } \quad \PSendfor \\ &\text{9: } \quad \PSreturn \FeePB \\ &\text{10: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Compute fee per byte reference implementation.

The computeFeePerByte function begins by setting \( \FeePB \) equal to the \( \FeeMul \). When there is no congestion in \( \TP \), this value is \( 0 \).

However, if there are any full blocks currently pending in \( \TP_{pq} \), \( \FeePB \) is initially set to \( 1 \). This setup ensures that the subsequent multiplication step accumulates due to a non-zero base.

Next, for each of these full pending blocks, the \( \FeeExp \) is multiplied by the current \( \FeePB \) value—causing \( \FeePB \) to grow exponentially with the level of congestion.

The resulting \( \FeePB \) is then:

$$ \FeePB = \max\{1, \FeeMul \} \times \FeeExp^{\TP.\PendingFB} $$

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \NB {\mathrm{newBlock}} \newcommand \SD {\mathrm{stateDelta}} \newcommand \FeeMul {\mathrm{feeThresholdMultiplier}} \newcommand \FeeExp {\mathrm{expFeeFactor}} \newcommand \PendingFB {\mathrm{pendingFullBlocks}} \newcommand \Update {\mathrm{Update}} $$

Update

The Update function is called each time a new block is confirmed.

During this process, the \( \TP \) removes all transactions that have either already been committed or whose lastValid field has expired.

The adjustment of the fee prioritization mechanism depends on how many full blocks are currently pending in the \( \TP_{pq} \) queue.

The state of the \( \TP \) is then updated as follows:

\( \textbf{Algorithm 3} \text{: Update } \TP \)

$$ \begin{aligned} &\text{1: } \PSfunction \Update(\NB\ b, \SD\ sd) \\ &\text{2: } \quad \PSif \TP_{pq} \text{ is empty or outdated} \PSthen \\ &\text{3: } \quad \quad \PSswitch \TP.\PendingFB \\ &\text{4: } \quad \quad \quad \PScase\ 0: \\ &\text{5: } \quad \quad \quad \quad \FeeMul \gets \frac{FeeMul}{FeeExp} \\ &\text{6: } \quad \quad \quad \PScase\ 1: \\ &\text{7: } \quad \quad \quad \quad \PScomment{Intentionally left blank to maintain the value of } \FeeMul \\ &\text{8: } \quad \quad \quad \PScase\ \PSdefault: \\ &\text{9: } \quad \quad \quad \quad \PSif \FeeMul = 0 \PSthen \\ &\text{10:} \quad \quad \quad \quad \quad \FeeMul \gets 1 \\ &\text{11:} \quad \quad \quad \quad \PSelse \\ &\text{12:} \quad \quad \quad \quad \quad \FeeMul \gets \FeeMul \cdot \FeeExp \\ &\text{13:} \quad \quad \quad \quad \PSendif \\ &\text{14:} \quad \quad \PSendswitch \\ &\text{15:} \quad \PSendif \\ &\text{16:} \quad \TP.\mathrm{Prune}(b, sd) \\ &\text{17: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Update on a new block reference implementation.

The algorithm above updates the \( \FeeMul \) based on the current state of the pending queue. Specifically, it checks whether the queue is either empty (no leftover transactions from the previous block assembly) or outdated (i.e., the remaining transactions were grouped into full blocks from a round \( r_p \) such that \( r \geq r_p \), where \( r \) is the current round).

The adjustment logic works as follows:

• If there are \( 0 \) pending full blocks:
  This suggests that any previous congestion has cleared. The \( \FeeMul \) is reduced by dividing it by the \( \FeeExp \). If this low-congestion state continues, the multiplier quickly diminishes and approaches \( 0 \).

• If there is exactly \( 1 \) pending full block:
  The \( \FeeMul \) remains unchanged.

• Otherwise, if there are more than \( 1 \) pending full block (\( \TP.\PendingFB > 1 \)):

  • If the \( \FeeMul \) is currently \( 0 \), it is set to \( 1 \) to reflect a sudden spike in congestion.

  • If it already has a value, it is multiplied by the \( \FeeExp \), causing it to grow in response to continued congestion.

After updating the fee prioritization mechanism, the \( \TP \) is pruned by removing:

• Transactions that were included in the newly committed block \( b \), and

• Transactions whose lastValid field is less than the current round \( r \) (which matches the round of \( b \) that was just observed).

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \TG {\mathrm{TxnGroup}} \newcommand \NB {\mathrm{newBlock}} \newcommand \BlockEval {\mathrm{BlockEvaluator}} \newcommand \Ledger {\mathrm{Ledger}} \newcommand \CheckSufficientFee {\mathrm{CheckSufficientFee}} \newcommand \now {\mathrm{now}} \newcommand \Ingest {\mathrm{Ingest}} $$

Ingestion

This function determines which transaction groups should be passed to the pending Block Evaluator for possible inclusion in the next block, and which ones should be deferred for evaluation in a future round.

When deferring transactions, the node checks that their remaining validity period is sufficient for future inclusion; otherwise, they are marked for removal if they exceed their validity period.

The \( \TP \) also verifies that each transaction group meets the minimum required fee to qualify for execution.

A \( \BlockEval \) is the construct used to ingest \( \TG \).

The following pseudocode snippet illustrates how this ingestion process could be implemented:

\( \textbf{Algorithm 4} \text{: Transaction Ingestion} \)

$$ \begin{aligned} &\text{1: } \PSfunction \Ingest(\TG\ gtx) \\ &\text{2: } \quad \dots \\ &\text{3: } \quad \PSif \lnot \BlockEval \PSthen \\ &\text{4: } \quad \quad \PSreturn \PScomment{No pending Block Evaluator exists} \\ &\text{5: } \quad \PSendif \\ &\text{6: } \quad \PSif \lnot \texttt{recompute} \PSthen \\ &\text{7: } \quad \quad r \gets \Ledger.\mathrm{getLatestRound}() \\ &\text{8: } \quad \quad t^\ast \gets \now() + \delta_{\NB} \\ &\text{9: } \quad \quad \PSwhile \BlockEval.\mathrm{round}() \leq r \land \now() < t^\ast \PSdo \\ &\text{10:} \quad \quad \quad \textsf{Give time to the } \BlockEval \textsf{ to catch up} \\ &\text{11:} \quad \quad \PSendwhile \\ &\text{12:} \quad \quad \PSif \lnot \CheckSufficientFee(gtx) \PSthen \\ &\text{13:} \quad \quad \quad \PSreturn gtx \PScomment{Discarded for insufficient fees} \\ &\text{14:} \quad \quad \PSendif \\ &\text{15:} \quad \PSendif \\ &\text{16:} \quad \TP \gets \BlockEval.\mathrm{add}(gtx) \\ &\text{17:} \quad \dots \\ &\text{18: } \PSendfunction \end{aligned} $$

Transaction ingestion reference implementation.

This algorithm requires a pending \( \BlockEval \) to be already initialized and ready to process transaction groups.

It uses a \( \texttt{recompute} \) flag to verify whether the Update function has handled the latest block. If not, the algorithm enters a wait phase, controlled by the \( \delta_{NB} \) parameter (as described in the parameters section).

This waiting period can end early if the pending \( \BlockEval \) catches up to the current round. Once synchronized, the algorithm performs a preliminary check to ensure that the candidate transaction group \( gtx \) is adequately funded, per the fee prioritization rules.

Finally, an attempt is made to add \( gtx \) to the pending \( \BlockEval \). After evaluating \( gtx \) and performing all necessary checks, this step effectively enqueues the transaction group into the \( \TP \).

$$ \newcommand \PSfunction {\textbf{function }} \newcommand \PSreturn {\textbf{return }} \newcommand \PSendfunction {\textbf{end function}} \newcommand \PSswitch {\textbf{switch }} \newcommand \PScase {\textbf{case }} \newcommand \PSdefault {\textbf{default}} \newcommand \PSendswitch {\textbf{end switch}} \newcommand \PSfor {\textbf{for }} \newcommand \PSendfor {\textbf{end for}} \newcommand \PSwhile {\textbf{while }} \newcommand \PSendwhile {\textbf{end while}} \newcommand \PSdo {\textbf{ do}} \newcommand \PSif {\textbf{if }} \newcommand \PSelseif {\textbf{else if }} \newcommand \PSelse {\textbf{else}} \newcommand \PSthen {\textbf{ then}} \newcommand \PSendif {\textbf{end if}} \newcommand \PSnot {\textbf{not }} \newcommand \PScomment {\qquad \small \textsf} $$

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \AD {\mathrm{assemblyDeadline}} \newcommand \AW {\mathrm{assemblyWait}} \newcommand \AssembleBlock {\mathrm{AssembleBlock}} \newcommand \BlockEval {\mathrm{BlockEvaluator}} \newcommand \EB {\mathrm{emptyBlock}} \newcommand \r {\mathrm{round}} \newcommand \nil {\mathit{nil}} $$

Block Assembly

The \( \TP \) is responsible for populating the payset of a block, a process referred to as BlockAssembly.

The BlockAssembly is a time-bound algorithm that manages the flow of transactions into the pending \( \BlockEval \) and stops ingestion once timing constraints are reached.

It also handles possible desynchronizations between the \( \TP.\r \) (the current round as perceived by the \( \TP \)) and the actual round being assembled by the pending \( \BlockEval \). This discrepancy arises based on how often the Update function has been invoked.

The following pseudocode outlines a high-level view of how BlockAssembly operates:

\( \textbf{Algorithm 5} \text{: Block Assembly} \)

$$ \begin{aligned} &\text{1: } \PSfunction \AssembleBlock(r) \\ &\text{2: } \quad \PSif \TP.\r < r - 2 \PSthen \\ &\text{3: } \quad \quad \PSreturn \AssembleBlock.\EB(r) \\ &\text{4: } \quad \PSendif \\ &\text{5: } \quad \PSif r < \TP.\r \PSthen \\ &\text{6: } \quad \quad \PSreturn \nil \\ &\text{7: } \quad \PSendif \\ &\text{8: } \quad \AD \gets \r.\mathrm{startTime}() + \delta_{\AD} \\ &\text{9: } \quad \text{Wait until } \AD \lor (\TP.\r = r \land \BlockEval \text{ is done}) \\ &\text{10:} \quad \PSif \lnot \BlockEval.\mathrm{done}() \PSthen \\ &\text{11:} \quad \quad \PSif \TP.\r > r \PSthen \\ &\text{12:} \quad \quad \quad \PSreturn \nil \PScomment{r is behind } \TP.\r \\ &\text{13:} \quad \quad \PSendif \\ &\text{14:} \quad \quad \AD \gets \AD + \epsilon_{\AW} \\ &\text{15:} \quad \quad \text{Wait until } \AD \lor (\TP.\r = r \land \BlockEval \text{ is done}) \\ &\text{16:} \quad \quad \PSif \lnot \BlockEval.\mathrm{done}() \PSthen \\ &\text{17:} \quad \quad \quad \PSreturn \AssembleBlock.\EB(r) \PScomment{Ran out of time} \\ &\text{18:} \quad \quad \PSendif \\ &\text{19:} \quad \quad \PSif \TP.\r > r \PSthen \\ &\text{20:} \quad \quad \quad \PSreturn \nil \PScomment{Requested round is behind transaction pool round} \\ &\text{21:} \quad \quad \PSelseif \TP.\r = r - 1 \PSthen \\ &\text{22:} \quad \quad \quad \PSreturn \AssembleBlock.\EB(r) \\ &\text{23:} \quad \quad \PSelseif \TP.\r < r \PSthen \\ &\text{24:} \quad \quad \quad \PSreturn \nil \\ &\text{25:} \quad \quad \PSendif \\ &\text{26:} \quad \PSendif \\ &\text{27:} \quad \PSreturn \BlockEval.\mathrm{block} \\ &\text{28: } \PSendfunction \end{aligned} $$

⚙️ IMPLEMENTATION

Block assembly reference implementation.

This algorithm begins by taking a target round \( r \), for which a new block is to be assembled.

It first checks the round currently perceived by the \( \TP \), which matches the round being handled by the pending \( \BlockEval \).

• If the \( \TP.\r \) is significantly behind \( r \): an empty block is immediately assembled and returned, as there’s no time to catch up.

• If the \( \TP \) is already ahead of \( r \): no action is needed, as \( \TP \) is simply ahead of the network’s current state.

Next, the algorithm waits for the assembly deadline \( \delta_{\AD} \). During this time, the pending \( \BlockEval \) is expected to notify the completed block assembly in the background via the Ingestion function, and that it is caught up to the round \( r \).

If this doesn’t happen by the deadline, the algorithm performs another round of checks:

• If the \( \TP.\r \) is now ahead of \( r \): the process is aborted, waiting for the network to catch up. This should rarely happen.

• Othwewise, if the \( \TP \) is still behind: an additional wait period \( \epsilon_{\AW} \) is introduced.

After this extra wait, similar checks are repeated:

• If the \( \TP \) is still too far behind: there is no more time to wait, and the algorithm exits.

• Otherwise: the algorithm proceeds.

If all checks pass and timing constraints are met without returning early (an empty block or a \( \nil \) value), the pending \( \BlockEval \) finally provides the fully assembled block for round \( r \).

$$ \newcommand \TP {\mathrm{TxPool}} $$

Graphic Run Example

This section is a high-level step-by-step graphic example of a \( \TP \) “vanilla run”, which provides an intuition about the typical operations:

1. Receiving transactions from the Network and prioritizing them,
2. Parallel transactions verification,
3. Enqueuing transactions in the \( \TP \),
4. Serial transaction (FIFO) queue verification and gossip,
5. Re-verification on a new appended block,
6. Block assembly.

Step 1: Reception and Prioritization

Step 2: Parallel Verification

Step 3: Enqueuing

Step 4: Serial Verification and Gossip

Step 5: Verification on New Block

Step 6: Block Assembly

$$ \newcommand \TP {\mathrm{TxPool}} \newcommand \BlockEval {\mathrm{BlockEvaluator}} $$

Block Commitment

Block commitment is the process by which a valid block is added to the Ledger.

⚙️ IMPLEMENTATION

Block commitment entry point in the reference implementation.

To support block commitment, verification, and assembly, the node uses a structure called \( \BlockEval \).

A \( \BlockEval \) can:

• Evaluate transactions in a block body one by one,

• Add transactions to an in-progress payset,

• Track state changes caused by each transaction, and

• Determine if a block is invalid due to a transaction failing validation in the block’s context.

During the block assembly phase, the \( \BlockEval \) can also discard invalid transactions and continue assembling the block with valid ones.

⚙️ IMPLEMENTATION

Block Evaluator reference implementation.

Once a block has been certified, the Ledger is responsible for successfully adding it to the blockchain.

The process of adding a block follows this basic sequence:

sequenceDiagram
    ledger.AddBlock ->> + eval.Eval: Calls Eval with Block and Agreement certificate
    eval.Eval ->> -ledger.AddBlock: State Delta updates
    ledger.AddBlock ->> + ledger.AddValidatedBlock: Adds the validated block with its certificate

Block evaluation takes place after its certificate has been computed. At this point, the Ledger validates the block, applies the resulting State Deltas to its internal state, and adds the block to the blockchain. Once these changes are successfully applied, the block is finalized and officially committed to the Ledger.

flowchart TD
    A[**EnsureBlock**] --> C[ledger.**addBlock**]
    C --> D[Execute **Eval** to process the Block with its **certificate**]
    D --> E[**StartEvaluator**<br>Fetch previous block and protocol params]
    E --> G[Initialize Evaluator and Base State]
    G --> H[Calculate updates for new Block]
    H --> I[Apply updates to Ledger state]
    I --> C
    C --> J[Finalize and commit Block to the Ledger]

The StartEvaluator function sets up and returns a pending \( \BlockEval \), which will handle processing the block and updating the Ledger state. As part of its initialization, the \( \BlockEval \) retrieves the previous block and the relevant protocol parameters to guarantee that the evaluation is consistent with the current blockchain state.

⚙️ IMPLEMENTATION

Start Evaluator reference implementation.

The core interface of a \( \BlockEval \) can be broken down into three primary functions:

• Block Construction:
  This begins by calling StartEvaluator to create a new \( \BlockEval \) instance. It then ingests a sequence of valid transactions from the transaction pool \( \TP_{rq} \), tracking all resulting state changes. The block is finalized at the end of this process with the block proposer setup deferred to this final stage.

• Block Validation:
  This function checks the validity of a given block. Internally, it reuses the same logic as the evaluation process to ensure consistency.

• Block Evaluation:
  This function processes the block to generate a State Delta, which captures all the changes the block makes to the Ledger and its associated Trackers.

⚙️ IMPLEMENTATION

Validate block reference implementation.

$$ \newcommand \TxTail {\mathrm{TxTail}} $$

State Delta

A State Delta represents the changes made to the Ledger’s state from one round to the next.

It is a compact data structure designed to efficiently update all state Trackers after a block is committed. By recording only the parts of the state that were modified, it also simplifies block assembly and validation.

For a formal definition of this structure, refer to the Algorand Ledger normative specification.

⚙️ IMPLEMENTATION

State Delta reference implementation.

In the go-algorand reference implementation, a State Delta includes the following fields:

• AccountStateDeltas:
  A set of Account State Deltas, collecting changes to accounts affected by the block, detailing how their states were modified.

• KVMods:
  A key-value map of modified entries in the Key Value Store, represented as (string → KvValueDelta).

• TxIDs:
  A mapping of new transaction IDs to their LastValid round: (txid → uint). This is used to update the \( \TxTail \) and manage the transaction counter.

• Txleases:
  A mapping (TxLease → uint64) of new transaction leases to their expiration rounds, also relevant to the \( \TxTail \) mechanism.

• Creatables:
  A mapping of data about newly created or deleted “creatable entities” such as Applications and Assets.

• *Hdr:
  A read-only reference to the header of the new block.

• StateProofNext:
  Reflects any update to the StateProofNextRound in the block header. If the block includes a valid State Proof transaction, this is set to the next round for a proof; otherwise, it’s set to \( 0 \).

• PrevTimestamp:
  Stores the timestamp of the previous block as an integer.

• AccountTotals:
  A snapshot of the updated account totals resulting from the changes in this State Delta.

Appendix A

Copy On Write implementation strategy

  ___________________
< cow = Copy On Write >
  -------------------
         \   ^__^
          \  (oo)\_______
             (__)\       )\/\
                 ||----w |
                 ||     ||

Copy-On-Write (COW) is an optimization strategy designed to manage data structure modifications efficiently. The fundamental principle behind COW is to defer the copying of an object until it is actually modified, allowing multiple processes or components to safely share a single instance of the object for as long as it remains unchanged. A separate copy is created only when a write operation occurs, ensuring both memory efficiency and data consistency.

The COW structure is part of the Block Evaluator.

In the go-algorand reference implementation, the roundCowState structure applies the Copy-On-Write (COW) strategy to manage the State Delta. It ensures that state copies are only created when modifications are necessary, enabling efficient memory usage and optimized performance during state transitions across blockchain rounds.

⚙️ IMPLEMENTATION

Copy on write reference implementation.

Algorand Virtual Machine Overview

The Algorand Virtual Machine (AVM) is a bytecode-based Turing-complete stack interpreter that executes programs associated with Algorand transactions.

TEAL is an assembly language syntax for specifying a program that is ultimately converted to AVM bytecode.

The AVM approves or rejects transactions’ effects on the Ledger state.

The Algorand Virtual Machine (AVM) and TEAL

The AVM is a bytecode-based stack interpreter that executes programs associated with Algorand transactions.

The Algorand Transaction Execution Approval Language (TEAL) is an assembly language syntax for specifying a program that is ultimately converted to AVM bytecode.

These programs can be used to check the parameters of the transaction and approve the transaction as if by a signature. This use is called a Logic Signature. Starting with AVM Version 2, these programs may also execute as Smart Contracts, which are often called Applications. Contract executions are invoked with explicit application call transactions.

Logic Signatures have read-only access to the transaction they are attached to, the other transactions in their transaction group, and a few global values. In addition, Applications have access to limited state that is global to the application, per-account local state for each account that has opted-in to the application, and additional per-application arbitrary state in named boxes.

For both types of program, approval is signaled by finishing with the stack containing a single non-zero uint64 value, though return can be used to signal an early approval which approves based only upon the top stack value being a non-zero uint64 value.

The Stack

The AVM Stack is the core structure for the interpreter’s execution. It is constructed and used as a regular stack data structure.

⚙️ IMPLEMENTATION

Stack reference implementation.

On a new AVM program execution, the Stack starts empty. After opcode execution the Stack can contain arbitrary values of either:

• 64-bit unsigned integer type (referred to as uint64), or

• Byte-array type (referred to as bytes or []byte).

Byte-arrays length MUST NOT exceed \( 4096 \) bytes.

A value that may be of either one of these types (not simultaneously) is generically referred to as a StackValue.

Most operations act on the stack, popping arguments from it and pushing results to it. Some operations have immediate arguments encoded directly into the instruction, rather than coming from the Stack.

The maximum Stack depth is \( 1000 \). If the Stack depth is exceeded or if a byte-array element exceeds \( 4096 \) bytes, the program fails.

If an opcode is documented to access a position in the Stack that does not exist, the operation fails.

📎 EXAMPLE

This is often an attempt to access an element below the Stack. A simple example is an operation like concat that expects two arguments on the Stack: if the Stack has fewer than two elements, the operation fails.