Algorand Byzantine Fault Tolerance Protocol

Specification

May 19, 2023

Abstract
The Algorand Byzantine Fault Tolerance protocol is an interactive pro-
tocol which produces a sequence of common information between a set of
participants.

Contents
1 Conventions and Notation 2

2 Parameters 2

3 Identity, Authorization, and Authentication 3

4 The Ledger of Entries 4

5 Messages 5
5.1 Elementary Data Types . . . . . . . . . . . . . . . . . . . . . . . 5
5.2 Votes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3 Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5 Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6 State Machine 8
6.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

7 Player State Definition 9

7.1 Special Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

8 Relay Rules 11
8.1 Votes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2 Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.3 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1
9 Internal Transitions 13
9.1 New Round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2 New Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.3 Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.4 New Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

10 Broadcast Rules 14
10.1 Resynchronization Attempt . . . . . . . . . . . . . . . . . . . . . 15
10.2 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.3 Reproposal Payloads . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.4 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.5 Certifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.6 Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.7 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.8 Fast Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1 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
which originated from another player), the protocol will use subscripts to distin-
guish 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 kth player in the protocol, then this address may also be denoted Ik .
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 of 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.

2 Parameters
The protocol is parameterized by the following constants:
• λ, λ0 , λf , Λ are values representing durations of time.

2
 • δs , δr are positive integers (the “seed lookback” and “seed refresh inter-
val”).
For convenience, we define δb (the “balance lookback”) to be 2δs δr .
We define FilterTimeout(p) on period p as follows:
• If p = 0:
– FilterTimeout(p) = 2λ0
• If p ̸= 0:
– FilterTimeout(p) = 2λ
Algorand sets δs = 2, δr = 80, λ = 2 seconds, λ0 = 1.5 seconds, λf = 5 minutes,
and Λ = 17 seconds.

3 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 an opaque object
which is defined in the specification of participation keys in Algorand. Each
participation keypair is valid for a range of rounds (rfirst , rlast ).
Let m, m′ be arbitrary sequences of bits, Bk , B̄ be 64-bit integers representing
balances in microalgos with rewards applied, τ, τ̄ be 32-bit integers, and Q be
a 256-bit string. Let (pkk , skk ) be some valid keypair.
A secret key supports a signing procedure

y := Sign(m, m′ , skk , Bk , B̄, Q, τ, τ̄ )

where y is opaque and are cryptographically resistant to tampering, where de-

fined. 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′ , pkk , Bk , B̄, Q, τ, τ̄ ) = w, where w is a 64-bit
integer called the weight of y. w ̸= 0 if and only if y was produced by
signing by skk (up to cryptographic security). w is uniquely determined
given fixed values of m′ , pkk , Bk , B̄, Q, τ, τ̄ .
• Comparing: Fixing the inputs m′ , B̄, Q, τ, τ̄ to a signing opera-
tion, there exists a total ordering on the outputs y. In other
words, if f (sk, B) = Sign(m, m′ , sk, B, B̄, Q, τ, τ̄ ) = y, and S =
{(sk0 , B0 ), (sk1 , B1 ), . . . , (skn , Bn )}, then {f (x)|x ∈ S} is a totally
ordered set. We write that y1 < y2 if y1 comes before y2 in this ordering.

3
 • Generating Randomness: Let y be a valid output of a signing operation
with skk . Then r = Rand(y, pkk ) is defined to be a pseudorandom 256-
bit integer (up to cryptographic security). r is uniquely determined given
fixed values of m′ , pkk , Bk , B̄, Q, τ, τ̄ .
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(. . .)) always returns
the same value).

4 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.
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 = (e1 , e2 , . . . , en ). 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 er = (or , Qr ), then Seed(L, r) = Qr .
• Record Lookup: Record(L, r, Ik ) = (pkk,r , Bk,r , rfirst , rlast ) for some ad-
dress Ik , some public key pkk,r , and some 64-bit integer Bk,r . rfirst and
rlast define the first valid and last valid rounds for this participating ac-
count.
• Digest Lookup: DigestLookup(L, r) = Digest(er ).
• Total Stake Lookup: We use Krb ,rv to represent all players with partic-
ipation keys at rb that are eligible to vote at rv . Let Krb ,rv be the
set of all k for which (pkk,rb , Bk,rb , rfirst , rlast ) P
= Record(L, rb , Ik ) and
rfirst ≤ rv ≤ rlast holds. Then Stake(L, rb , rv ) = k∈Kr ,r Bk,rb .
b v

