Ethereum’s Future

Evolving Protocol Governance and Public Goods Funding Decentralization and Reform

1. Executive Summary

The Ethereum Foundation (EF) has been essential to Ethereum’s development, but as the network matures, decentralizing some functions has become increasingly necessary. This report defines EF’s prime directives — stewarding coordination and resources for protocol development while filling existentially necessary funding gaps the market cannot address.

To accomplish this, EF must streamline core activities, improve transparency in protocol governance, and adopt funding models that extend its finite treasury. By enhancing participation through structured community engagement and vTaiwan-style public consultation processes like Ethereum Town Halls, restructuring ecosystem funding through onchain Donor Advised Funds and staking yield pools for public goods, and ensuring research aligns with ecosystem needs, EF can establish new governance forms maintaining credible neutrality while advancing collective ecosystem aims.

2. Introduction

Ethereum was founded on decentralization, transparency, and open participation principles. The Ethereum Foundation was established to support these values during initial development and growth. Over time, its role has evolved significantly, and today it holds considerable influence over ecosystem funding despite having a relatively small treasury compared with L2 and DeFi protocol treasuries.

Current public sentiment reflects critiques regarding EF’s responsiveness to broader community needs and vision. From multiple angles, the ecosystem expresses that EF’s focus on internal research rather than external developer needs causes resource misallocation failing to accelerate real-world Ethereum adoption. The EF remains inaccessible to many, creating opaque governance structures lacking clear accountability and responsive mechanisms for ecosystem needs. Lack of engagement with builders results in detached research. Many feel EF operates with exclusionary culture discouraging external contributor participation.

As Ethereum grows, EF must evolve toward reduced centralization risks, increased community participation, and funding mechanisms aligned with long-term sustainability. This report proposes structured transition toward further decentralization and community engagement, drawing inspiration from open governance models like the Internet Engineering Task Force (IETF) while introducing innovative funding structures supporting public goods and ecosystem development.

3. Defining the Prime Directives of the Ethereum Foundation

This report suggests EF’s dual core missions are stewarding coordination and resourcing for protocol development and expansion and filling funding gaps existentially necessary for Ethereum’s holistic development which market mechanisms cannot address.

The Protocol Support team is central to this mission, facilitating “All Core Devs” and providing neutral forums balancing incentives and priorities across stakeholder groups.

Currently, Ethereum’s governance and development processes remain transparent yet inaccessible to most community members due to highly technical discussion nature. Internal misalignments and competing interests have created inefficiencies. To address this, we propose:

  • vTaiwan-style public consultation: Ethereum Town Halls and Citizen Assemblies can combine expert perspectives with developer, user, and community needs into holistically considered and transparently communicated network development strategy.

  • Translation of Technical Discussions: Bi-directional AI-generated summaries making protocol development understandable for wider audiences, reducing governance capture risks and providing technical teams more user and community input.

  • IETF-Inspired Governance Adoption: More open working groups democratizing protocol development participation while preserving technical rigor.

This framework ensures EF remains focused on its core mandate while making Ethereum governance more accessible, participatory, and resistant to capture.

4. Theoretical and Comparative Framework For Decentralized Protocol Governance

To improve Ethereum protocol development transparency and responsiveness to real community needs, accelerating wider adoption beyond DeFi applications, increased participation and engagement in protocol development is needed. This report draws on research by Kaliya ‘Identity Woman’ Young and Day Waterbury exploring Internet Engineering Task Force protocol governance patterns. These patterns offer instructive lessons for Ethereum’s protocol development evolution and could be implemented via participatory governance methods Kaliya has offered supporting deployment.

4.1 Historical Context of IETF

The Internet Engineering Task Force (IETF) was founded in 1986 to oversee core internet protocol development including TCP/IP, HTTP, and DNS. Unlike traditional standards organizations, IETF embraced decentralized, open participation models, allowing worldwide engineers and stakeholders to collaborate on internet standards without controlling central authority.

Key aspects of IETF history include:

  • RFC System Formation (1969) — Steve Crocker introduced the “Request for Comments” (RFC) model, providing open document formats for proposing and revising internet standards.

  • U.S. Government Separation (1992) — Originally overseen by DARPA, IETF became independent under the Internet Society (ISOC), ensuring neutrality and autonomy.

  • Web1 Infrastructure Role — IETF played fundamental roles defining early web protocols (HTTP, SMTP, BGP), ensuring permissionless, open-source modern internet foundations.

