Ethereum Governance Reflection: Why Is There Dissatisfaction About the EIP-3074 Incident?
TechFlow Selected TechFlow Selected
Ethereum Governance Reflection: Why Is There Dissatisfaction About the EIP-3074 Incident?
The Ethereum EIP-3074/EIP-7702 incident revealed the complexity of its governance structure: in addition to formal governance processes, informal roadmaps proposed by researchers also wield significant influence.
Navigating Web3 tides with focused insightsAuthor: Bu Lu Shuo
This article presents my reflections on the recent EIP-3047 incident. I thank Vitalik and Yoav for reviewing the content.
If you're unfamiliar with this event, here's a brief recap:
Not long ago, the EIP-3074 proposal received a green light from core developers and was planned for implementation in Ethereum’s next hard fork, Pectra. The goal of this proposal was to allow ordinary Ethereum accounts (EOAs) to enjoy the many benefits of account abstraction (commonly abbreviated as AA).
However, shortly afterward, the ERC-4337 community—especially its drafters—strongly opposed EIP-3074, arguing that it could increase centralization risks and conflict with Ethereum's account abstraction roadmap, which centers around EIP-4337 and its close relative EIP-7560 (also known as native account abstraction).
Last week, Vitalik proposed EIP-7702 as an alternative to EIP-3074. It aims to deliver similar benefits of account abstraction to EOA users but is designed to better align with the current EIP-4337 standard and enable a smooth transition toward the final form—EIP-7560.
Translator’s note: Both ERC-4337 and ERC-7560 are proposals within the Ethereum ecosystem related to account abstraction, aiming to improve user account management and interaction methods, enhancing user experience and security.
ERC-4337 allows users to manage their accounts through proxy contracts, reducing complexity and risk during DApp interactions. ERC-7560 aims to integrate the concepts from ERC-4337 directly into Ethereum’s base layer, enabling all accounts to natively support account abstraction, thus achieving deeper integration and optimization.
ERC-4337 serves as a crucial step toward ERC-7560; together, they form the core of Ethereum’s account abstraction roadmap.
Currently, the core developer team is discussing EIP-7702, and early signals and community feedback suggest that EIP-7702 will likely replace EIP-3074 in the Pectra hard fork.
Personally, I am very satisfied with this outcome: EOA users will soon be able to access most of the benefits of account abstraction via tools and infrastructure built for ERC-4337.
Yet, the process leading to this point troubles me—it feels far from optimal and echoes what many others have felt recently. I firmly believe that with a more robust process, we could have minimized disruptions and reached consensus faster.
In this article, I intend to:
-
Analyze the problems in the process
-
Propose a mental framework for understanding Ethereum governance
-
Explore how to improve and avoid repeating this mistake in the future
Why do people feel upset?
The entire episode left many feeling dissatisfied for several reasons:
-
Long approval journey: EIP-3074 took years before finally receiving approval.
-
Delayed feedback: Only after EIP-3074 passed did core developers widely hear opposition from the ERC-4337 community.
-
Warnings ignored: Despite multiple warnings from ERC-4337 authors about EIP-3074, their concerns were largely dismissed.
-
Policy reversal: We now face the prospect of reversing EIP-3074 and replacing it with EIP-7702.
Objectively speaking, each of these steps individually seems reasonable:
-
Extended discussion is normal.
-
Opposition arising after approval is also common.
-
Adjusting or even canceling decisions when new issues emerge makes logical sense.
Nevertheless, we might agree that the process could have been much smoother. Imagine instead if things had unfolded like this:
During core developer discussions on EIP-3074, the ERC-4337 community actively participated. This would lead to only two possible outcomes:
-
Either EIP-3074 is approved (possibly revised) after incorporating feedback from the ERC-4337 community, meaning the community would support it and no reversal would be needed.
-
Or EIP-3074 never gets approved, but the ERC-4337 community collaborates with core developers to advance a mutually acceptable proposal—just like EIP-7702.
Everyone’s voice is heard, and there’s no dramatic reversal. This would have been an ideal outcome—but why didn’t it happen?
Where did things go wrong?
Looking back at the whole process, both sides have pointed fingers.
Core developers (including EIP-3074’s authors) argue that if the EIP-4337 team had engaged more actively in the All Core Devs (ACD) process, this issue wouldn’t have occurred.
In this process, proposals undergo lengthy discussions before being accepted and integrated into protocols by client teams. They believe the EIP-4337 team could have stepped in at any time to raise concerns, rather than waiting until after EIP-3074 was approved. After all, the ACD process is open and transparent, meetings are public, and individuals like Tim Beiko summarize them on social media. If the EIP-4337 team truly cared, why didn’t they invest the time to participate?
Conversely, the account abstraction team (i.e., EIP-4337 authors) emphasize that they actually attended ACD meetings and seized every opportunity to oppose EIP-3074, but were not heeded by core developers. Moreover, many members of the EIP-4337 community were genuinely surprised—some thought EIP-3074 had already been abandoned and didn’t even know it was still under consideration.
Additionally, some argue that the ACD process is too complex for those with full-time jobs who can’t keep up with every update. Others believe it should be the responsibility of ACD organizers to proactively consult key stakeholders—such as the EIP-4337 community.
In my view, neither side fully grasps the root problem. There is a deeper issue at play, and unless we address or at least acknowledge it, we’ll keep experiencing governance failures and fall into cycles of unproductive blame.
The Real Problem
The real crux of the governance failure lies in a widespread misunderstanding of the All Core Devs (ACD) forum. ACD is not the sole decision-making body for protocol upgrades. In this case, another governance force actually overrode ACD and played a decisive role.
The problem is that although this critical governance force exerts major influence over important Ethereum matters—like account abstraction and scalability—it is rarely formally acknowledged.
I refer to this force here as the “roadmap.”
Put simply, the entire shift from EIP-3074 to EIP-7702 is a classic example of the “roadmap” force overriding the decision-making power of ACD.
From a governance perspective, when an invisible force overrides a visible one, we should be alarmed—because invisibility means lack of oversight. Therefore, we must expose and scrutinize this hidden force.
What Is a Roadmap?
Within Ethereum circles, terms like “rollup-centric roadmap,” “ETH 2.0 roadmap,” or the “account abstraction roadmap” discussed here are familiar.
Imagine a scenario during an All Core Devs meeting where everyone is discussing how to scale the network:
Core Developer Bob proposes: I support EIP-1234, which advocates making block times 10x faster, block sizes 10x larger, and transaction fees 100x lower.
Other developers respond: Are you serious?
Think about it: Why is Bob’s proposal quickly rejected? He did propose a valid scaling solution—one used effectively by other public chains like Solana.
The reason is that Bob’s proposal contradicts Ethereum’s rollup-centric scaling roadmap. This roadmap emphasizes that for blockchain decentralization to be preserved, it must remain easy for ordinary users to run nodes. Thus, Bob’s proposal drastically increases node operation difficulty, conflicting with the roadmap, and is therefore ruled out.
Through this example, I want to illustrate that core developers participating in ACD meetings and responsible for protocol updates actually follow a higher guiding principle—the so-called roadmap. There are various roadmaps (e.g., scalability, account abstraction, MEV), which collectively form Ethereum’s overall roadmap and serve as the basis for core developer decisions.
When Core Developers Clash With the Roadmap
Because roadmaps aren’t part of formal governance, core developers don’t always align with them. Especially since there’s no official “roadmap approval” process, not all roadmaps enjoy equal recognition. This requires roadmap advocates to actively promote their vision among core developers and the broader community to gain acceptance and support.
Take account abstraction as an example: Although Vitalik has repeatedly endorsed a roadmap centered on EIP-4337, it’s primarily the EIP-4337 team—particularly Yoav and Dror—who have championed this direction through conferences, online forums, and ACD meetings.
Yet even so, some core developers opposed the EIP-4337-centric roadmap, arguing that EIP-7560 (the native version of EIP-4337, requiring future client implementation) is too complex and not the only path to achieving final account abstraction. Ultimately, despite the EIP-4337 team’s opposition—arguing that EIP-3074 would fragment the account abstraction ecosystem by introducing a competing, more centralized stack—the ACD forum still approved EIP-3074.
However, after EIP-3074 was approved, strong backlash from the entire EIP-4337 community prompted core developers to reevaluate. Deadlocked, the situation only shifted when Vitalik introduced EIP-7702 as a replacement—a proposal clearly aligned with the EIP-4337-centric account abstraction roadmap—steering developments back onto the intended path.
Vitalik’s Role
Although Vitalik sees himself primarily as a researcher, this incident reveals his unique and distinct role in Ethereum governance. This raises the question: What exactly is Vitalik’s role in Ethereum governance?
We can imagine Vitalik as the CTO of a large tech company.
If you’ve worked at a tech company of significant size—say, over 50 people—you understand that a CTO cannot be involved in every technical decision. As companies grow, technical decisions naturally decentralize, and sub-teams across product areas generally make autonomous choices about implementation details.
Moreover, the CTO isn’t necessarily the top expert in every domain. There may be engineers within the company who surpass the CTO in specific areas. So in technical disputes, engineers often make the final calls.
However, the CTO sets the company’s technical vision, while execution is delegated to developers.
While imperfect, this analogy accurately captures Vitalik’s role in the Ethereum ecosystem.
Vitalik doesn’t engage in every technical decision—he couldn’t, nor is he the top expert in every field. But he wields immense influence over roadmaps for all key aspects of Ethereum (e.g., scaling, account abstraction, proof-of-stake), not just due to his technical knowledge, but because he ultimately judges whether a roadmap aligns with Ethereum’s vision—which, in essence, is his own vision.
Vision Drives Every Successful Product
As an entrepreneur, I believe every successful product is driven by a clear vision. Such a vision is typically established by a small group—often the founding team, sometimes even a single key founder.
The magic of Ethereum lies in how such a complex, multi-layered system functions cohesively as a decentralized computer handling massive value daily. This wasn’t achieved through committee-style decision-making, but through Vitalik’s visionary leadership. From its 2015 inception to today, Ethereum remains an embodiment of Vitalik’s intellect.
This isn’t to diminish the contributions of other researchers and engineers—they’ve made invaluable contributions to Ethereum’s development. Yet it’s undeniable that Ethereum is the ultimate expression of Vitalik’s vision, far exceeding the influence of any other individual.
Honestly ask yourself: When you joined Ethereum because of its openness, censorship resistance, and innovative vitality, did you care that it all originated from Vitalik’s original idea?
Maybe you hadn’t thought about it before—but now that you know, do you really mind?
Ethereum was born from a clear vision and continues to grow by realizing that vision—that is its charm.
But What About Decentralization?
You might ask: If one person holds such significant influence over Ethereum, how can we call it decentralized?
To answer this, consider a classic article by Vitalik explaining the multiple dimensions of decentralization. The key takeaway is that decentralization has three aspects:
Architectural decentralization: How many nodes need to fail before the system stops working?
Logical decentralization: Can parts of the system evolve independently without affecting overall functionality?
Political decentralization: How many people or entities control the system?
Ethereum is unquestionably decentralized architecturally and logically, as it operates across numerous nodes and components (like consensus and execution layers) can develop relatively independently.
Regarding political decentralization, the good news is no single entity—including Vitalik—can shut down Ethereum. However, it’s undeniable that Vitalik’s pivotal role in shaping Ethereum’s vision and roadmap implies some compromise in political decentralization.
My view is that to sustain innovation in Ethereum, we should accept Vitalik’s de facto role as CTO, even if it reduces political decentralization somewhat. Before Ethereum matures into a stable, unchanging system like Bitcoin, it needs a widely respected authority figure who makes decisions not just based on technical merit, but also ensures alignment with Ethereum’s long-term vision.
Without such a figure, Ethereum might face two scenarios—as illustrated vividly by the EIP-3074 incident:
-
Decision deadlock: Parties refuse to compromise, stalling progress—exactly what happened with EIP-3074 until Vitalik intervened.
-
Design fragmentation: The system risks becoming an incoherent patchwork—nearly happening with incompatible parallel stacks like EIP-3074 and EIP-4337.
Therefore, during Ethereum’s rapid evolution phase, Vitalik’s leadership is crucial for maintaining an ecosystem that is both decentralized and directionally coherent.
The Importance of Community
So far, we’ve nearly built a comprehensive framework for understanding Ethereum governance, but one critical element remains unaddressed—the role of the community.
If Vitalik sets the vision, researchers design roadmaps accordingly, and core developers implement them, then what role does the community play? Surely not an insignificant one?
In fact, the community plays the most fundamental role. Because before any vision exists, there is something even more foundational—values. We come together as a community because we share certain values, which form the bedrock of Vitalik’s vision. These values must align; otherwise, the community ceases to exist.
Whether shaped by upbringing or past experiences, each member of the Ethereum community, at some point, recognized the global value of building a universally accessible, censorship-resistant, truly decentralized computer. Our daily work on Ethereum embodies and affirms these values. It is precisely through these actions that we give life and legitimacy to the visions, roadmaps, and code proposed by Vitalik, researchers, and core developers.
A Simplified Model of Ethereum Governance: The VVRC Framework
Imagine Ethereum governance as a finely engineered machine, simplified into four key components: Values, Vision, Roadmaps, and Clients—abbreviated as the VVRC model.
-
Values: Everything begins with a shared set of core principles and beliefs within the Ethereum community.
-
Vision: As founder, Vitalik articulates Ethereum’s future vision based on community values.
-
Roadmaps: With a clear vision, research teams develop concrete steps to realize these aspirations, designing technical pathways forward.
-
Clients: Finally, core developers implement the roadmap by writing code and maintaining client software, ensuring all technical plans become reality for users and developers to use.
This process sounds seamless, but reality is messier. For instance, core developers hold de facto final decision power since they control actual software implementation. Vitalik and other researchers mainly offer suggestions, which aren’t always adopted—as shown by the EIP-3074 incident.
Overall, the VVRC model helps us understand how Ethereum ideally advances governance, while reminding us to continuously refine the process to prevent future repeats of the EIP-3074 issue.
How to Improve Ethereum Governance
To optimize Ethereum’s governance structure and avoid repeating the EIP-3074/EIP-7702 episode, here are several improvement suggestions:
Increase EIP transparency: Ensure EIPs under consideration are more openly communicated to the community, avoiding surprises like the sudden acceptance of EIP-3074. Currently, EIP status labels on the EIPs website don’t reflect ACD discussion progress—so even after core developers approve an EIP, it may still show as “Review.” It’s recommended that the Ethereum Foundation use social media platforms to notify the community in advance about EIPs nearing adoption.
Enhance community participation: Designate specific slots during ACD meetings for community members to discuss how EIPs affect downstream projects, preventing unexpected impacts like those EIP-3074 had on the EIP-4337 community. Additionally, if researchers find their input ignored—similar to the EIP-4337 team’s experience—they should invite community members into discussions to strengthen their position.
Mutual understanding and continuous communication: Core developers and researchers must recognize each other as essential governance forces with different emphases. Core developers wield “executive power” through client implementation—akin to having voting rights. Researchers build “roadmap influence” by actively sharing and discussing their roadmaps, gaining broad community support.
When disagreements arise, core developers may tend to override researchers’ ideas—as they did with the EIP-4337 team. But this risks backlash, as power imbalances disrupt stability—the chaos following EIP-3074’s approval is a prime example.
Conversely, when researchers face resistance, they may disengage from core developers—partly why the RIP (Rollup Improvement Proposal) process emerged and why native account abstraction (EIP-7560) advanced primarily as RIPs rather than EIPs.
While RIPs help L2s experiment with protocol upgrades difficult to adopt directly on L1, they cannot replace engagement in the EIP governance process. Researchers must persist in communicating with core developers until roadmaps achieve consensus.
These measures can enhance governance transparency, boost community involvement, and foster effective collaboration between core developers and researchers, reducing potential governance issues in the future.
Conclusion
The Ethereum EIP-3074/EIP-7702 incident reveals the complexity of its governance structure: beyond the formal governance process (driven by core developers through EIPs and ACD proposals), informal roadmaps proposed by researchers also wield significant influence. When these two forces are misaligned, decision deadlocks or abrupt shifts may occur—making Vitalik’s role particularly crucial. He can coordinate各方 based on his grasp of Ethereum’s vision, acting much like a project’s spiritual leader.
We simplify Ethereum governance into a model: Community Values → Vitalik’s Vision → Research Team Roadmaps → Core Developer Implementation (VVRC model). This chain illustrates how decisions evolve from broad ideals to concrete technical implementations.
To improve governance efficiency, we must correct practical deviations from this ideal model. After all, sound Ethereum governance is the core mechanism driving the project forward. The EIP-3074 incident, as a case study, exposes weaknesses in governance, offering valuable lessons and opportunities for improvement—ensuring we’re better equipped to handle similar challenges ahead and promote Ethereum’s sustained, healthy development.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@imTokenOfficial
