Learn / Block Execution

This chapter builds on: Ch 12 Pallets & the Runtime, Ch 13 Chain Interactions

Block Execution Timeline

How Substrate processes each block in Subtensor. Understanding this flow helps you know when events fire, when storage updates, and what happens during epochs.

Overview

Roughly every 12 seconds, Subtensor produces a new block . Each block follows a precise execution timeline with four phases. This deterministic order ensures all nodes reach the same state.

on_initialize

Block start, epoch checks

Execute Extrinsics

Process transactions in order

on_finalize

Cleanup, finalize block digest

Block Produced

Seal and propagate to network

Block Time

Subtensor targets 12-second block times. A typical block contains around 0-50 extrinsics , though blocks during high activity can contain more.

1 Phase 1: on_initialize

The first code to run in every block. This is where pallets perform per-block housekeeping before any user transactions are processed.

What Happens

• Aura slot assignment. The block author is determined based on the Aura consensus slot
• Inherent data. Timestamp and other inherent data are set
• Epoch check. For each subnet , checks if (block_number + netuid + 1) % (tempo + 1) == 0

When a subnet's tempo triggers, the epoch processing runs. This is the most computationally intensive part of block execution.

Collect Weights

Gather the weight matrix from all validators , showing who scored whom and how much.

Yuma Consensus

Calculate stake -weighted median of weights. This clips outliers and finds consensus on miner scores.

Compute Incentive & Dividends

Miners get incentive (based on their rank ). Validators get dividends (based on their bonds ).

Distribute Emissions

TAO is minted and distributed to neurons based on their incentive + dividends.

Deep Dive: Epoch Processing Deep Dive: Yuma Consensus Deep Dive: Emission Mechanics

Yuma Math is Compiled Code

The consensus algorithm is compiled Rust code in epoch/run_epoch.rs – not queryable metadata . To understand the math, read the source code.

Storage affected: BlockEmission, LastMechansimStepBlock, Rank, Trust, and more.

2 Phase 2: Execute Extrinsics

User transactions (extrinsics ) are processed in order. Each extrinsic is isolated – one failing doesn't affect others.

Processing Order

• Inherents first. Unsigned transactions from the block author (timestamp, etc.)
• Signed transactions. User-submitted calls in FIFO order
• Transaction pool selection. Block authors include transactions based on priority and fees

Every signed extrinsic goes through 4 stages. Here's the complete lifecycle using add_stake(hotkey, netuid, amount) as an example:

1 Validation , before entering transaction pool

When a transaction is submitted to a node, it's validated before being added to the transaction pool. This happens on the node receiving the transaction, not during block execution.

Checks performed:

Signature. Verifies the coldkey signed this transaction
Nonce. Checks that the transaction nonce matches the account's next expected nonce
Mortality. Ensures the transaction hasn't expired (if mortal)
Fee estimate. Calculates weight and verifies the account can pay fees

If validation fails: Transaction is rejected immediately, never enters pool or block.

2 Pre-dispatch Checks , at start of block execution

When the block author includes this transaction, pre-dispatch checks run before the actual call. These are call-specific validations defined in the pallet.

For add_stake:

Hotkey exists. The target hotkey must be registered on the network
Sufficient balance. Coldkey has at least amount free balance (plus fees)
Minimum stake. Amount meets the minimum stake requirement for the network
Not rate-limited. Coldkey hasn't exceeded stake operations per block

If pre-dispatch fails: Transaction fails with error (e.g., NotEnoughBalanceToStake), fees still charged.

3 Dispatch (Execute) , the actual call logic runs

The call's business logic executes. Storage is modified and events are emitted atomically: if any part fails, all changes are rolled back.

For add_stake:

Storage modified:

Alpha[hotkey][coldkey][netuid] += alpha shares
TotalHotkeyShares[hotkey][coldkey][netuid] += shares
Balances.free[coldkey] -= amount

Events emitted:

StakeAdded
Balances.Withdraw

Atomicity: All storage changes and events happen together – if dispatch fails partway through, everything is rolled back.

4 Post-dispatch , finalize and charge fees

After dispatch completes (success or failure), fees are charged and the outcome is recorded.

On success:

• Fees charged based on actual weight used
• System.ExtrinsicSuccess event emitted
• Nonce incremented
• All storage changes persisted

On failure:

• Fees still charged (for work done)
• System.ExtrinsicFailed event with error
• Nonce still incremented
• All storage changes rolled back

Finding errors: Check System.ExtrinsicFailed event for the error module, index, and message (e.g., SubtensorModule.NotEnoughBalanceToStake).

Summary: add_stake outcomes

Success Path

add_stake

Events: StakeAdded Balances.Withdraw

Storage: Alpha TotalHotkeyShares Balances.free

Failure Path

add_stake

ExtrinsicFailed All storage rolled back, fees still charged

3 Phase 3: on_finalize

After all extrinsics are processed, each pallet's on_finalize hook runs. This is for end-of-block cleanup.

What Happens

• Timestamp finalized. The block's timestamp inherent is locked in
• Block digest updated. Logs, consensus data, and runtime changes are recorded
• Authority rotation queued. If the validator set changes, updates are prepared for the next epoch

Minimal Work

Most pallets generally keep on_finalize lightweight. Heavy computation belongs in on_initialize or hooks to avoid blocking finalization.

4 Phase 4: Block Produced

The block author seals the block with a cryptographic proof and propagates it to the network.

What Happens

• Block hash computed. The header hash uniquely identifies this block
• Block sealed. The author signs the block using Aura consensus
• Network propagation. Block is sent to peers via libp2p gossip
• Finality via GRANDPA . Validators vote to finalize blocks (may lag behind head)

Block Structure

Block #{number}

├── parent_hash: 0x...

├── state_root: 0x...

├── extrinsics_root: 0x...

├── digest: [logs, seal]

└── extrinsics: [inherents, transactions]

Rollback Handling

What happens when a transaction fails? Substrate uses atomic storage changes to maintain consistency.

Atomic Transactions

All or nothing. If any part of a call fails, all storage changes are reverted
Isolated failures. One failed transaction doesn't affect other transactions in the block
Fees still charged. Even if the call fails, transaction fees are deducted

Finding Error Codes

When a call fails, look for System.ExtrinsicFailed event in the block. It contains the error module, index, and message.

Common Failure Scenarios

Scenario	What Happens
Insufficient balance	Call reverted, fee still charged
Invalid parameters	Call reverted, fee still charged
Out of gas/weight	Call reverted, max fee charged
Block weight limit	Transaction stays in pool for next block

Block Execution Timeline

Overview

1 Phase 1: on_initialize

What Happens

2 Phase 2: Execute Extrinsics

Processing Order

3 Phase 3: on_finalize

What Happens

4 Phase 4: Block Produced

What Happens

Block Structure

Rollback Handling

Atomic Transactions

Common Failure Scenarios

Related Resources