IETF’s success in developing resilient, neutral, and open protocols makes it a valuable governance model for Ethereum’s decentralized future.

4.2 Mechanics of the IETF Governance Process

IETF operates on open participation, rough consensus, and document-driven decision-making. Its governance structure includes:

  • Open Working Groups (WG)

    • Any individual or organization can join and contribute on specific technical issues (security, transport protocols, cryptography).
    • Working Group Formation: Anyone can propose Birds of a Feather (BOF) sessions exploring potential working groups, though rigorous approval processes precede official WG recognition.
    • Discussions occur via mailing lists, in-person meetings, and virtual conferences.
  • Rough Consensus Decision-Making

    • No formal voting — proposals with strong opposition are refined until consensus emerges.
  • Request for Comments (RFC) Process

    • Standards are drafted as Internet-Drafts (I-Ds) and, once finalized, become RFCs, serving as permanent technical standards.
  • Randomized Nominating Committee (NomCom) for Leadership Selection

    • The Internet Engineering Steering Group (IESG) approves working group decisions.
    • A NomCom, selected via random sortition, nominates new Area Directors composing IESG.
    • This mechanism prevents governance capture and ensures leadership rotation.
  • IETF Last Call Participation: IETF has no formal members; anyone worldwide can participate in IETF last call lists providing feedback.

  • Human-Centric Governance: IETF’s success attributes to three major annual in-person meetings rotating between North America, Europe, and Asia. Human relationships formed at these meetings provide crucial governance stability components.

4.4 IETF Decision-Making & Governance

4.4.1 Hierarchy of Oversight

  • Working Groups (WGs): Primary units where technical discussions and standard development occur.
  • Area Directors (ADs): Oversee related WGs ensuring coordination.
  • Internet Engineering Steering Group (IESG): Approves final drafts before RFC publication.
  • Internet Architecture Board (IAB): Provides long-term strategic direction and resolves disputes.
  • RFC Editor & Internet Assigned Numbers Authority (IANA): Maintains official RFC registries and technical standards.

4.4.2 IESG Selection Process

  1. Nomination Process

    1. Community members nominate candidates for open IESG positions.
    2. The NomCom (Nominating Committee), composed of randomly selected community volunteers, reviews and evaluates nominations.
  2. Community Review & Feedback

    1. NomCom solicits community feedback on nominees assessing leadership suitability.
  3. Area Director Appointment

    1. Once NomCom selects preferred candidates, choices require approval by the Internet Society (ISOC) Board of Trustees.
  4. Term Limits & Rotation

    1. IESG members serve fixed terms with regular role rotation preventing entrenchment.

The key randomized element lies in NomCom selection itself, drawn randomly from active IETF participants. This mechanism introduces sortition elements ensuring broad community representation, though final leadership selection remains deliberative and feedback-driven.

4.5 Comparing the Ethereum Improvement Proposal (EIP) Process and the IETF’s RFC Process

Ethereum’s governance relies heavily on the Ethereum Improvement Proposal (EIP) process, the primary mechanism for proposing and implementing protocol changes. Similarly, IETF maintains the Request for Comments (RFC) process, governing internet standards evolution for decades. While Ethereum’s ERC process addresses non-hardfork changes, IETF and EIP processes differ significantly impacting governance and decentralization.

4.5.1 Structural Differences

  • EIP Process:

    • Primarily driven by Ethereum client teams, core developers, and researchers.
    • Proposals are reviewed through All Core Devs (ACD) calls, where core developer consensus is primary deciding factor.
    • Less defined formal governance structure than IETF’s process, leading to informal power dynamics and potential bottlenecks.
  • IETF RFC Process:

    • Uses formalized working groups for different protocol areas.
    • RFCs progress through defined review stages, ensuring broad community input and technical rigor.
    • Decision-making follows rough consensus rather than majority voting or developer-driven approval.

4.5.2 Decision-Making Mechanisms

  • EIP Process:

    • Lacks formalized governance structure, relying on developer-led coordination.
    • Requires client team adoption for implementation, leading to implicit veto power from dominant client teams.
    • Some proposals get stalled due to misalignments between core developers, researchers, and ecosystem stakeholders.
  • IETF RFC Process:

    • Uses structured working groups refining technical proposals before seeking approval.
    • Employs randomized Nominating Committee (NomCom) selecting leadership roles, preventing governance capture.
    • Ensures long-term decision archival via immutable RFC publication processes.

