Skip to content
light theme Algorand Developer Portal dark theme Algorand Developer Portal Algorand Developer Portal

Blocks

Blocks are the fundamental data structures of the Algorand blockchain, representing a batch of transactions that transitions the ledger state from one round to the next. They include essential metadata, like round number and timestamps, and the actual transactions data. Blocks are added through Algorand’s Pure Proof of Stake consensus protocol.

Algorand Block Structure

An Algorand block consists of two main parts:

The block header contains high-level metadata about the block:

  • Round: The block’s height or index in the chain.
  • Timestamp: The Unix epoch time (in seconds) of block creation.
  • Proposer: The account chosen (via VRF) to propose the block.
  • Previous Block Hash: Reference linking this block to its predecessor.
  • Genesis ID / Hash: Identifiers anchoring the chain back to its genesis block.
  • Other Fields

Body

The block body contains the transaction sequence that updates both the account state and box state. It includes:

  • Transactions: All transactions in this round, such as payments, asset transfers, and application calls. This includes any inner transactions that applications generate.
  • Fees Collected: Sum of fees for the transactions included.

Algorand Block Fundamentals

First/Last Valid Rounds

Unlike Ethereum which uses nonces to prevent transaction replay, Algorand uses a validity window specified by first and last valid rounds. This window determines between which blockchain rounds a transaction can be committed to the blockchain. Additionally, Algorand prevents transaction replay by rejecting identical transactions - two identical transactions cannot be committed to the blockchain. For further transaction control, optional leases can also be used.

The validity window consists of:

  • First Valid: The earliest round in which the transaction can be included.
  • Last Valid: The final round after which the transaction is no longer valid.

The validity window has a maximum span of 1,000 rounds. Since Algorand produces blocks every 2.82 seconds, this gives transactions approximately one hour to be included in the blockchain.

By carefully selecting these rounds, developers can manage timing or ensure the transaction expires if not promptly processed.

Average Block Time

Algorand confirms blocks every 2.82 seconds on average. This means transactions are finalized within this timeframe, whether submitted by users or dApps. When designing applications, developers should consider how this block production timing impacts user experience and round-based logic.

Throughput

Algorand is designed for high throughput, supporting thousands of transactions per second (TPS). Each block can hold up to 25,000 transactions, which ensures the network can scale to meet growing demand without sacrificing security or decentralization.

Finality and No Forking

Unlike other blockchains that require multiple confirmations or risk chain reorganizations called “forks”, Algorand achieves instant finality at the block level. Once a block is certified via soft vote and certify vote, its transactions are final and cannot be reversed.

Interaction with Blocks

Algorand Node Endpoints

To retrieve block data programmatically, Algorand provides several REST API endpoints through its node software. These endpoints allow developers to fetch complete blocks, just headers, or even cryptographic hashes for specific rounds. They are essential for inspecting block-level data or verifying state transitions in on-chain applications.

Terminal window
GET /v2/blocks/{round}: Retrieve a complete block (header + transactions).
GET /v2/blocks/{round}/header: Fetch just the block header.
GET /v2/blocks/{round}/hash: Obtain the cryptographic hash of a given block.

These REST endpoints typically require an API token (X-Algo-API-Token header).

Algorand Python and Typescript

Developers can also interact with blocks and transaction data using Algokit Utils in Python and TypeScript.

Algokit Utils offer abstractions to retrieve block details, inspect transaction content and inspect the whole block data. Below are code examples demonstrating how to do this:

  /**
   * Gets the block info for the given round.
   *
   * @param roundNumber - The round number of the block to get.
   * @category GET
   */
  const block = await algorand.client.algod.block(1).do()


  console.log(block)
  /**
   * BlockResponse {
   *  block: Block {
   *    header: BlockHeader {
   *      round: 1n,
   *      branch: [Uint8Array],
   *      seed: [Uint8Array],
   *      txnCommitments: [TxnCommitments],
   *      timestamp: 1742832892n,
   *      genesisID: 'dockernet-v1',
   *      genesisHash: [Uint8Array],
   *      proposer: [Address],
   *      feesCollected: 1000n,
   *      bonus: 10000000n,
   *      proposerPayout: 0n,
   *      rewardState: [RewardState],
   *      upgradeState: [UpgradeState],
   *      upgradeVote: [UpgradeVote],
   *      txnCounter: 1001n,
   *      stateproofTracking: [Map],
   *      participationUpdates: [ParticipationUpdates]
   *    },
   *    payset: [ [SignedTxnInBlock] ]
   *  },
   *  cert: UntypedValue { data: Map(1) { 'rnd' => 1n } }
   * }
   */

Block Fields

FieldDescription
RoundThe 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 and Genesis HashThe block’s genesis identifier and hash, which match the genesis identifier and hash of the states it transitions between. The genesis identifier is stored under msgpack key gen, and the genesis hash is stored under msgpack key gh.
Upgrade VoteThe 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 representation of the components of the upgrade vote are described in detail below.
TimestampThe block’s timestamp, which matches the timestamp of the state it transitions into. The timestamp is stored under msgpack key ts.
SeedThe block’s seed, which matches the seed of the state it transitions into. The seed is stored under msgpack key seed.
Reward UpdatesThe 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 representation of the components of the reward updates are described in detail below.
Transaction SequenceA cryptographic commitment to the block’s transaction sequence, described below, stored under msgpack key txn.
Transaction Sequence HashA cryptographic commitment, using SHA256 hash function, to the block’s transaction sequence, described below, stored under msgpack key txn256.
Previous HashThe block’s previous hash, which is the cryptographic hash of the previous block in the sequence. (The previous hash of the genesis block is 0.) The previous hash is stored under msgpack key prev.
Transaction CounterThe 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 supported the transaction counter. The counter is stored in msgpack field tc.
ProposerThe block’s proposer, which is the address of the account that proposed the block. The proposer is stored in msgpack field prp.
Fees CollectedThe block’s fees collected is the sum of all fees paid by transactions in the block and is stored in msgpack field fc.
Bonus IncentiveThe potential bonus incentive is the amount, in MicroAlgos, 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 modulo 1,000,000.
Proposer PayoutThe 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 100,000 microAlgos.
Expired Participation AccountsThe 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 AccountsThe block’s suspended participation accounts, which contains an optional list of account addresses. These accounts are have not recently demonstrated that they available and participating, with exact rules below. The list is stored in msgpack key partupdabs.