A ledger may support an opaque entry generation procedure

o := Entry(L, Q)

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

4
5 Messages
Players communicate with each other by exchanging messages.

5.1 Elementary Data Types

A period p is a 64-bit integer.
A step s is an 8-bit integer. Certain steps are named for clarity. These steps
are defined as follows:
• propose = 0
• soft = 1
• cert = 2
• late = 253
• redo = 254
• down = 255
• next s = s + 3
The following functions are defined on s:
• Committee Size: CommitteeSize(s) is a 64-bit integer defined as follows:


 20 : s = propose
2990 : s = soft




 1500 : s = cert


CommitteeSize(s) = 500 : s = late
2400 : s = redo




6000 : s = down




5000 : otherwise


• Committee Threshold: CommitteeThreshold(s) is a 64-bit integer defined

as follows:


 0 : s = propose
2267 : s = soft




 1112 : s = cert


CommitteeThreshold(s) = 320 : s = late
1768 : s = redo




4560 : s = down




3838 : otherwise


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”), and
Hash is some cryptographic hash function. The special proposal where all fields
are the zero-string is called the bottom proposal ⊥.

5.2 Votes
Let I be an address, r be a round, p be a period, s be a step, and v be a
proposal-value, let x be a canonical encoding of the 5-tuple (I, r, p, s, v), and

5
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).
Moreover, let L be a ledger where |L| ≥ δb . Let (sk, pk) be a keypair, B, B̄ be
64-bit integers, Q be a 256-bit integer, and τ, τ̄ 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:
• r ≤ |L| + 2
• Let v = (Iorig , porig , d, h). If s = 0, then porig ≤ p. Furthermore, if s = 0
and p = porig , then I = Iorig .
• If s ∈ {propose, soft, cert, late, redo}, v ̸= ⊥. Conversely, if s = down,
v = ⊥.
• Let (pk, B, rfirst , rlast ) = Record(L, r − δb , I), B̄ = Stake(L, r − δb , r), Q =
Seed(L, r − δs ), τ = CommitteeThreshold(s), and τ̄ = CommitteeSize(s).
Then Verify(y, x, x′ , pk, B, B̄, Q, τ, τ̄ ) ̸= 0 and rfirst ≤ r ≤ rlast .
Observe that valid votes contain outputs of the Sign procedure; i.e., y :=
Sign(x, x′ , sk, B, B̄, Q, τ, τ̄ ).
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 pe-
riod (porig = p) or claim to “re-propose” a value originally proposed in an
earlier period (porig < p). But they can’t claim to “re-propose” a value
from a future period. And if the proposal-value is new (porig = p) then
the “original proposer” must be the voter.
• The propose, soft, cert, late, and redo steps must vote for an actual pro-
posal. The down step must only vote for ⊥.
• 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,
where the committee selection process uses the voter’s stake and keys as
of δb 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 which differ in their proposal values. In other words,

Equivocation(I, r, p, s) = (Vote(I, r, p, s, v1 ),
Vote(I, r, p, s, v2 ))

6
for some v1 ̸= v2 .
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.

5.3 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).
Moreover, let L be a ledger where |L| ≥ δ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:
• Every element ai ∈ V is valid with respect to L.
• For any two elements ai , aj ∈ V , Ii ̸= Ij .
• For any element ai ∈ V , ri = r, pi = p, si = s.
• For any element ai ∈ V , either ai is a vote and vi = v, or ai is an
equivocation vote.
P
• Let wi be the weight of the signature in ai . Then i wi ≥
CommitteeThreshold(s).

5.4 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 |L| ≥ δb , and let 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, rfirst , rlast ) = Record(L, r − δb , I). If p = 0, then
Verify(y, Q0 , Q0 , pk, 0, 0, 0, 0, 0) ̸= 0.
• Let (pk, B, rfirst , rlast ) = Record(L, r − δb , I). Then rfirst ≤ r ≤ rlast .
If e matches v, we write e = Proposal(v).

