EIP Dispute Resolution Guideline

--- eip: <TBD> title: EIP Dispute Resolution Guidelines description: Guidelines and lightweight procedures for resolving disputes within the Ethereum Improvement Proposal (EIP) process, including authorship, feature scope, process escalation, and contributor coordination. author: Pooja Ranjan discussions-to: TBA status: Draft type: Meta category: Process created: 2026-05-16 requires: 1, 5069 --- ## Abstract This EIP proposes a lightweight dispute resolution and contributor coordination framework for the Ethereum Improvement Proposal (EIP) process. The goal is to improve transparency, contributor confidence, fairness, and coordination while preserving Ethereum’s culture of rough consensus and open participation. The proposal introduces non-binding guidelines and structured escalation paths for disputes related to authorship, contributor attribution, feature scope, technical objections, upgrade inclusion disagreements, editorial process concerns, and behavioral conflicts. ## Motivation As Ethereum governance and protocol development continue to scale, the EIP process increasingly involves contributors from diverse organizations, client teams, research groups, enterprises, and ecosystem communities. While the open nature of the EIP process is a strength, it also creates situations where disagreements emerge regarding: - Authorship and contributor recognition - Feature inclusion and scope expansion - Process enforcement and editorial expectations - Technical direction and implementation tradeoffs - Network upgrade inclusion decisions - Coordination between competing proposals - Communication and contributor conduct Currently, many of these disputes are resolved informally through ad hoc coordination on GitHub, Ethereum Magicians, Office Hours, or All Core Devs discussions. While effective in many cases, the absence of documented expectations can lead to: - Contributor frustration - Social escalation - Perceived process inconsistency - Delayed coordination - Reduced institutional clarity This EIP proposes transparent guidelines and lightweight coordination practices that improve clarity while preserving Ethereum’s decentralized governance culture. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174). ### Definitions #### Author An EIP Author is an individual responsible for documenting and proposing a design, writing the initial specification, driving the proposal toward standardization, building community consensus, and documenting supporting and dissenting viewpoints throughout the process. #### Co-author An individual making substantial technical or specification-level contributions sufficient to materially shape the proposal. #### Contributor An individual providing feedback, testing, review comments, implementation suggestions, or ecosystem coordination assistance. #### Editor As per [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069), EIP Editors serve as process facilitators, archivists, and publishers who maintain long-term accessibility of proposals and discussions, facilitate open community participation, and uphold minimally subjective process and quality standards within the EIP repository. ### Dispute Categories & Resolution Process This EIP recognizes the following common dispute categories within the EIP process. #### 1. Authorship and Attribution Disputes Authorship SHOULD reflect substantial specification or design contributions. Disputes SHOULD first attempt resolution through direct discussion among materially involved contributors. Final authorship outcomes SHOULD ideally emerge through rough consensus among contributors and SHOULD be publicly documented with rationale. #### 2. Feature Scope and Technical Design Disputes Authors SHOULD clearly document proposal rationale, tradeoffs, non-goals, and significant design decisions. Contributors raising blocking concerns SHOULD provide technical rationale and ecosystem impact considerations. Final technical direction SHOULD emerge through rough consensus among ecosystem participants and implementation teams. #### 3. Upgrade Inclusion and Implementation Readiness Disputes Acceptance of an EIP as technically valid SHOULD remain distinct from inclusion in a network upgrade. Final upgrade inclusion decisions SHOULD emerge through rough consensus during All Core Devs (ACD) coordination among implementation teams, reviewers, and network upgrade coordinators based on implementation readiness, ecosystem coordination, testing maturity, and security considerations. #### 4. Duplicate or Overlapping Proposal Disputes Contributors are encouraged to coordinate before fragmenting efforts and SHOULD clearly distinguish proposal objectives and scope. Non-blocking alternative approaches or optional optimizations SHOULD NOT indefinitely delay proposal progression and MAY be pursued through follow-up EIPs where appropriate. #### 5. Editorial and Process Disputes Editors SHOULD remain process-neutral, apply process guidance consistently, and facilitate constructive coordination without unilaterally determining technical direction or ecosystem adoption outcomes. Contributors are encouraged, but not required, to disclose organizational affiliations, grant relationships, commercial implementation interests, or other significant ecosystem dependencies where relevant to proposal coordination. Disputes SHOULD first attempt resolution through direct discussion among involved contributors using publicly accessible proposal discussion channels - including PR discussions, [Ethereum Magicians], and EIP Office Hours where appropriate. Contributors raising concerns SHOULD provide clear rationale and supporting context, including specification contributions, implementation considerations, technical tradeoffs, security implications, interoperability concerns, or repository history where applicable. Editors MAY facilitate coordination, request clarification, and ensure discussions remain constructive and process-oriented; however, Editors SHOULD remain process-neutral and SHOULD NOT unilaterally determine proposal ownership, technical direction, implementation adoption, or network upgrade inclusion. # Recommended Lightweight Dispute Flow ``` Issue Raised ↓ Direct Contributor Discussion ↓ Public Written Clarification ↓ Optional Facilitated Coordination ↓ Office Hours / Governance Discussion ↓ Public Rationale & Resolution ↓ Optional Reconsideration with New Information ``` ## Rationale EIP process operates through open participation, rough consensus, and transparent collaboration across a growing and increasingly diverse ecosystem of contributors, client teams, researchers, enterprises, and community participants. While most disagreements are resolved informally through public discussion and ecosystem coordination, the absence of documented expectations around authorship, contributor responsibilities, proposal scope, technical objections, and escalation paths can create uncertainty, inconsistent process expectations, contributor frustration, and avoidable social escalation. This proposal intentionally avoids: * Binding governance authority * Centralized arbitration * Mandatory voting systems * Heavy procedural overhead Instead, it attempts to: * Clarify contributor expectations * Improve transparency * Reduce unnecessary escalation * Preserve contributor dignity * Improve institutional memory The framework aligns with Ethereum’s historical governance culture while acknowledging growing ecosystem complexity. ## Backwards Compatibility None ## Security Considerations None ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).