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 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 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 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.