7
5.5 Seed
Informally, the protocol interleaves δs seeds in an alternating sequence. Each
seed is derived from a seed δs rounds in the past through either a hash function
or through a VRF, keyed on the entry proposer. Additionally, every δs δr rounds,
the digest of a previous entry (specifically, from round r − δs δ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, rfirst , rlast ) = Record(L, r − δb , I) and sk be the secret key corresponding
to pk. Let α 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 − δs ), sk)
– α = Hash(VRF.ProofToHash(y), I)
• If p ̸= 0:
– y=0
– α = Hash(Seed(L, r − δs ))
Now I computes the seed Q as follows:

H(α, DigestLookup(L, r − δs δr )) : (r mod δs δr ) < δs
Q=
H(α) : otherwise

The seed is valid if the following verification procedure succeeds:

1. Let (pk, B, rfirst , rlast ) = Record(L, r − δb , I); let q0 = Seed(L, r − δs ).
2. If p = 0, check VRF.Verify(y, q0 , pk), immediately returning failure if
verification fails. Let q1 = Hash(VRF.ProofToHash(y), I) and continue to
step 4.
3. If p ̸= 0, let q1 = Hash(q0 ). Continue.
4. If r ≡ (r mod δs ) mod δr δs , then check Q = Hash(q1 , DigestLookup(L, r−
δs δr )). Otherwise, check Q = q1 .
Note: Round r leader selection and committee selection both use the seed from
r − δs and the balances / public keys from r − δb .
Note: For reproposals, the period p used in this section is the original period,
not the reproposal period.

6 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.

8
We can define the operation of the state machine as transitions between different
states. A transition N maps some initial state S0 , a ledger L0 , and an event e
to an output state S1 , an output ledger L1 , and a sequence of output network
transmissions a = (a1 , a2 , . . . , an ). We write this as

N (S0 , L0 , e) = (S1 , L1 , a).

If no transmissions are output, we write that a = ϵ.

6.1 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 λ seconds
after period p begins is denoted t(λ, p).

6.2 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∗ (r, p, s, v).

7 Player State Definition

We define the player state S to be the following tuple:

S = (r, p, s, s̄, V, P, v̄)

where
• r is the current round,
• p is the current period,
• s is the current step,
• s̄ is the last concluding step,
• V is the set of all votes,
• P is the set of all proposals, and
• v̄ is the pinned value.

9
We say that a player has observed
• Proposal(v) if Proposal(v) ∈ P
• Votel (r, p, s, v) if Votel (r, p, s, v) ∈ V
• Bundle(r, p, s, v) if Bundlel (r, p, s, v) ⊂ V
• that round r (period 0) has begun if there exists some p such that
Bundle(r − 1, p, cert, v) was also observed
• that 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, s̄, V, P, v̄), L0 , Vote) = ((r′ , p′ , . . . , V ∪ {Vote}, P, v̄ ′ ), L1 , . . .).

We abbreviate the transition above as

N ((r, p, s, s̄, V, P, v̄), L0 , Vote) = ((S ∪ Vote, P, v̄), L1 , . . .).

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.

7.1 Special Values

We define two functions µ(S, r, p), σ(S, r, p), which are defined as follows:
µ(S, r, p) is defined as the proposal-value in the vote in round r and period p
with the minimal credential. More formally, let

Vr,p = {Vote(I, r, p, 0, v)|Vote ∈ V }

where V is the set of votes in S. Then if Votel (r, p, 0, vl ) is the vote with the
smallest weight in Vr,p , then µ(S, r, p) = vl .
If Vr,p is empty, then µ(S, r, p) = ⊥.
σ(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) ⊂ V . Then
σ(S, r, p) = v.
If no such soft-bundle exists, then σ(S, r, p) = ⊥.
If there exists a proposal-value v such that Proposal(v) ∈ V and σ(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).

10
8 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 pro-
ducing 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 peer which indicates that the peer is
misbehaving. These cases are marked with an asterisk (*) and enable the node
to perform a special action (e.g., disconnect from the peer).
We say that a player ignores a message if it produces no outputs on receiving
that message.

