# SLOTDURATION proposal would expose Ethereum slot duration to smart contracts

Canonical: https://forkbrief.com/news/83597f19-0396-4358-bf5b-b07f74bb132e
Published: 2026-11-04T18:39:17.819Z
Publisher: Fork Brief

An open, unnumbered Core draft proposes a duration opcode and Engine API changes, while leaving historical lookup as an alternative design.

Ethereum developer Hadrien Croubois opened a proposal on November 4 for `SLOTDURATION`, an opcode that would let smart contracts read the duration of the current slot in milliseconds. The proposed interface addresses contracts that need a duration value when converting between slot counts and time.

[Pull request 12619](https://github.com/ethereum/EIPs/pull/12619) was opened at 13:37 UTC and remains open and unmerged as checked on November 4. Its single proposed specification is marked Draft, Standards Track and Core. The file has no assigned EIP number, so this is a submitted design rather than an adopted Ethereum change.

The draft assigns opcode `0x4c` a fixed cost of two gas. It would take no stack input and return the current block’s slot duration. A new `slotDurationMs` header field would carry the value from the consensus layer, with corresponding versions of Engine API payload objects and methods passing it to the execution layer. The design lists EIP-7843, which introduces slot-number access, as a dependency.

That division matters for implementers: the proposed execution layer would copy and expose the duration supplied by consensus without maintaining its own duration schedule. The returned value would describe the current slot, rather than the time elapsed since the previous block.

The [author’s discussion post](https://ethereum-magicians.org/t/slotduration-opcode/30276) leaves a central design question open. An alternative would accept a slot number and look up the historical duration, requiring the execution layer to retain a schedule. The current no-input design does not provide that historical lookup. Reading today’s duration alone therefore would not reconstruct an interval that spans a duration change.

The draft says it does not depend on a slot-duration change. That separates this interface proposal from the [Quick Slots work](https://forkbrief.com/news/dc092304-9c70-4abf-a631-900895b2392e) on changing the duration schedule itself.

The specification also calls for coordinated consensus and execution client upgrades at activation. The open proposal does not establish client implementation, a scheduled activation or a change to Ethereum’s current slot duration.

## Sources

- [Add EIP: SLOTDURATION Opcode](https://github.com/ethereum/EIPs/pull/12619) — Ethereum EIPs repository
- [SLOTDURATION Opcode](https://ethereum-magicians.org/t/slotduration-opcode/30276) — Ethereum Magicians

- [Editorial policy](https://forkbrief.com/editorial-policy)
- [Request a correction](https://forkbrief.com/corrections)