> Feedback: If these docs are stale, missing, or confusing, post sanitized feedback to `https://docs.tempo.xyz/api/feedback` with `source: "mcp"`, a short `message`, and any relevant `toolName`, `relatedResource`, or `client`.
# Blockspace Overview

## Abstract

This specification defines the structure of valid blocks in the Tempo blockchain.

## Motivation

Tempo blocks extend the Ethereum block format in multiple ways: there are new header fields to account for payment lanes and shared gas accounting, and system transactions are added to the block body for the fee AMM and other protocol operations. This specification contains all the modifications to the block format.

## Specification

### Header fields

Tempo extends an Ethereum header with three extra scalars.

```rust title="Header struct"
pub struct Header {
    pub general_gas_limit: u64,
    pub shared_gas_limit: u64,
    pub timestamp_millis_part: u64,
    pub inner: Header,
}
```

* `inner` is the canonical Ethereum header (parent\_hash, state\_root, gas\_limit, etc.).
* `general_gas_limit` and `shared_gas_limit` partition the canonical `gas_limit` for payment and non-payment capacity (see [payment lane specification](/docs/protocol/blockspace/payment-lane-specification)).
* `timestamp_millis_part` stores the sub‑second component; the full timestamp is `inner.timestamp * 1000 + timestamp_millis_part` .

### Block body

The block body in Tempo retains the canonical Ethereum block body structure, with the addition of system transactions. Transactions are ordered in the following sections:

1. Start-of-block system transaction(s) (must begin with the rewards registry call).
2. Proposer lane transactions, subject to `general_gas_limit` on non-payment transactions.
3. Remaining transactions that consume the shared gas budget.
4. Protocol-defined end-of-block system transactions, when required.

### System transactions

A valid tempo block must contain the following system transaction:

* **Rewards Registry (start-of-block)** — must be the first transaction in the block body; refreshes validator rewards metadata before user transactions begin.  Detailed specification [here](/docs/protocol/tip20-rewards/spec).