8.1 Votes
On receiving a vote V otek (rk , pk , sk , v) a player
• Ignores* it if Votek is invalid.
• Ignores it if s = 0 and Votek ∈ V .
• Ignores it if s = 0 and Votek is an equivocation.
• Ignores it if s > 0 and Votek is a second equivocation.
• Ignores it if
– rk ∈/ [r, r + 1] or
– rk = r + 1 and either
∗ pk > 0 or
∗ sk ∈ (next 0 , late) or
– rk = r and one of
∗ pk ∈ / [p − 1, p + 1] or
∗ pk = p + 1 and sk ∈ (next 0 , late) or
∗ pk = p and sk ∈ (next 0 , late) and sk ∈
/ [s − 1, s + 1] or
∗ pk = p − 1 and sk ∈ (next 0 , late) and sk ∈/ [s̄ − 1, s̄ + 1].
• Otherwise, relays Votek , observes it, and then produces any consequent
output.
Specifically, if a player ignores the vote,

N (S, L, Votek (rk , pk , sk , v)) = (S, L, ϵ)

while if a player relays the vote,

N (S, L, Votek (rk , pk , sk , v)) = (S ′ ∪Vote(I, rk , pk , sk , v), L′ , (Vote∗k (rk , pk , sk , v), . . .)).

8.2 Bundles
On receiving a bundle Bundle(rk , pk , sk , v) a player
• Ignores* it if Bundle(r, p, s, v) is invalid.

11
 • Ignores it if
– rk ̸= r or
– rk = r and pk + 1 < p.
• Otherwise, observes the votes in Bundle(rk , pk , sk , v) in sequence.
If there exists a vote which causes the player to observe some
bundle Bundle(rk , pk , sk , v ′ ) for some sk , then the player relays
Bundle(rk , pk , sk , 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,

N (S, L, Bundle(rk , pk , sk , v)) = (S, L, ϵ);

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

N (S, L, Bundle(rk , pk , sk , v)) = (S ′ ∪ Bundle(rk , pk , sk , v), L, ϵ);

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),

N (S, L, Bundle(rk , pk , sk , v)) = (S ′ ∪Bundle(rk , pk , sk , v), L′ , (Bundle∗ (r, pk , sk , v ′ ), . . .)).

8.3 Proposals
On receiving a proposal Proposal(v) a player
• Relays Proposal(v) if σ(S, r + 1, 0) = v.
• Ignores it if it is invalid.
• Ignores it if Proposal(v) ∈ P .
• Relays Proposal(v), observes it, and then produces any consequent output,
if v ∈ {σ(S, r, p), v̄, µ(S, r, p)}.
• Otherwise, ignores it.
Specifically, if the player ignores a proposal,

N (S, L, Proposal(v)) = (S, L, ϵ)

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

N (S, L, Proposal(v)) = (S ′ ∪ Proposal(v), L′ , (Proposal∗ (v), . . .)).

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∗ (v))).

Note: An implementation may buffer a proposal in this case. Specifically, an

implementation which relays a proposal without checking that it is valid may

12
optionally choose to replay this event when it observes that a new round has
begun (see below). In this case, on 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 are always required to relay pro-
posals which match the following proposal-values (where r is the current round
and p is the current period):
• v̄
• σ(S, r, p), σ(S, r, p − 1)
• µ(S, r, p) if σ(S, r, p) is not set and µ(S, r, p + 1) if σ(S, r, p + 1) is not set

9 Internal Transitions
After receiving message events, the player updates some components of its state.

9.1 New Round

When a player observes that a new round (r, 0) has begun, the player sets
s̄ := s, v̄ := ⊥, p := 0, s := 0. Specifically, if a new round has begun,

N ((r − i, p, s, s̄, V, P, v̄), L, . . .) = ((r, 0, 0, s, V ′ , P ′ , ⊥), L′ , . . .)

for some i > 0.

9.2 New Period

When a player observes that a new period (r, p) has begun, the player sets
s̄ := s, s := 0. Also, the player sets v̄ := v if the player has observed Bundle(r, p−
1, s, v) given some values s > cert (or s = soft), v ̸= ⊥; if none exist, the player
sets v̄ := σ(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
v̄.
In other words, if Bundle(r, p−1, s, v) ∈ V ′ for some v ̸= ⊥, s > cert or s = soft,

N ((r, p − i, s, s̄, V, P, v̄), L, . . .) = ((r, p, 0, s, V ′ , P, v), L′ , . . .);

and otherwise, if Bundle(r, p − 1, s, ⊥) ∈ V ′ for some s > cert with σ(S, r, p − i)

defined,

N ((r, p − i, s, s̄, V, P, v̄), L, . . .) = ((r, p, 0, s, V ′ , P, σ(S, r, p − i)), L′ , . . .);

and otherwise

N ((r, p − i, s, s̄, V, P, v̄), L, . . .) = ((r, p, 0, s, V ′ , P, v̄), L′ , . . .);

for some i > 0 (where S = (r, p − i, s, s̄, V, P, v̄)).

13
9.3 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, s̄, V, P, v̄), L, . . .) = ((r, p, s̄, 0, V ′ \ Vr,p

∗
, P ′ \ Pr,p
∗
, v̄), L, . . .).

