Ethereum Draft Proposes CALLSTATUS Opcode to Expose Call Failures

A developer using the handle svlachakis opened a discussion thread on Ethereum Magicians on October 26, 2026, formalizing a draft EIP for a new EVM instruction called CALLSTATUS. The proposal was first submitted as a pull request to the ethereum/EIPs GitHub repository on October 25, 2026, and would add an opcode letting smart contracts read the precise outcome of their most recent call or contract-creation attempt.

What the CALLSTATUS draft actually specifies

Per the Ethereum Magicians thread, CALLSTATUS would give contracts a way to distinguish between different failure modes of a prior call — specifically, whether a sub-call reverted normally or ran out of gas before completing. Today's EVM exposes only a binary success/failure signal through existing call opcodes, forcing contract authors to use indirect workarounds, such as gas-stipend tricks, to infer why a call failed. The draft's changelog, visible on the Ethereum Magicians page, shows the opcode's proposed byte value moved from 0x4D to 0xA5 between the October 25 and October 26 revisions, a change the author attributes to a conflict with a separate pending proposal, EIP draft #12577, which already claims 0x4D. The thread lists outstanding issues as of October 26, including which exact opcode number to finalize — the author notes 0xA5 "is free as far as I can tell" while flagging that the 0x4B-to-0x4F range is contested by other open EIP drafts — and whether the instruction should expose a fourth status value covering "success with a halt" in addition to the baseline revert and out-of-gas distinctions. The author states that no external reviews had been logged for the draft as of October 26.

Why a granular call-status opcode matters for contract design

Contracts that call other contracts — virtually all non-trivial Ethereum applications, including DeFi protocols and multicall routers — currently cannot cheaply tell whether a failed sub-call reverted intentionally or hit an out-of-gas wall. That ambiguity shapes defensive coding patterns across the ecosystem: developers often over-provision gas stipends or wrap calls in try/catch patterns that still can't fully disambiguate the failure cause. A dedicated opcode exposing call status more precisely would let contract logic branch differently depending on why a call failed, which matters for anything handling retries, fallback paths, or accounting after a failed external call. This is an early-stage draft on Ethereum's own EIP discussion forum, not a proposal that has cleared any formal review stage; the author's own changelog describes it as an initial draft with open questions still unresolved. Readers tracking Ethereum's core protocol development can follow the discussion directly on Ethereum Magicians, where the author is actively soliciting feedback on the opcode number and the scope of status values the instruction should return.

As with any EVM-level change, adoption would require community review, client implementation, and eventual inclusion in a network upgrade — none of which has happened at this stage. For now, CALLSTATUS remains a draft under active revision, with its author flagging the opcode byte assignment as the most immediate open question. Developers and researchers following Ethereum's core development process can track further revisions on the same Magicians thread as the proposal moves, or fails to move, toward formal EIP numbering.