4.5.3 Transparency and Accessibility

  • EIP Process:

    • Technical discussions are transparent but highly complex, making non-developer participation difficult.
    • No structured mechanisms exist for aggregating community feedback beyond core developer consensus.
  • IETF RFC Process:

    • All discussions, working group notes, and decisions are publicly archived.
    • AI and automated tools could be leveraged improving accessibility, making governance more inclusive.

4.6 Applying IETF Principles to the Ethereum Protocol Governance

Ethereum governance shares several similarities with IETF but lacks formalized processes ensuring neutrality and decentralization. Key areas benefiting from IETF model integration include:

  1. Decentralizing Ethereum’s Governance Through Working Groups

    • Establish Ethereum Working Groups (EWGs) for Protocol Development, Security, L2 Coordination, and Public Goods Funding.
    • Expand Working Group open participation by integrating public Town Halls and interactive sense-making and decision-making mechanisms.
  2. Restructure EF Treasury Into Pluralistic Onchain Allocation Mechanisms For Protocol Support and Public Goods Funding

    • Shift Ethereum’s funding model from EF grants to protocolized funding pools for public goods, governed by stakeholder quadratic voting.
    • Use staking pool rewards and onchain Donor Advised Funds funding ongoing research and development.
    • Improve strategic public goods and research funding allocation through multi-mechanism strategies while maintaining EF credible neutrality.
  3. Implementing a Randomized NomCom for formalized Ethereum Steering Group and Protocol Support Team

    • Introduce sortition-based NomCom overseeing Protocol Support Team and Ethereum Steering Group appointments.
    • Ethereum Steering Group makes final EIP adoption decisions.
    • Area Directors candidates are nominated by NomCom and voted on by participants with elected Area Directors overseeing related Working Groups and composing the Ethereum Steering Group.
    • Protocol Support Team facilitates All Core Devs Calls.
    • Prevent governance capture by rotating leadership every 1-2 years.
  4. Enhancing Transparency and Civic Participation augmented by vTaiwan-style public consultation and AI-Assisted Sensemaking

    • Deploy AI tools summarizing governance discussions, making Ethereum’s decision-making more accessible to non-technical participants.
    • Host Ethereum town halls, citizen assemblies, or public consultation processes engaging broader ecosystem in overarching strategic alignment.
    • Aggregate sentiment from research forums and social media providing structured feedback on protocol evolution and ecosystem needs.

5. Progressive Protocolization: A Strategic Subtraction Approach

Ethereum’s continued decentralization requires shifting from centralized institutional control toward protocolized and community-governed mechanisms. This transition should ensure stability while maximizing stakeholder engagement and transparency.

5.1 Key Strategies for Protocolization

  1. Refining Core Coordination Functions

    • The Protocol Support team remains central to Ethereum’s development, evolving to include better sensemaking mechanisms (AI-assisted governance discussion synthesis) and broader stakeholder participation (vTaiwan-style public consultation) that is both more formal and more open.
    • Development decisions should be more accessible, reducing technical barriers through improved documentation and AI-generated summaries.
  2. Creating Decentralized Equivalents of Centralized Teams

    • Teams involved in ecosystem expansion (Devcon, Developer Growth) should operate as independent entities with their own funding models.
    • EF also could establish parallel decentralized (horizontal) structures for teams falling outside core mandates.
  3. Participatory Grant-making

    • Instead of only providing discretionary EF-controlled funding, onchain public goods funding and onchain Donor Advised Funds should be implemented as complementary treasury fund allocation structures to research and public goods initiatives.
    • A staking DAO model (similar to Octant v2) would allow some funding aspects to be community-driven while ensuring sustainability through staking rewards.
      • This model extends EF’s financial runway while expanding centralized discretion to include decentralized participation in public goods funding.
      • EF could delegate its own staking shares to key community leaders, balancing power dynamics and ensuring broader funding allocation voices.
    • Other mechanisms like viaPrize or Endaoment could offer more centrally controlled treasuries filling gaps while ensuring transparency and community participation.
  4. Enhancing Governance through Working Groups

    • Following IETF inspiration, Ethereum should form independent, specialized working groups for research, execution, and security.
    • These groups should be open to public participation working through consensus-driven approaches.