where
∗
Vr,p = {Vote(I, r′ , p′ , s̄, v)|Vote ∈ V, r′ < r}
∪ {Vote(I, r′ , p′ , s̄, v)|Vote ∈ V, r′ = r, p′ + 1 < p}
∗
and Pr,p is defined similarly.

9.4 New Step

A player may also update its step after receiving a timeout event.
On observing a timeout event of FilterTimeout(p) for period p, the player sets
s := cert.
On observing a timeout event of max{4λ, Λ}, the player sets s := next 0 .
On observing a timeout event of max{4λ, Λ} + 2st λ + r where r ∈ [0, 2st λ]
sampled uniformly at random, the player sets s := st .
In other words,

N ((r, p, s, s̄, V, P, v̄), L, t(FilterTimeout(p), p)) = ((r, p, cert, s̄, V, P, v̄), L′ , . . .)

N ((r, p, s, s̄, V, P, v̄), L, t(max{4λ, Λ}, p)) = ((r, p, next 0 , s̄, V, P, v̄), L′ , . . .)
N ((r, p, s, s̄, V, P, v̄), L, t(max{4λ, Λ} + 2st λ + r, p)) = ((r, p, st , s̄, V, P, v̄), L′ , . . .).

10 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, rfirst , rlast ) = Record(L, r − δb , I), B̄ = Stake(L, r − δb ), Q =
Seed(L, r − δs ), τ = CommitteeThreshold(s), τ̄ = CommitteeSize(s).
• Encode x := (I, r, p, s, v), x′ := (I, r, p, s).
• Try to set y := Sign(x, x′ , sk, B, B̄, Q, τ, τ̄ ).
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.

14
For certain broadcast vote-messages specified here, a node is forbidden to equiv-
ocate (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.

10.1 Resynchronization Attempt

Where specified, a player attempts to resynchronize. A resynchronization at-
tempt involves the following:
• 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) ⊂ V for some v, if it exists, or else
– Bundle(r, p − 1, s, ⊥) ⊂ V for some s > cert, if it exists, or else
– Bundle(r, p − 1, s, v) ⊂ V for some s > cert, v ̸= ⊥, if it exists.
• Second, if the player broadcasted a bundle Bundle(r, p, s, v), and v ̸= ⊥,
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, . . .) = (S ′ , L′ , . . .),

corresponds to a broadcast of a bundle after a relay output and before any sub-
sequent broadcast outputs, if a freshest bundle exists but no matching proposal
exists
N (S, L, . . .) = (S ′ , L′ , (. . . , Bundle∗ (r, p, soft, v), . . .)),
and otherwise corresponds to a broadcast of both a bundle and a proposal after
a relay output and before any subsequent broadcast outputs

N (S, L, . . .) = (S ′ , L′ , (. . . , Bundle∗ (r, p, soft, v), Proposal(v), . . .)).

10.2 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, ⊥) 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 s0 > cert, v where Bundle(r, p − 1, s0 , v)
was observed, while there exists no s1 > cert where Bundle(r, p − 1, s1 , ⊥)
was observed, then the player broadcasts Vote(I, r, p, 0, v). Moreover, if
Proposal(v) ∈ P , the player then broadcasts Proposal(v).

15
A player generates a new proposal by executing the entry-generation proce-
dure 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 and
s := Hash(Seed(L, r − 1)) otherwise. This consequently defines the matching
proposal-value v = (I, p, Digest(e), Hash(Encoding(e))).
In other words, if the player generates a new proposal,

N (S, L, . . .) = (S ′ , L′ , (. . . , Vote(I, r, p, 0, v ′ ), Proposal(v ′ ))),

while if the player broadcasts an old proposal,

