On Vitalik and the Impact of Various Roadmaps on Ethereum's Governance Process
TechFlow Selected TechFlow Selected
On Vitalik and the Impact of Various Roadmaps on Ethereum's Governance Process
The technical roadmap is the overlooked core force in Ethereum governance, and Vitalik's role more closely aligns with that of a CTO.
Navigating Web3 tides with focused insightsAuthor: Derek Chiang, CEO of ZeroDev
Translation: Faust, Geeker Web3
Abstract: This article presents the views of Derek Chiang, CEO of ZeroDev, following Vitalik Buterin's proposal of EIP-7702 to reconcile the conflict between ERC-4337 and EIP-3074. Drawing from his firsthand experience as a founder within the account abstraction (AA) ecosystem, the author objectively highlights current governance challenges in Ethereum, sharply pointing out one key issue:
One of Ethereum’s governance tensions lies in the divergence between the roadmap defined by researchers and the perspectives of client development teams like Geth, with Vitalik Buterin acting as the final decision-maker—akin to a CTO.
After affirming Vitalik's pivotal role, Derek outlines how Ethereum could improve its governance model—an analysis valuable not only for the Ethereum community but also for Bitcoin and other decentralized networks.
Main Text: A quick recap if you're unfamiliar with recent Ethereum AA (account abstraction) developments:
A few weeks ago, EIP-3074 was approved by Ethereum core developers for inclusion in the upcoming hard fork “Pectra.” The proposal introduces two new opcodes to the EVM, enabling Ethereum’s externally owned accounts (EOAs) to enjoy near-native account abstraction experiences.
Since then, many in the ERC-4337 community—especially the original proposers—have strongly opposed EIP-3074, citing security risks and incompatibility with Ethereum’s established AA roadmap, which clearly centers on ERC-4337 and similar proposals such as 7560 (also known as “nativeAA”).
In early May, Vitalik proposed EIP-7702 as an alternative to EIP-3074, striking a balance between the two: offering AA-like functionality for EOAs while being more compatible with ERC-4337 and aligned with the long-term “final solution” 7560.
Currently, core Ethereum developers are reviewing EIP-7702, and preliminary discussions and community sentiment suggest that EIP-7702 is likely to replace EIP-3074.
Personally, I’m very satisfied with this outcome: EOA users will soon be able to access products built in the ERC-4337 ecosystem and enjoy most of the benefits of account abstraction. However, I can’t help but feel we could have reached this result through a better process. Many have pointed this out over the past few weeks. I believe a more effective governance process could have saved significant effort and accelerated progress toward the desired outcome.
In this article, I aim to:
-
Identify what went wrong in the governance process
-
Propose a mental model for understanding Ethereum governance
-
Suggest improvements to prevent similar governance incidents in the future
Summary and Reflection on the EIP-3074 Incident
The narrative described above has left many frustrated, for the following reasons:
EIP-3074 took years to gain approval. Only after 3074 was finally approved did core developers face strong opposition from the 4337 community.
On the other hand, the authors of ERC-4337 repeatedly expressed their concerns about EIP-3074 to the Ethereum core team, but were ignored. Now, Ethereum is planning to reverse the approval of 3074 and replace it with another EIP—7702.
None of these steps are inherently flawed:
-
Discussions around an EIP taking years are normal.
-
An EIP being rejected after approval is acceptable.
-
Approvals can be revoked post-facto if new issues emerge.
However, this could have been resolved more smoothly. Let’s imagine an alternate scenario:
During discussions on 3074, the 4337 community actively engaged with Ethereum core developers. Under this assumption, two outcomes could follow:
-
3074 is approved (possibly revised) after considering feedback from the 4337 community. In this case, the 4337 community accepts 3074, and core developers avoid reversing course.
-
Alternatively, 3074 is never approved, but instead the 4337 community and core team jointly develop a satisfactory alternative—just like EIP-7702.
Everyone’s voice would be heard, and there would be no dramatic reversal. That would have been ideal—so why didn’t it happen?
Where Did Things Go Wrong?
Looking back, both sides blame each other.
Core Ethereum developers (and EIP-3074 authors) argue this is the fault of “ERC-4337 supporters” for failing to participate in All Core Devs (ACD) meetings, where EIPs undergo lengthy review before being accepted and implemented by client teams like Geth.
Critics note that during 3074’s review period, 4337 supporters could have joined ACD discussions and voiced concerns earlier, rather than waiting until after approval to object. After all, ACD meetings are public, well-documented, and summarized regularly by contributors like Tim Beiko. So if 4337 advocates cared so deeply, why weren’t they actively involved?
Conversely, core members of the 4337 team insist they attended ACD meetings and tried to oppose 3074, but were ignored. Many in the broader 4337 community were caught off guard—some thought 3074 had already died, unaware it was nearing approval.
Many point out that the entire ACD process lacks transparency, making it difficult for diligent community members who aren’t constantly tracking updates. Some argue that ACD should proactively solicit input from stakeholders—in this case, the 4337 community.
Yet, I believe both sides miss the deeper issue. There’s a more fundamental problem at play. Unless we acknowledge or resolve it, we’ll keep falling into governance crises followed by mutual blame—with little productive outcome.
Root Cause of Governance Incidents: The Roadmap
Contrary to popular belief, the root of this governance failure is not that ACD is the sole source of protocol governance authority. Instead, it has been supplanted by another, less visible form of authority. The real issue is that this alternative power exerts greater influence over core Ethereum matters (like AA and scalability) than ACD itself—yet remains largely unacknowledged.
In this article, I refer to this force as “the roadmap.”
The entire ‘3074-4337-7702’ governance breakdown is a case where the power of the established roadmap overpowered ACD decisions. When we discuss governance, we must be alarmed when an invisible force overrides a visible one—because invisible forces are hard to explain and often go unnoticed. They must be exposed.
What Is the Roadmap?
Anyone in the Ethereum community has likely encountered the term “roadmap”—e.g., “rollup-centric roadmap,” “ETH2.0 roadmap,” or, relevant here, the “AA roadmap.”
To illustrate my point, imagine a scene in an ACD meeting where core developers are debating Ethereum scaling:
-
Core developer Bob: I support EIP-1234, which proposes increasing block frequency tenfold, expanding block size tenfold, and reducing fees hundredfold.
-
Other core devs: …Are you crazy?
Let’s pause. Why would Ethereum core devs reject Bob’s idea? It seems like a reasonable scaling approach—one adopted by chains like Solana, Aptos, and Sui, achieving high TPS.
The reason is that this hypothetical EIP-1234 violates Ethereum’s “rollup-centric” scaling roadmap, which emphasizes that low-cost node operation for ordinary users is essential for decentralization. Thus, EIP-1234 would drastically increase node operation costs and therefore cannot be accepted.
This example illustrates that core developers participating in ACD governance are guided by a higher-level force—the “roadmap.” Today, Ethereum’s overall direction is shaped by roadmaps for scaling, AA, MEV, etc. These collectively inform core developers’ decisions.
When Core Developer Views Clash with the Roadmap
Because the roadmap is not a formal part of Ethereum’s governance process, there’s no guarantee core teams will adhere to it. Nor is there a formal “approval” mechanism for roadmaps, so not all roadmaps carry equal legitimacy. Researchers behind Ethereum roadmaps must actively promote them to gain acceptance among core developers and the community, thereby securing legitimacy and support.
Regarding AA, Vitalik himself has repeatedly advocated for a 4337-centered AA roadmap, though much of the advocacy has come from the 4337 team, especially Yoav and Dror, through forum posts and ACD presentations.
Despite these efforts, some core developers still strongly oppose the 4337-centered AA roadmap. They view 7560 (the native version of 4337 planned for client implementation) as overly complex and not the only viable “endgame” for AA. Ultimately, ACD decided to approve EIP-3074, despite opposition from the 4337 team, who feared it would fragment the AA ecosystem.
After 3074’s approval, the 4337 community reacted strongly, forcing core developers to reopen discussions. Talks stalled, with neither side convincing the other, until Vitalik stepped in at the last minute with EIP-7702—a compromise explicitly compatible with the 4337-centered “AA endgame,” resolving the conflict and aligning the outcome with the AA roadmap.
Vitalik’s Role: Ethereum’s De Facto CTO
Though Vitalik identifies as a researcher, the story above clearly shows he holds unique governance power distinct from other researchers. So the question arises: What role does Vitalik play in Ethereum governance?
In my view, seeing Vitalik as the CTO of a very large company isn’t far-fetched (assuming, for accuracy, that Ethereum “has no CEO”).
If you’ve worked at a tech company with over 50 employees, you know a CTO can’t make every technical decision. As organizations scale, decision-making becomes decentralized—each domain typically managed by a dedicated team free to decide implementation details.
Moreover, a CTO isn’t necessarily the top expert in every (or any) area. Engineers may surpass the CTO in specific domains, so detailed technical decisions are usually made by specialists.
However, the CTO sets the company’s technical vision. Execution is delegated to engineers.
While imperfect, this analogy reasonably captures Vitalik’s role in Ethereum. He doesn’t—and can’t—participate in every technical decision. He isn’t the top expert in every field. But he exerts overwhelming influence over roadmaps for key initiatives (scaling, AA, PoS, etc.), not just due to technical expertise, but because he is the ultimate arbiter of whether a roadmap aligns with Ethereum’s vision—his vision.
Every Successful Product Starts with a Vision
If calling Vitalik Ethereum’s CTO wasn’t controversial enough, here’s the most contentious claim: We should embrace Vitalik as CTO.
As a startup founder, I believe every successful product requires a coherent long-term vision—yes, even Ethereum, which solves real problems for real users. Such coherence must be driven by a small group, often a single founder.
The beauty of Ethereum lies in how its many complex components seamlessly integrate into a robust, decentralized computer settling billions in transactions daily.
We didn’t get here through committee design. It was Vitalik’s visionary leadership that enabled us to build today’s cohesive and elegant Ethereum. Ethereum began as Vitalik’s 2015 idea—and remains so.
Of course, this doesn’t diminish the contributions of other researchers and engineers who executed much of the work. But it’s consistent: Ethereum is the realization of Vitalik’s vision—orders of magnitude larger than anyone else’s.
Honestly, do you really complain? When drawn to Ethereum’s openness, censorship resistance, and innovation speed, do you resent that it stems from Vitalik’s vision? Maybe you don’t—it might not have occurred to you. But now it has. Do you actually mind?
What About Decentralization?
But wait—you’ll say—what about decentralization? If one person holds such overwhelming power, how can Ethereum be decentralized?
To answer, we must recall Vitalik’s classic essay on decentralization, which identifies three types:
-
Architectural decentralization: How many nodes must fail before the system stops functioning?
-
Logical decentralization: Can subsystems evolve independently while maintaining system integrity, or must they coordinate tightly?
-
Political decentralization: How many individuals or organizations control the system?
By these definitions, Ethereum is clearly architecturally decentralized, and arguably logically decentralized due to loose coupling between components (e.g., consensus and execution layers).
Politically, the good news is no individual or organization can shut down Ethereum—not even Vitalik. Yet, one might argue Ethereum’s political decentralization is lower than assumed, given Vitalik’s dominant role in shaping its vision and roadmap.
Still, I believe we must accept Vitalik as de facto CTO if Ethereum is to keep innovating—even if it means sacrificing some political decentralization.
If Ethereum ever becomes as rigid as Bitcoin—nearly immutable—then perhaps Vitalik can retire. But until then, it’s crucial to have a respected authority trusted to judge technical decisions not only by technical merit but by alignment with Ethereum’s vision.
Without someone like Vitalik, only two outcomes are possible, vividly illustrated by the 3074 saga:
-
Ethereum governance could stall in endless deadlock, with opposing sides refusing to compromise and no one able to move forward—as seen in the 3074 debate before Vitalik intervened.
-
Or, Ethereum could become a disjointed “Frankenstein”—a patchwork monster stitched together from incompatible parts. As previously noted, 3074 and 4337 might coexist irreconcilably, splitting the AA ecosystem into two incompatible parallel worlds.
The Role of the Community
With these reflections, we’re close to a complete mental model of Ethereum governance—but one critical piece has been missing: the community.
If Vitalik defines the vision, researchers define the roadmap, and core developers implement it, what role remains for the community? Surely not nothing?
Fortunately, the community plays the most vital role. Because before vision comes values. We gather as a community around shared principles, and Vitalik’s vision must ultimately align with these values—or risk losing community support.
Everyone in the Ethereum community believes a globally accessible, censorship-resistant, trust-minimized decentralized computer benefits the world. Every day, through our work on Ethereum, we uphold these values—thereby granting legitimacy to the visions, roadmaps, and code crafted by Vitalik, researchers, and core developers.
The VVRC Model of Ethereum Governance
Thus, here is a complete mental model of Ethereum governance: Values → Vision → Roadmap → Client, or VVRC for short:
-
V == Values == Community;
-
V == Vision == Vitalik;
-
R == Roadmap == Researchers;
-
C == Client == Core Developers;
Together, they function as follows:
-
The community unites around shared values.
-
Vitalik articulates a vision aligned with those values.
-
Researchers formulate roadmaps based on the vision.
-
Core developers implement clients according to the roadmap.
Of course, reality is more complex than any simple model. Indeed, core developers are the only ones who can truly “vote” on proposals via client code changes. Vitalik and other researchers serve advisory roles, and their opinions are sometimes rejected by core developers—exactly why EIP-3074 was approved.
That said, I believe the VVRC model reasonably captures how Ethereum governance typically operates, and we need to “debug” this process to prevent future incidents like EIP-3074.
Improving Ethereum’s Governance Model
Now that we have a mental model of how Ethereum governance works, here are several ideas for improvement.
-
EIP discussion progress must be made more visible. The community should never be “surprised” by an EIP’s acceptance. Approvals like 3074 should no longer catch people off guard.
Currently, EIP statuses on the official website don’t reflect their actual stage in the ACD process. That’s why 3074 still shows as “Review,” even though core developers have already voted to approve it, with no indication it was ever under active consideration.
Ideally, the Ethereum Foundation should issue clear public announcements on social media when an EIP is nearing acceptance, to raise community awareness.
-
Sometimes core developers underestimate an EIP’s downstream impact on projects and users—exactly what happened with 3074 and the 4337 community. Given limited ACD meeting time and cross-timezone coordination, only “involved parties” typically speak.
Occasionally allocating speaking time for community members to comment on potential downstream impacts of certain EIPs would be valuable.
If researchers feel their input is ignored by core developers—as in the 4337 case—they could mobilize community members to amplify their position.
-
Crucially, core developers and researchers must mutually recognize that, despite differing powers, both are integral parts of Ethereum governance. Core developers hold the exclusive right to modify and update clients—the only way to “vote” via protocol changes. Researchers wield influence through public support gained by actively discussing and writing about their ideas.
When these two powers clash, core developers may tend to override researcher input, as seen when they dismissed 4337 team objections. Yet such overrides can trigger conflict, destabilizing the ecosystem—as shown by the drama following 3074’s approval.
Likewise, when facing resistance, researchers may withdraw from collaboration with core developers. In my view, this partly explains the creation of the RIP (Research & Implementation Proposal) process and why native AA (7560) is now promoted mainly as a RIP rather than an EIP.
While testing controversial L1 upgrades on L2s has merits, RIPs cannot replace participation in the EIP governance process. Researchers must continue collaborating with core developers until their visions fully align with the roadmap.
Conclusion
The 3074/7702 episode reveals how Ethereum governance truly operates: beyond the explicit governance power of EIPs and ACD processes led by core developers, there’s an implicit power held by researchers through roadmaps. When these powers misalign, we see deadlock and backlash—sometimes requiring a third force—Vitalik—to restore balance.
We then argued Vitalik represents a unique force—the “vision” of Ethereum, which serves as the foundation of any roadmap’s legitimacy. Comparing him to a corporate CTO, we acknowledged his quasi-CTO role is necessary for Ethereum to maintain its innovation pace and avoid devolving into a “Frankenstein” of mismatched parts.
Finally, we proposed the VVRC model to describe Ethereum governance: Values (Community) → Vision (Vitalik) → Roadmap (Researchers) → Client (Core Developers). We then suggested ways to fix flaws in this model.
Ethereum governance is the “machine that builds the machine.” For Ethereum to function properly, its governance must be sound. The 3074 incident offers a valuable case study. I hope the Ethereum community learns useful lessons to improve future governance processes.
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
@godrealmx