6. Horizontal and Vertical Restructuring of EF Teams

This section explores how EF could embrace horizontal and vertical restructuring, akin to Taiwanese government response to the Sunflower Revolution establishing decentralized equivalents to centralized ministries.

By streamlining EF responsibilities and structure with centralized and decentralized decision making and resource allocation combinations, resources can be allocated efficiently, governance remains neutral, and unnecessary centralization risks are minimized.

6.1 Core to the EF Mandate (Should Remain Within EF’s Centralized Control)

These teams are essential to Ethereum’s protocol stability, security, and long-term resilience. They contribute directly to Ethereum’s technical development, coordination, and cryptographic research.

  • Protocol Support Team: Facilitates All Core Devs calls, manages upgrade coordination, and acts as neutral stakeholder mediator, ensuring balanced protocol evolution decision-making processes.
  • Consensus R&D Team: Conducts in-depth research on Ethereum’s proof-of-stake model, cryptoeconomic security, and scaling solutions. Their work informs key network upgrades and optimizations.
  • Cryptography Research Team: Investigates and develops cryptographic primitives enhancing Ethereum’s security, privacy, and resilience. Contributions include zero-knowledge proof research and secure protocol upgrades.
  • Robust Incentives Group (RIG): Analyzes cryptoeconomic mechanisms, game theory applications, and validator incentive structures ensuring network remains economically secure.
  • PandaOps: Provides DevOps infrastructure for Ethereum upgrades, testnets, and operational security, ensuring smooth network transitions. Their expertise is critical for Ethereum’s operational stability.
  • Applied Research Group (ARG): Bridges theoretical and applied research, working on MEV, validator incentives, and execution layer efficiency. Their contributions directly impact Ethereum’s roadmap and technical improvements.
  • Ecodev Coordinators: Acts as internal project management team and ecosystem conduit. Decentralized working groups and self-organized governance mechanisms could replace this role, reducing EF’s internal overhead.

6.2 Candidates for Decentralization With Paths To Self-Sustaining Revenue (Independent but Aligned with Ethereum’s Goals)

These teams contribute significantly to Ethereum’s ecosystem but do not require direct EF control. Instead, they could operate independently receiving ecosystem-wide support through decentralized funding mechanisms.

  • Geth Team: As Ethereum’s most widely used execution client, Geth could function independently like other clients (Nethermind, Erigon). This would diversify client governance while ensuring long-term sustainability.
  • Devcon Team: Organizing global Ethereum events is important, but not core to protocol development. Devcon has clear paths to profit or self-sustainability operating via DAO or non-profit structures providing community support without EF funding reliance.
  • Ethereum.org: While Ethereum.org is key educational resource, its maintenance does not require EF oversight and has several clear revenue paths. It could be managed by independent community-run foundation or DAO, providing community-centered resources as public goods while generating revenue through advertising, courses, or paid directory listings.
  • Snake Charmers: Maintains Python-based Ethereum tooling (web3.py). This is valuable for developers but could transition to independent funding via ecosystem grants, productizing, or consulting services.

6.3 Candidates for Hybrid Decentralized and Centrally Coordinated Decision Making

These teams provide valuable services but could benefit from splitting into decentralized (horizontal) and centralized (vertical) ministries. Decentralizing some aspects would allow ecosystem actors participating in funding public goods they benefit from while preserving centralized decision-making aspects.

  • Developer Growth Team: While developer education is critical, funding and educational resources could be managed via decentralized grants models. Note: Since initial report drafting, the Developer Growth Team has successfully spun out of EF into Geodework.
  • Next Billion Team: These initiatives should be externally funded through ecosystem-driven philanthropy or DAOs.
  • STEEL: Provides execution layer specification and testing. This function is important but could be community-managed to prevent EF centralizing test processes.
  • Ethereum Funding Initiative: EFI fills Ethereum’s public goods funding gaps supporting strategic, underfunded, or time-sensitive projects. It prioritizes emerging domains, unfunded areas, and urgent needs while reducing EF dependence. EFI provides flexible support to high-potential initiatives, bridging short-term gaps and fostering sustainability.
  • ESP (Ecosystem Support Program): EF’s grant allocation role is highly centralized. Funding decisions could transition to decentralized public goods funding models hybrids for some public goods funding aspects (community initiatives) while retaining centralized control over specific domains (research initiatives).