N (S, L, . . .) = (S ′ , L′ , (. . . , Vote(I, r, p − 1, 0, v), Proposal(v)))

if Proposal(v) ∈ P and

N (S, L, . . .) = (S ′ , L′ , (. . . , Vote(I, r, p − 1, 0, v)))

otherwise.

10.3 Reproposal Payloads

On observing Vote(I, r, p, 0, v), if Proposal(v) ∈ P then the player broadcasts
Proposal(v).
In other words, if Proposal(v) ∈ P ,

N (S, L, Vote(I, r, p, 0, v)) = (S ′ , L′ , (Proposal(v))).

10.4 Filtering
On observing a timeout event of FilterTimeout(p) (where µ = (H, H ′ , l, pµ ) =
µ(S, r, p)),
• if µ ̸= ⊥ and if
– pµ = p or
– there exists some s > cert such that Bundle(r, p − 1, s, µ) was ob-
served. then the player broadcasts Vote(I, r, p, soft, µ).
• if there exists some s0 > cert such that Bundle(r, p − 1, s0 , v̄) was observed
and there exists no s1 > cert such that Bundle(r, p−1, s1 , ⊥) was observed,
then the player broadcasts* Vote(I, r, p, soft, v̄).
• otherwise, the player does nothing.
In other words, in the first case above,

N (S, L, t(FilterTimeout(p), p)) = (S, L, Vote(I, r, p, soft, µ));

16
while in the second case above,

N (S, L, t(FilterTimeout(p), p)) = (S, L, Vote(I, r, p, soft, v̄));

and if neither case is true,

N (S, L, t(FilterTimeout(p), p)) = (S, L, ϵ).

10.5 Certifying
On observing that some proposal-value v is committable for its current round
r, and some period p′ ≥ p (its current period), if s ≤ cert, then 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.)
In other words, if observing a soft-vote causes a proposal-value to become com-
mittable,

N (S, L, Vote(I, r, p, soft, v)) = (S ′ , L, (. . . , 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, (. . . , 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, (. . . , Vote(I, r, p, cert, v)));

as long as s ≤ cert.

10.6 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.)
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, . . .));

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

N (S, L, Bundle(r, p, cert, v)) = (S ′ , L||e, . . .)).

Note: Occasionally, an implementation may not have e at the point e becomes

committed. In this case, the implementation may wait until it receives e some-
how (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 ̸= ⊥ until
it has committed e.

17
10.7 Recovery
On observing a timeout event of
• T = max{4λ, Λ} or
• T = max{4λ, Λ} + 2st λ + r where r ∈ [0, 2st λ] sampled uniformly at
random,
the player attempts to resynchronize and then broadcasts* Vote(I, r, p, next s , v)
where
• v = σ(S, r, p) if v is committable in (r, p),
• v = v̄ if there does not exist a s0 > cert such that Bundle(r, p − 1, s0 , ⊥)
was observed and there exists an s1 > cert such that Bundle(r, p − 1, s1 , v̄)
was observed,
• and v = ⊥ otherwise.
In other words, if a proposal-value v is committable in the current period,

N (S, L, t(T, p)) = (S ′ , L, (. . . , Vote(I, r, p, next s , v)));

while in the second case,

N (S, L, t(T, p)) = (S ′ , L, (. . . , Vote(I, r, p, next s , v̄)));

and otherwise,

N (S, L, t(T, p)) = (S ′ , L, (. . . , Vote(I, r, p, next s , ⊥))).

10.8 Fast Recovery

On observing a timeout event of T = kλf + r where k is a positive integer and
r ∈ [0, λf ] sampled uniformly at random, the player attempts to resynchronize.
Then,
• The player broadcasts* Vote(I, r, p, late, v) if v = σ(S, r, p) is committable
in (r, p).
• The player broadcasts* Vote(I, r, p, redo, v̄) if there does not exist a s0 >
cert such that Bundle(r, p − 1, s0 , ⊥) was observed and there exists an
s1 > cert such that Bundle(r, p − 1, s1 , v̄) was observed.
• Otherwise, the player broadcasts* Vote(I, r, p, down, ⊥).
Finally, the player broadcasts all Vote(I, r, p, late, v) ∈ V , all Vote(I, r, p, redo, v) ∈
V , and all Vote(I, r, p, down, ⊥) ∈ V that it has observed.

18