Skip to content
Aptos Documentation

Blocks

Aptos versions ledger state per transaction, not per block. After execution, each transaction’s resulting state is stored separately, so clients can read and prove a single version. That differs from chains that persist only the post-block state.

Blocks are still the unit of consensus and proof. Validators agree on an ordered batch of transactions, execute that batch with Block-STM, and persist the results. Storage proofs are at block granularity. How many user transactions land in a block depends on network activity and on-chain limits (gas, output size, and maximum block size).

Block production is not a fixed slot time. Aptos proposes the next block as soon as network delay allows. Mainnet block times are typically tens of milliseconds; check live timestamps on Explorer.

See Aptos Blockchain Deep Dive for the full path from submission to commit.

System transactions

Section titled “System transactions”

A block is more than user transactions. Consensus inserts system transactions that mark the batch and, in some cases, carry protocol data:

  1. BlockMetadataTransaction — first transaction in the block. It records the proposer, timestamp, and round. At an epoch boundary it can also trigger validator-set changes and reward distribution.
  2. ValidatorTransaction — optional protocol payloads from validators, such as JWK updates or randomness (DKG) material. These are not submitted by users.
  3. User transactions — signed transactions from accounts. See Transactions and States.
  4. BlockEpilogueTransaction — last transaction in the block in the common case. It carries BlockEndInfo (whether the block hit gas or output limits, plus approximate usage). Introduced in AIP-88, it replaced StateCheckpointTransaction as the usual end-of-block marker.

The last block of an epoch has no BlockEpilogueTransaction. Indexers and explorers that assumed every block ended with StateCheckpoint must handle block_epilogue_transaction instead.

A typical mainnet block looks like:

BlockMetadataTransaction
[ValidatorTransaction ...]   // optional
[user transactions ...]
BlockEpilogueTransaction     // omitted on the last block of an epoch

Epochs

Section titled “Epochs”

An epoch is a longer interval used to apply validator-set changes, redistribute voting power, and pay staking rewards. Mainnet, testnet, and devnet epochs are two hours (7200 seconds). The number of blocks in an epoch is however many the network produces in that window.

Major configuration changes — for example a validator joining or leaving the set — take effect only at the start of the next epoch. See Staking for the on-epoch triggers.