7. Protocolization Roadmap

A structured, multi-phase approach ensures smooth transitions:

7.1 Phase 1: Transparency & Modularization (0-6 Months)

Objective: Collaborate with EF mapping internal structures, funding allocations, and dependencies while designing horizontal or decentralized complementary structures.

  • Publish Transition Reports: Release detailed reports on phased horizontal or decentralized structure deployment providing full visibility into financial and operational structure transitions.
  • Modularize EF Functions: Clearly define core responsibilities remaining centrally controlled within EF and identify functions expandable into horizontal complementary structures.
  • Establish Open Governance Discussions: Create structured forums where stakeholders discuss and provide EF transition input, ensuring community participation from the outset.
  • Develop a Transition Support Program: Provide logistical, legal, and financial support to teams preparing for independent operation, ensuring smooth transitions without disruptions.

7.2 Phase 2: Progressive Decentralization (6-18 Months)

Objective: Reduce EF’s centralized control over funding and governance by implementing decentralized funding and decision-making mechanisms.

  • Transition EF Grants to Hybrid Decentralized and Centralized Funding: Establish protocolized funding models such as quadratic funding, staking-backed DAOs, and retroactive public goods funding complementing direct EF grant allocations.
  • Formalize New Protocol Governance: By collaboratively writing Ethereum protocol governance constitutions, new collective decision-making and sense-making mechanisms can be gradually introduced by following protocolization roadmaps and developing new modular governance functions.
  • Diversify Public Goods Funding Models: Implement pluralistic funding approaches, where multiple funding mechanisms (Endaoment, Gitcoin, Octant, L2-native DAOs) support Ethereum’s ecosystem needs.
  • Formalize Independent Governance Bodies: Establish Ethereum Working Groups (EWGs) modeled after IETF, each focused on different protocol development, security, and research aspects.
  • Expand the NomCom-Like Selection Process: Implement randomized Nominating Committee (NomCom) mechanisms selecting key governance roles, ensuring broader community representation and preventing entrenched power structures.
  • Pilot Staking-Based Treasury Management: Begin shifting EF treasury management portions to community-governed staking DAOs, where staking rewards fund development initiatives transparently without principal spending downs.
  • Encourage Client Independence: Provide support for Ethereum client teams (Geth, Nethermind, Erigon) functioning as fully independent entities rather than EF funding and coordination reliance.

7.3 Phase 3: Full Decentralization (18-36 Months)

Objective: Finalize transitions to hybrid self-sustaining, decentralized governance models with deep centralized equivalent relationships, ensuring not all key functions require direct EF oversight.

  • Ensure Decentralized Governance Frameworks are Fully Operational: Confirm independent working groups, NomCom-based governance, and community funding mechanisms are effectively managing Ethereum’s core development and research priorities.
  • Monitor and Iterate on Decentralized Models: Conduct periodic evaluations refining decentralized governance processes, ensuring long-term adaptability and resilience.

8. Conclusion

Ethereum’s long-term sustainability requires reducing centralized institution reliance. By refining EF’s prime directives, establishing some current EF function horizontal versions, and implementing protocolized funding mechanisms, Ethereum can achieve more transparent, community-driven, and decentralized governance structures.

EF should evolve into neutral protocol development coordination body, ensuring research, execution, and governance remain aligned with Ethereum’s core principles. By leveraging decentralized funding models and transparent protocol governance, Ethereum can remain thriving, self-sustaining ecosystem for generations.

Adapting IETF-inspired governance, Ethereum can improve neutrality, transparency, and decentralization while maintaining protocol evolution technical rigor. Key recommendations include:

  1. Establish Open Ethereum Working Groups (EWGs) decentralizing protocol governance.
  2. Introduce a Randomized NomCom for rotating leadership selection.
  3. Expand public goods funding to include Staking DAO models for sustainable ecosystem development.
  4. Implement vTaiwan-style public consultations enhancing accessibility and participation.

These reforms would future-proof Ethereum’s governance, ensuring that no single entity — whether EF, corporate actors, or large token holders — can unilaterally dictate Ethereum’s evolution, securing its role as foundational global blockchain infrastructure layer.

References

Ethereum Governance & EF Documentation

IETF & Open Governance Models

Technical & Economic Studies on Staking DAOs