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

Section titled “Algorand Block Structure”

An Algorand block consists of two main parts:

Section titled “Header”

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.
  • Fees Collected: Sum of fees paid by the transactions in the block.
  • Other Fields

Body

Section titled “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.

Algorand Block Fundamentals

Section titled “Algorand Block Fundamentals”

First/Last Valid Rounds

Section titled “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

Section titled “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

Section titled “Throughput”

Algorand is designed for high throughput, supporting thousands of transactions per second (TPS). Block capacity is bounded by size rather than by a fixed transaction count: each block holds up to 5,242,880 bytes (5 MB) of transaction data, set by the MaxTxnBytesPerBlock consensus parameter. How many transactions that works out to depends on their type and size, so the count varies from block to block. Mainnet blocks have carried tens of thousands of transactions during periods of high activity.

Finality and No Forking

Section titled “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

Section titled “Interaction with Blocks”

Algorand Node Endpoints

Section titled “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

Section titled “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 } }
 * }
 */
Source

Smart Contract Access

Section titled “Smart Contract Access”

Smart contracts can read selected header fields from recent blocks directly in the Algorand Virtual Machine (AVM) using the block opcode. The opcode fails unless the target round falls between txn.LastValid-1002 and txn.FirstValid (exclusive). Available fields include the seed, timestamp, proposer, fees collected, the hash of the block’s predecessor, and the block’s transaction commitments in each supported hash function (SHA512_256, SHA256, and SHA512). This allows a smart contract to verify information about a previous block and the transactions it committed to. See the TEAL Opcodes reference for the supported field list and version details.

Block Fields

Section titled “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.
Transaction Sequence Hash (SHA512)A cryptographic commitment, using SHA512 hash function, to the block’s transaction sequence, stored under msgpack key txn512.
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.
Previous Hash (SHA512)The SHA512 hash of the previous block in the sequence. It is stored under msgpack key prev512.
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 have not recently demonstrated that they are available and participating, with exact rules below. The list is stored in msgpack key partupdabs.
State Proof TrackingThe block’s state proof tracking data, which tracks the status of ongoing state proofs for each state proof type. It is stored under msgpack key spt.
LoadThe degree to which the block is full, based on the number of bytes in the block compared to the maximum allowed. It is expressed as a fixed-point integer with six digits of precision, where 1,000,000 means a completely full block. It is stored under msgpack key ld.
Congestion TaxThe fee required, beyond the minimum fee, for normal transactions in this block. It is stored under msgpack key ct.