---
id: TIP-1119
title: Explicit block system calls
description: Limit automatic block system calls to history storage and committee updates.
authors: DaniPopes, Matthias Seitz (@mattsse)
status: Draft
related: TIP-1016, TIP-1070
protocolVersion: TBD
---

# TIP-1119: Explicit block system calls

## Abstract

This TIP limits Tempo's automatic block system calls to storing parent block hashes
and updating the committee. It disables Ethereum's beacon-root and execution-request
calls.

## Motivation

Tempo inherits Ethereum's system calls and validation through its block executor.
[Alloy-evm #400](https://github.com/alloy-rs/evm/pull/400) rejects Amsterdam blocks
when either builder contract is missing. Tempo should explicitly select its history
and committee calls instead of inheriting Ethereum's selection or checking for code
at each target.

## Assumptions

The history contract accepts the EIP-2935 parent-hash input. The committee call
accepts the epoch and ordered players from the DKG outcome selected by consensus,
as specified by [TIP-1070](./tip-1070.md). Interface changes require corresponding
updates to these rules.

## Threat Model

A proposer or contract deployer cannot enable additional automatic system calls.
Validators apply the same fork rules regardless of code at excluded addresses.
Ordinary transaction calls to those addresses remain subject to normal EVM rules.

---

# Specification

## System calls

At the activation protocol version, replace Ethereum's automatic block system-call
selection with the following rules:

| Call | Timing | Caller | Target | Input |
| --- | --- | --- | --- | --- |
| EIP-2935 history update | Before transactions, except genesis; existing Prague gate applies | `0xfffffffffffffffffffffffffffffffffffffffe` | `0x0000F90827F1C53a10cb7A02335B175320002935` | Parent block hash as 32 raw bytes |
| Current committee update ([TIP-1070](./tip-1070.md)) | After transactions in the last block of an epoch; existing T8 gate applies | `0x0000000000000000000000000000000000000000` | `0xC077E00000000000000000000000000000000000` | ABI-encoded `setCommitteeMembers(uint64 epoch, bytes32[] publicKeys)` from the block's DKG outcome |

The executor commits the state returned by the history call. EVM invocation or
database errors abort block processing. A returned EVM revert or halt does not
invalidate the block. Missing history code produces no update. Tempo initialization
and precompile deployment follow the history call and precede transactions.

The last block of epoch `E` is the block at height `h` where
`h % epoch_length == epoch_length - 1`.

The call runs after incentive-section gas validation. Failure to decode the required
DKG outcome, an EVM invocation error, or a reverted or halted committee call aborts
block processing. On success, the executor commits the returned state.

Transactions in the last block of epoch `E` MUST continue to observe the committee for
epoch `E`; the persisted committee record for epoch `E+1` MUST only become visible to
user EVM execution in the first block of epoch `E+1`.

These calls do not add transactions or receipts and do not consume block gas
capacity.

## Excluded Ethereum processing

The executor MUST NOT schedule the EIP-4788 beacon-root call, EIP-7002 withdrawal
request call, EIP-7251 consolidation request call, or either EIP-8282 builder
request call. It MUST NOT require code at those targets or a beacon root for the
omitted call, regardless of target code or Amsterdam activation.

The executor MUST NOT parse EIP-6110 deposit logs into execution requests. The
execution-request list MUST be empty.

The executor MUST NOT apply Ethereum block or ommer rewards, withdrawal balance
increments, or the DAO transition. Nonempty withdrawals remain invalid.

Receipts retain their order, logs, status, and cumulative gas. Header gas used
remains regular execution gas when [TIP-1016](./tip-1016.md) is enabled and
cumulative transaction gas after refunds otherwise.

## Activation and Compatibility

The rule is fork-gated. Before activation, blocks MUST be processed according to
the existing rules. At and after activation, blocks MUST use the system-call
selection specified above.

# Tooling

N/A. Existing tools use the executor's protocol-version rules.

# Observability

N/A. Block-import errors and state-root comparisons detect execution disagreements.

# Invariants

- Blocks before activation produce the same results under the historical rules.
- History records the parent hash when enabled and deployed; genesis and missing
  code retain their existing behavior.
- State-changing code at every excluded target receives no automatic call, even
  with Amsterdam active. Missing builder code cannot invalidate a block.
- Deposit-shaped logs remain ordinary receipt logs and produce no requests.
- Committee updates preserve epoch-boundary ordering and reject invalid outcomes.
- Initialization, withdrawal rejection, incentive validation, receipts, and both
  gas-accounting modes retain their existing rules.