EIP-7843 Draft EL

SLOTNUM opcode

Authors:

Canonical data: /latest/eips/7843.json

Opcode to get the current slot number

Timeline

Glamsterdam

Marc Harvey-Hill

Scheduled for Inclusion · May 7, 2026 · ACDE #236

May 7, 2026 · ACDE #236

Considered for Inclusion · Dec 4, 2025 · ACDE #225

Dec 4, 2025 · ACDE #225

Proposed

Fusaka

Declined

EIP Created Dec 6, 2024

Key Benefits

● Removes hardcoded slot assumptions; apps remain correct if slot duration changes.
● Cheaper than proving slot via EIP-4788; simple 2-gas opcode call.
● Slot number available directly in block header and engine API.
● No added proving complexity; similar to TIMESTAMP for ZK-VMs.

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

Indirectly benefits from more reliable app timing if slot duration changes in future networks.

Application Developers

Simplifies reading beacon time onchain, avoiding timestamp math and EIP-4788 proofs; fewer assumptions about the slot schedule.

Wallet Developers

Little to no impact; wallets typically don't consume slot numbers. Optional UI or simulation support could display it.

Tooling / Infrastructure

Block explorers, RPC simulators, and debuggers may add opcode support and parse the new header slot_number field.

Layer 2s

Optional support; helpful if mirroring L1 semantics. Not required unless chains want SLOTNUM compatibility and header field parity.

Stakers & Node Operators

No operational changes expected; clients handle computation and propagation. Node operators shouldn't need configuration or workflow updates.

CL Client Developers

Must compute slot_number and include it in headers and engine API payloads; aligns with existing consensus-layer slot calculations.

EL Client Developers

Implement new opcode, validate header field, expose via RPC, and price gas; updates required across execution clients.

North Star Goal Alignment

● Improve UX: Enables more reliable time-based smart contracts and better coordination between consensus and execution layers.

Abstract

This EIP proposes to add a new opcode SLOTNUM (0x4b), that returns the corresponding slot number for the current block.

Motivation

There are currently two ways to get the current slot number onchain:

Calculate from the block timestamp. This requires hardcoding the chain slot length into a smart contract.
Provide the slot number as calldata and prove it against the beacon block root (using EIP-4788).

Both of these approaches have significant drawbacks. (1) would break contracts in the event of a change to the slot length. (2) is expensive in terms of gas, encouraging approach (1) to be used instead.

A better approach is for the slot length to be abstracted away from applications, and instead the slot number can be calculated in the consensus layer client and exposed by an opcode. This paves the way for future changes to the slot length.

Specification

A new opcode SLOTNUM is introduced at 0x4b. It shall return one stack element.

Output

One element slotNumber is added to the stack; it is equal to the corresponding slot number for this block. slotNumber is a uint64 in big endian encoding.

Gas Cost

The gas cost for SLOTNUM is a fixed fee of 2.

RPC changes

The slot number is calculated in the consensus layer and passed to the execution layer through the engine API.

Header extension

The header encoding shall be extended to include a slotNumber field of type uint64.

Engine API changes

New objects ExecutionPayloadV4 and PayloadAttributesV4 are introduced, adding a slotNumber field of type uint64. The methods engine_newPayloadV4, engine_getPayloadV6, and engine_forkChoiceUpdateV4 are added, to use the new objects.

Rationale

Gas Price

The opcode is priced to match similar opcodes in the W_base set.

Calculation in consensus layer

The slot number could alternatively be calculated in the execution layer using the timestamp, but it is more appropriate to calculate values pertaining to the beacon chain in the consensus layer. Additionally this avoids code duplication, as the slot number is already calculated in the consensus layer.

ZK-VM proving

The SLOTNUM opcode should not increase the complexity of proving EVM execution, as it is similar to existing opcodes such as TIMESTAMP. The slot number is included in the block header rather than as a engine_newPayload parameter, ensuring that the block is self-contained for proving; no extra inputs to the circuit are required.

Backwards Compatibility

No backward compatibility issues found.

Test Cases

N/A

Security Considerations

None.