The EIP-7979 reference implementation in ethereum/execution-specs is designed to test the proposed structured subroutine flow for the EVM: it exercises CALLSUB, CALLDEST, and RETURNSUB, validates use of a separate, inaccessible return stack, and enforces runtime halts for invalid call destinations, empty return stacks, and exceeding a depth of 1024. These tests show how the draft could behave; they are not an approval, client commitment, or deployment plan. The EIP remains Draft, opcode values are placeholders, gas costs are unbenchmarked, and there is no selected hard-fork or mainnet activation—hence, tests do not equal adoption.
Operative status and evidence cutoff: as of 12 September 2026 18:14:30 IST, the canonical EIP-7979 entry in the Ethereum EIPs repository lists status as Draft, Standards Track: Core. According to the ethereum/execution-specs maintainers, a pull request opened on 11 September 2026 20:34:47 IST describes a reference implementation and 44 tests producing 130 fixtures for this proposal. At collection, the PR was open (unmerged). No Hegotá selection, final opcode values, final gas schedule, multi-client adoption, fork schedule, or mainnet activation was established. Claims about security benefits remain design statements pending review and benchmarking.
Open PR and Draft EIP status
Per the ethereum/execution-specs maintainers, the open pull request adds a reference implementation of EIP-7979 along with 44 tests that yield 130 fixtures. The PR was open and unmerged at the time of collection. This places the work in an open and pending state within the execution-specs repository, not an approved change to any client.
The canonical EIP record, maintained by the Ethereum EIPs editors, lists EIP-7979 as Draft, Standards Track: Core. That Draft label signals a proposal under discussion. Draft does not imply consensus among client teams, nor a greenlight for deployment; it merely indicates that the proposal is written in EIP format and under review.
Until the PR is merged, reviewed across teams, and scheduled for a specific network upgrade through the Ethereum core developer process, its status remains open and unapproved. Even after a merge into specs, client integrations and a fork selection would still be required before any effective activation.
The control-flow problem the proposal addresses
The EVM today uses JUMP and JUMPDEST for control flow, which places the burden of subroutine-like behavior on general-purpose stack manipulation and careful layout of code. This can be error-prone for structured calls and returns, complicating static analysis and tooling, and making certain safety properties harder to guarantee.
EIP-7979 proposes explicit subroutine semantics to make intra-contract control flow more structured. By distinguishing subroutine entry points and returns, it aims to reduce ambiguity around jump targets, improve analyzability, and enable more predictable execution paths. These are design objectives articulated in the proposal; they are not yet measured outcomes.
For auditors and formal methods practitioners, structured calls could reduce classes of control-flow mistakes. However, benefits remain proposed until validated through benchmarking, auditing, and client experimentation coordinated via the Ethereum core development process.
CALLSUB, CALLDEST and RETURNSUB conceptually
Conceptually, CALLDEST marks a valid subroutine entry point. CALLSUB transfers control to a designated CALLDEST, while pushing a return address onto a dedicated return stack. RETURNSUB pops that return address and resumes execution there. These opcodes are intended to provide clear, structured call/return mechanics within a single contract’s code segment.
Within the draft, invalidating factors—such as attempting to CALLSUB to something that is not a CALLDEST—are designed to halt at runtime. Likewise, invoking RETURNSUB without a pending return address is meant to halt, rather than fall through unpredictably. These semantics target determinism and analyzability.
Importantly, the opcode numeric values are still placeholders in the EIP, and gas costs have not been finalized. Implementers should treat the behavior as proposed, not final. Benchmarks and client feedback will inform whether adjustments are needed prior to any approval.
Separate return stack and runtime halts
A key part of the design is a dedicated return stack that is inaccessible to ordinary EVM code. By separating return addresses from the data stack, the draft attempts to prevent accidental or malicious manipulation of return points through general stack operations, which is a known complexity in unstructured control flow.
Per the draft specification, runtime must halt when: (1) a call destination is invalid (not a CALLDEST), (2) a RETURNSUB is executed with an empty return stack, or (3) the return stack depth would exceed 1024. These halts are intended safety rails, but they remain proposed semantics until finalized.
Security improvements at this stage are design claims attributed to the proposal and its authors and maintainers; they have not been established as deployed properties. Evidence that would modify this assessment would include merged specs, multi-client implementations, and formal acceptance into a named network upgrade.
Forty-four tests and 130 fixtures
According to the ethereum/execution-specs PR description (11 September 2026 20:34:47 IST), the reference implementation is accompanied by 44 tests that generate 130 fixtures. These fixtures aim to exercise valid and invalid control-flow paths, nested subroutine depths, and halting conditions, providing deterministic inputs/outputs for implementers to compare against.
Fixtures are valuable because they enable repeatable test vectors across environments, but they are not themselves normative for consensus until adopted by clients. At present, the tests are a reported artifact of an open PR and constitute helpful scaffolding for evaluation rather than a standard.
Source attribution: ethereum/execution-specs maintainers report a reference implementation plus 44 tests producing 130 fixtures for EIP-7979; PR open and unmerged at collection.
Placeholder opcodes, gas benchmarking, clients and fork selection
The EIP explicitly leaves opcode values as placeholders and defers gas schedule decisions to later benchmarking. Until the benchmarking is performed and reviewed, gas costs remain unknown. Absent concrete opcode assignments, client teams cannot ship interoperable releases.
Multi-client adoption is likewise pending. For any Core EIP to move forward, client implementations (for example, across major execution clients) need to converge on behavior, followed by testing on devnets and public testnets. A hard-fork selection—none exists yet for this item, including no Hegotá selection—would then be required to coordinate activation.
In other words: placeholders and open questions keep this proposal in a not-yet-approvable state. Evidence that would change this includes finalized opcode numbers, published gas analysis, merged implementations across multiple clients, and explicit inclusion in a scheduled network upgrade announced via the Ethereum core developer process. For background on reading upgrade notices, see our guide.
India developer relevance and the path from proposal to activation
India’s Ethereum developers, auditors, and researchers may find structured subroutines attractive for analyzability and audit hygiene. However, because EIP-7979 is Draft and unselected for any fork, teams in India should treat it as an open research and engineering topic rather than a feature to target in production builds or audits. If you assess operational risk in contracts, consider the general lessons about control-flow safety in our primer on smart contract execution risk.
The typical path from proposal to activation involves: Draft EIP discussion; prototype and tests (as reported here); client experimentation; benchmarking (gas); AllCoreDevs triage; testnets; and finally a named hard-fork selection and activation. At present, EIP-7979 sits near the front of this path. For contrast with another in-flight standardization track, see how resource accounting proposals like EIP-8141 communicate open parameters until benchmarking concludes.
Nothing in this article is financial, legal, tax, or security advice. Do not infer trading signals or deployment commitments from a Draft EIP or an open PR. Activation only occurs after explicit, public decisions recorded in the Ethereum core development process and reflected in client releases.
Bottom line: the reference implementation and its 44 tests with 130 fixtures demonstrate how EIP-7979 could work and help reviewers probe edge cases, but they do not constitute approval, client consensus, or deployment. The current state is open and draft, with key parameters pending and no scheduled fork.