A Draft EIP is the first official status of an Ethereum Improvement Proposal (EIP) after it has been assigned a number but before it undergoes formal peer review. At this stage, the proposal is a work-in-progress document hosted in the Ethereum EIPs repository, typically in a pull request. The primary goal of the Draft phase is to solicit broad community feedback, identify potential issues, and iterate on the technical specification. Authors use this period to refine their proposal's logic, security considerations, and backward compatibility before seeking advancement. It is the most fluid and collaborative stage in the EIP lifecycle.
Draft EIP
What is a Draft EIP?
A Draft EIP is the initial, formative stage of an Ethereum Improvement Proposal, representing a work-in-progress specification open for community feedback and iteration before formal review.
The path to becoming a Draft EIP begins when an author submits a properly formatted proposal to the EIP GitHub repository. A champion, often an EIP editor, will assign it a number and move it into the Draft state. Key requirements for a Draft include a clear title, abstract, motivation, and a detailed specification. Crucially, the specification does not need to be final; it is expected to evolve. Community members discuss the draft in the pull request and on Ethereum forums like Ethereum Magicians, providing technical critiques that shape the proposal's future direction.
A Draft EIP remains in this state until the author believes it is ready for the next stage: Review. There is no strict time limit, but prolonged inactivity may lead to the draft being marked as Stagnant. To move forward, the author must request a review by an EIP editor, who will assess if the draft has received sufficient community discussion and addresses all critical feedback. Not all drafts progress; many are abandoned or superseded. This rigorous early-stage filtering ensures that only well-vetted proposals advance toward potentially impacting the Ethereum network through a core EIP or an ERC standard.
How the Draft EIP Process Works
An Ethereum Improvement Proposal (EIP) begins its life as a draft, a formal document proposing a new feature, standard, or process for the Ethereum ecosystem. This section details the structured path from initial idea to community review.
A Draft EIP is the initial, pre-standardization stage of an Ethereum Improvement Proposal, where the author formalizes a technical specification or process change for community scrutiny. The process is governed by EIP-1, the meta-EIP that defines all procedures. An author creates a draft by submitting a pull request to the official EIPs repository using a specific template, which includes critical sections like the abstract, motivation, and technical specification. At this stage, the proposal is assigned a number and enters the "Draft" status, indicating it is open for early feedback and iteration but is not yet ready for broader consensus.
The core of the draft phase is collaborative refinement. The EIP editor assigns reviewers, often domain experts, who provide technical feedback on the proposal's clarity, feasibility, and alignment with Ethereum's design philosophy. This iterative process happens publicly on the GitHub pull request, where discussions, commits, and reviews are transparently logged. Key activities include resolving open questions, ensuring the specification is unambiguous, and checking for conflicts with existing standards. A draft only progresses when the author has addressed substantive feedback and the EIP editor is satisfied that the document is structurally and technically sound.
Not all drafts move forward. Some may be abandoned if the author loses interest, if the proposal is superseded, or if fundamental flaws are identified. A successful draft, however, undergoes a final editorial review for formatting, licensing, and compliance with EIP-1 rules. Once it meets all criteria, an EIP editor moves the proposal to "Review" status. This promotion signals that the draft is considered complete and ready for wider community evaluation, often involving core developers and client teams, which is a prerequisite for the subsequent "Last Call" and "Final" stages that lead to network adoption.
Key Features of a Draft EIP
A Draft EIP is the initial, formal proposal stage in the Ethereum Improvement Proposal lifecycle, where a new standard or protocol change is documented for community review.
Formal Specification
A Draft EIP must provide a technical specification using a precise RFC-style format. This includes:
- A clear abstract and motivation.
- Detailed technical specifications, often with pseudocode or formal logic.
- Backwards compatibility analysis.
- Test cases and reference implementations. This structured format ensures the proposal can be rigorously evaluated by developers and client teams.
Community Review & Feedback
The primary purpose of the Draft status is to solicit peer review from the Ethereum community. The draft is discussed on forums like the Ethereum Magicians and the EIPs GitHub repository. Key feedback areas include:
- Technical soundness and security.
- Network upgrade complexity.
- Potential conflicts with other standards. This open process is critical for identifying flaws before implementation.
Prerequisite for 'Review' Status
A Draft EIP is a mandatory gateway. To advance to the 'Review' or 'Last Call' stage, the draft must:
- Have its specification finalized based on feedback.
- Gain a champion from an EIP Editor.
- Demonstrate sufficient community discussion. Without a properly formatted and discussed draft, an EIP cannot progress in the standardization process.
Living Document
During the Draft phase, the EIP is a living document subject to significant changes. Authors are expected to:
- Iteratively update the specification based on feedback.
- Mark new versions clearly.
- Respond to all substantive technical questions. The draft is not static; it evolves through collaboration before being locked for final review.
Core vs. ERC Drafts
Draft EIPs are categorized by type, which dictates their review path:
- Core EIPs: Propose consensus-layer changes (e.g., EIP-1559). Require a network upgrade and involve client teams.
- ERC Drafts: Propose application-layer standards (e.g., ERC-20, ERC-721). Reviewed by domain experts and the wider developer community. The distinction determines the relevant stakeholders for the review process.
Example: EIP-1559 as a Draft
EIP-1559 (Fee Market Change) spent over two years as a Draft EIP. During this time, its specification was refined through:
- Extensive economic modeling and simulation.
- Security audits of the proposed mechanism.
- Prototype implementations in Geth and other clients. This prolonged draft phase was essential for testing its complex impact on Ethereum's economics and security before mainnet deployment.
EIP Status Comparison: Draft vs. Other Stages
A comparison of key characteristics and requirements for an EIP as it progresses through the standardization process.
| Feature / Requirement | Draft | Review | Last Call | Final |
|---|---|---|---|---|
Formal Specification Required | ||||
Community Review & Feedback | Open for initial feedback | Formal review period | Final review window | Feedback incorporated |
Core Devs / ACD Consideration | Initial discussion | Final commentary | Decision finalized | |
Status Change Timeline | No fixed limit | Minimum 2 weeks | Minimum 2 weeks | Permanent |
Ethereum Client Implementation | Prototype possible | Recommended for testing | Required for mainnet | |
Formal Security Audit | Recommended | Strongly recommended | Often required | |
Can Be Superseded | ||||
Typical GitHub Label | Draft | Review | Last Call | Final |
Required Components of a Draft EIP
A Draft Ethereum Improvement Proposal (EIP) must follow a standardized template to ensure clarity, facilitate peer review, and maintain a consistent historical record. The required components are defined in EIP-1.
Preamble & Metadata
The header contains critical metadata for indexing and categorization. This includes:
- EIP Number: A unique identifier assigned upon submission.
- Title: A concise, descriptive name.
- Author(s): The creator(s) and their contact information.
- Type: The EIP's category (e.g., Standards Track, Meta, Informational).
- Status: Always begins as 'Draft'.
- Created: The submission date.
- Requires/Dependencies: References to other EIPs this proposal builds upon.
Abstract
A technical summary of 200-300 words that succinctly describes the problem being solved and the proposed solution. It should be understandable to a wide technical audience and allow readers to quickly gauge the EIP's scope and relevance without reading the full specification. A well-written abstract is crucial for initial reviewer engagement.
Motivation
This section justifies the proposal by clearly articulating the problem statement. It explains why the current state of the Ethereum protocol, ecosystem, or process is inadequate. The motivation should address:
- The specific shortcomings or limitations.
- The stakeholders who are affected.
- The benefits the EIP aims to deliver, establishing a clear 'why' before the 'how'.
Specification
The core technical content of the EIP. It provides a detailed, unambiguous description of the proposed change. For Standards Track EIPs, this must be precise enough for developers to implement it correctly. The specification often includes:
- Technical diagrams or data flow charts.
- Formal definitions of new data structures, functions, or RPC methods.
- Pseudocode or explicit logic describing behavior.
- Backwards compatibility analysis.
Rationale
Explains the design decisions made during the specification's creation. It documents the alternatives that were considered (e.g., different cryptographic primitives, consensus mechanisms, or API designs) and articulates why the chosen approach was selected over others. This section provides crucial context for future reviewers and prevents re-discussion of settled debates.
Backwards Compatibility & Security Considerations
Mandatory analyses that assess the proposal's impact.
- Backwards Compatibility: Must detail any breaking changes to clients, smart contracts, or tooling. If breaks exist, a migration path must be proposed.
- Security Considerations: A thorough review of potential security implications, including new attack vectors, gas cost changes, denial-of-service risks, and impacts on cryptographic assumptions. This is non-negotiable for any protocol change.
How to Submit a Draft EIP
A step-by-step guide to the formal process of proposing a new standard or improvement to the Ethereum protocol through the Ethereum Improvement Proposal (EIP) system.
The submission of a Draft EIP is the first formal step in the Ethereum governance process for proposing a new feature, standard, or protocol change. A draft is a preliminary version of an EIP that is published to solicit community feedback and begin technical review before it can advance to a more mature state. To submit, an author must first create a well-researched proposal that follows the official EIP-1 specification, which defines the required structure, format, and templates for all EIPs. The core document must include sections for the abstract, motivation, specification, rationale, and backwards compatibility.
Once the draft document is prepared, the author submits it as a Pull Request (PR) to the official EIPs GitHub repository. The PR must target the correct directory—typically /EIPS for core protocol EIPs or /ERCS for application-level standards—and be formatted according to the repository's conventions. Upon submission, the EIP editor team will assign a unique EIP number and the Draft status. The PR then enters a public review phase where community members, including core developers and other stakeholders, can comment, ask questions, and suggest technical improvements.
The author is responsible for actively shepherding their draft through this feedback period, which is critical for identifying flaws and building consensus. Key actions include responding to comments on the GitHub PR, engaging in relevant forums like the Ethereum Magicians, and potentially presenting the proposal at All Core Devs meetings if it concerns the core protocol. A draft remains in this state until the editor, in consultation with the community, determines it is sufficiently polished and has addressed major concerns. Only then can it be merged into the repository and potentially progress to Review, Last Call, or Final status, marking its formal acceptance into the Ethereum standards track.
Frequently Asked Questions (FAQ)
Common questions about Ethereum Improvement Proposals (EIPs), the formal process for proposing changes to the Ethereum protocol, client APIs, and standards.
An Ethereum Improvement Proposal (EIP) is a formal design document that provides information to the Ethereum community or describes a new feature, process, or standard for the Ethereum ecosystem. It serves as the primary mechanism for proposing, discussing, and implementing changes, following a structured workflow from Draft to Final. EIPs are categorized into three main types: Core EIPs for consensus-breaking protocol changes, ERC (Ethereum Request for Comments) for application-level standards like token interfaces, and Networking EIPs for changes to the devp2p layer. The process is governed by EIP Editors who manage the repository and ensure proposals meet required specifications before acceptance.
Examples of Influential Draft EIPs
While still in the proposal stage, these Draft EIPs have generated significant discussion and often preview major protocol upgrades or new standards.
Common Misconceptions
Clarifying frequent misunderstandings about Ethereum Improvement Proposals (EIPs) in the draft stage, their purpose, and the formal process they must undergo.
A Draft EIP is the initial, informal stage of an Ethereum Improvement Proposal where an idea is shared with the community for early feedback before formal submission. It works by an author publishing their proposal to a public forum, such as the Ethereum Magicians forum or a GitHub pull request marked as 'Draft,' to gather initial reactions, identify potential issues, and gauge interest. This stage is crucial for refining the proposal's technical details and scope. A Draft EIP has no official status in the EIP repository until it is moved to the 'Review' or 'Last Call' stage by an EIP Editor, signifying it is ready for formal peer review. The draft phase is intentionally lightweight to encourage open collaboration and iteration.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.