## Keyboard shortcuts Press `←` or `→` to navigate between chapters Press `S` or `/` to search in the book Press `?` to show this help Press `Esc` to hide this help - Auto - Light - Dark # Algorand Specifications 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: 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. > Important > **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). Cryptographic commitment (hash) of the previous block header, linking blocks into a chain. The _genesis block_ has this field set to 00. A 64-bit unsigned integer value that identifies the block’s _round_. The _genesis_ _block_ has round 00. 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). 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](https://specs.algorand.co/abft/abft-messages-seed)) defines implicitly a sequence of seeds, whose values alternate according to: - The seed lookup constant δsδs, - Some round-specific computation that depends, amongst other things, on the seed refresh interval δrδr, the period pp during which the block was assembled, and on the VRFVRF value obtained by the block proposer. > Important > **EXAMPLE:** > Example a valid [seed chain computation](https://specs.algorand.co/abft/non-normative/abft-nn-seed-calculation#example). A 64-bit unsigned integer. The timestamp is purely informational and states when a block was proposed, expressed in seconds since [UNIX Epoch](https://en.wikipedia.org/wiki/Unix_time) (00:00:00 Thursday, 1 January 1970, at UTC). The difference between consecutive timestamps cannot be greater than tδ=25tδ=25 seconds > See the formal definition in the Ledger [normative specification](https://specs.algorand.co/ledger/ledger-parameters). > Important > **EXAMPLE:** > In the reference implementation, checks on the timestamp are performed during block assembly. See the [`MakeBlock`](https://github.com/algorand/go-algorand/blob/b6e5bcadf0ad3861d4805c51cbf3f695c38a93b7/data/bookkeeping/block.go#L543) function. > Consensus protocol does not guarantee the accuracy of the timestamp! Cryptographic commitments (hash) to the block’s transaction sequence. Internally, it uses a [Merkle Tree](https://specs.algorand.co/crypto/crypto-merkle-tree) and commits to the tree’s root. Two different hashes are provided: - [SHA512/256](https://specs.algorand.co/crypto/crypto-sha512-256), - [SHA256](https://specs.algorand.co/crypto/crypto-sha256). > Important > **IMPLEMENTATION:** > Transactions (`payset`) commit [reference implementation](https://github.com/algorand/go-algorand/blob/b6e5bcadf0ad3861d4805c51cbf3f695c38a93b7/data/bookkeeping/block.go#L591). 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](https://specs.algorand.co/ledger/non-normative/ledger-nn-staking-rewards). - `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. Address of the account that proposed this block. 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. > Important > **EXAMPLE:** > MainNet `FeeSink` address: `Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA`. > This legacy rewards distribution mechanism is currently inactive. See the [non-normative\ > section](https://specs.algorand.co/ledger/non-normative/ledger-nn-protocol-rewards) 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). > Important > **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 00 for every block). - `RewardsResidue` ( **legacy**) A 64-bit unsigned integer holding the leftover amount of μALGO after the distribution of RewardsRateRewardUnitsRewardsRateRewardUnits for every reward unit in the next round. - `RewardsRecalculationRound` ( **legacy**) A 64-bit unsigned integer holding the round at which the RewardsRateRewardsRate will be recalculated. A 64-bit unsigned integer counting transactions committed before this block. It is initialized at 00 or 10001000 in the _genesis block_, depending on the `AppForbidLowResources` consensus parameter. 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](https://github.com/algorandfoundation/specs) of the currently active protocol version. - `NextProtocol` A link to the commit in the [Algorand Formal Specification repository](https://github.com/algorandfoundation/specs) 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. 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 00 unless an upgrade vote is ongoing. 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 3232 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 3232 accounts.