Repository: ethereum/EIPs
Pull request #9704: Add EIP: Ethereum Shah
Author: login: ameensol
Labels: name: c-new
description: Creates a brand new proposal
name: t-informational
name: e-review
description: Waiting on editor to review
name: s-draft
description: This EIP is a Draft
name: e-consensus
description: Waiting on editor consensus
Created: 2025-04-28T19:59:08Z | Merged: 2025-04-30T19:36:22Z

**ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN [ETHEREUM/ERCS](https://github.com/ethereum/ercs)**

--

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.



Diff:
diff --git a/EIPS/eip-7940.md b/EIPS/eip-7940.md
new file mode 100644
index 00000000000000..fc1e96f8d1413e
--- /dev/null
+++ b/EIPS/eip-7940.md
@@ -0,0 +1,115 @@
+---
+eip: 7940
+title: Ethereum Shah
+description: Proposal to elect an Ethereum Shah who will act as a "protector" for the core devs and the Ethereum protocol.
+author: Ameen Soleimani (@ameensol), Gregory Markou
+discussions-to: https://ethereum-magicians.org/t/discussion-for-eip-ethereum-shah/23909
+status: Draft
+type: Informational
+created: 2025-04-28
+---
+
+## Abstract
+
+Ethereum needs a Shah. The role of the Shah is to be the "protector". A Shah, empowered by the community and with a mandate to represent their interests, could solve the communication gaps between the Ethereum community and core devs, represent the interests of the Ethereum community (holders, stakers, app devs & businesses especially) to the core devs with a tighter feedback loop, and eventually dissolve their position when the imminent danger of Ethereum coordination failure is meaningfully addressed.
+
+## Motivation
+
+It is clear from recent events that Ethereum is suffering from a coordination breakdown between the user ecosystem and the core devs. A case in point is the EOF debacle, with years wasted in EOF development that ~~seems ultimately likely to be~~ was just rejected as a result of 1) fragmented communication between researchers/core devs and the greater Ethereum ecosystem, to the extent that even tentative supporters of EOF weren't aware of the toolchain update requirements on the rest of the ecosystem as well as 2) a lack of rigorous compatibility testing such that EOF exposes protocol level risks. 
+
+A Shah is of course centralized, but we've seen the decentralized alternative: First a tacit acceptance of a seemingly unnecessary EIP involving years of labor, approved by committee, and ultimately rejected by the Ethereum community. The costs on our collective time are large, not to mention the opportunity cost. 
+
+Ethereum could spare itself these innefficiencies by electing a Shah to manage the core dev roadmap and EIPs.
+
+## Specification
+
+The Shah SHOULD be elected by the Ethereum community, using a combination of ETH voting, social signalling, and core dev ratification.
+
+The Shah SHOULD be singularly responsible for deciding on the EIP inclusion roadmap, as well as having veto power over which EIPs to include.
+
+The Shah SHOULD maintain communication channels with the Ethereum community (holders, stakers, app devs & businesses) to understand their needs & request feedback on EIPs.
+
+The Shah SHOULD play a coordinator role in the All Core Devs (ACD) calls, and submit a quarterly progress update to Ethereum stakeholders.
+
+The Shah SHOULD NOT have any special privileges, for example: to relieve developers of duty at organizations not under the Shah's control.
+
+The Shah SHOULD explicitely call out blockers, communications breakdowns, and when deserving, the core devs that get in the way of addressing them.
+
+The Shah SHOULD NOT report to the Ethereum Foundation. The Shah's position would be paid directly from the most credibly "Ethereum" source of funding, which has received its budget from a diverse set of Ethereum community members: The Protocol Guild. 
+
+The Shah SHOULD have an expiration date for their role set at the time of election, that does exceed 2 years.
+
+The Shah SHOULD be able to step down willingly before the end of their 2 year term. 
+
+***
+
+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 and RFC 8174.
+
+## Rationale
+
+During times of war, the Roman Senate would elect an "Imperator" that would be responsible for dealing with an imminent threat, and once the threat was dealt with, would abdicate their power. The Shah is a similar concept, but rooted in the culture of the Persian Empire, which pioneered a "pluralistic" multi-national empire that respected cultural and religious diversity of its member nations—as aligned with Ethereum's culture of plurlism today.
+
+This EIP is largely inspired by Greg the Greek's post (below) about the EF core devs lacking strong leadership who can take responsibility for saying "NO" to EIPs that they expect will ultimately be defeated by community consensus, and thus saving everyone their time, effort, and mental health. The Greeks pioneered democracy—if the will of the people is to elect (even for a limited time) a strong leader, would it not be undemocratic to deny it?
+
+Link: x (dot) com/gregthegreek/status/1914811701901623746
+
+> All Core Devs need to centralize.
+> They need a leader who will say, NO.
+> They need to be told what not to do.
+> They need someone to shield them.
+>
+> ![Figure 1](../assets/eip-7940/acd_leader.jpeg)
+> 
+> Story Time
+> 
+> I vividly remember hearing about EOF 4-5 years ago
+> 
+> I asked a simple question:
+> Q: How does this benefit users interacting with the chain?
+> A: It allows future implementations of the EVM to add those things!
+> 
+> 👎
+> 
+> Cold, hard truth. Engineers are trying to solve a problem because it's fun, not because it's needed. It has some long-tail benefits, but not enough to justify the pain that it will cause.
+> 
+> This is a full-blown toolchain update (almost). We need to prioritize things that provide incremental wins. If the team behind EOF had spent more time improving the EVM in incremental steps (ditching EOF altogether), they could have shipped so much more, which could have, in aggregate, contributed to a 10x improvement.
+> 
+> Instead, they continue to fight for a proposal that was shot down ~3 times?
+> 
+> What has EOF done?
+> 
+> - Distracted ACD for the 4th time
+> - Delaying roadmap by jamming a MASSIVE change into core code
+> - Distract @ethPandaOps who will inevitably be responsible for creating an ungodly testing framework for this change
+> - Caused ProgPow level wars because they can't take "no" for an answer
+> 
+> ONE YEAR AGO in Brussels, I asked Marius "How's work?" and he responded:
+> > The EOF folks are back, the proposal is bigger than before.
+> 
+> ONE YEAR AGO - does no one see the problem here?
+> 
+> @tkstanczak @hwwonx This is the hardest role to hire for, but it needs to be done. That or one of you will need to step up and actually own this. It's clear @VitalikButerin, and we shouldn't force him to, he's better on the research side. Someone needs to run DAY-To-DAY ops/product on ACD.
+> 
+> It's exhausting. 
+> Let the devs ship.
+> Stop the politics.
+> Turn the ship around.
+> 
+> Please 💕
+
+The role of the Shah would be primarily social, and they would not have any *formal* power. Their power solely comes from the belief that the community has in their power. In the context of steering the ACD calls & EIP inclusion roadmap, this is actually enough. In my personal experience helping kill ProgPow, the core devs were not convinced that I adequately represented enough of the Ethereum community (despite my position as the Summoner of MolochDAO) and it took Martin Koeppelman & several others to step forward to socially signal against ProgPow and ultimately join the ACD meeting to advocate against it in order to finally convince the core devs that ProgPow was against the interest of the greater Ethereum community. The role of the Shah can help short-circuit this suspicion from the core devs by having the default understanding be that the Shah does in fact represent the will of the greater Ethereum community.
+
+In his post a few weeks ago, Tim Beiko (the current Ethereum Hard Fork Coordinator) also suggested that the ACD was missing the roadmapping role this EIP proposes to be coordinated by the Shah.
+
+> **Roadmap Setting**
+The most important missing piece in the current AllCoreDevs process is a focus on the high level roadmap (“why we do things”), rather than individual proposals (“what we do”). This is true both for when planning the next fork(s), but also when thinking about Ethereum’s longer-term direction.
+
+Link: ethereum-magicians (dot) org/t/reconfiguring-allcoredevs/23370
+
+## Security Considerations
+
+The obvious risk of having a Shah is that they could veto EIPs that *are* actually aligned with the Ethereum community stakeholders or prioritize EIPs that are not. In this case, it is the role of the community to publicly dissent from the Shah and ultimately remove them from office. I would expect that long before the Shah was officially deposed, the all core devs would start ignoring the Shah's input anyway, as the position does not hold any formal power. I think a fair mimimum term would be 6 months (for there to be two quarterly reports at least) and with at least the same degree of community consensus around deposing the Shah as there was to enshrine them in the first place.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
diff --git a/assets/eip-7940/acd_leader.jpeg b/assets/eip-7940/acd_leader.jpeg
new file mode 100644
index 00000000000000..f16e163e3b2880
Binary files /dev/null and b/assets/eip-7940/acd_leader.jpeg differ


Reviews:
user: login: eth-bot
body: All Reviewers Have Approved; Performing Automatic Merge...
state: DISMISSED
author_association: COLLABORATOR
submitted_at: 2025-04-28T19:59:56Z
user: login: eth-bot
body: All Reviewers Have Approved; Performing Automatic Merge...
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-28T20:02:50Z
user: login: eth-bot
body: All Reviewers Have Approved; Performing Automatic Merge...
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-28T20:03:00Z
user: login: lightclient
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-04-28T22:38:51Z
user: login: eth-bot
body: All Reviewers Have Approved; Performing Automatic Merge...
state: DISMISSED
author_association: COLLABORATOR
submitted_at: 2025-04-28T22:39:40Z
user: login: eth-bot
body: All Reviewers Have Approved; Performing Automatic Merge...
state: DISMISSED
author_association: COLLABORATOR
submitted_at: 2025-04-29T15:47:10Z
user: login: wjmelements
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-30T04:40:41Z
user: login: lightclient
state: APPROVED
author_association: MEMBER
submitted_at: 2025-04-30T19:35:33Z
user: login: eth-bot
body: All Reviewers Have Approved; Performing Automatic Merge...
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-30T19:36:21Z

Review comments:
diff_hunk: @@ -0,0 +1,115 @@
+---
path: EIPS/eip-new
user: login: lightclient
body: eip: 7940
created_at: 2025-04-28T22:38:51Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,115 @@
+---
+eip: 7940
+title: Ethereum Shah
+description: Proposal to elect an Ethereum Shah who will act as a "protector" for the core devs and the Ethereum protocol.
+author: Ameen Soleimani (@ameensol), Gregory Markou
+discussions-to: https://ethereum-magicians.org/t/discussion-for-eip-ethereum-shah/23909
+status: Draft
+type: Informational
+created: 2025-04-28
+---
+
+## Abstract
+
+Ethereum needs a Shah. The role of the Shah is to be the "protector". A Shah, empowered by the community and with a mandate to represent their interests, could solve the communication gaps between the Ethereum community and core devs, represent the interests of the Ethereum community (holders, stakers, app devs & businesses especially) to the core devs with a tighter feedback loop, and eventually dissolve their position when the imminent danger of Ethereum coordination failure is meaningfully addressed.
+
+## Motivation
+
+It is clear from recent events that Ethereum is suffering from a coordination breakdown between the user ecosystem and the core devs. A case in point is the EOF debacle, with years wasted in EOF development that ~~seems ultimately likely to be~~ was just rejected as a result of 1) fragmented communication between researchers/core devs and the greater Ethereum ecosystem, to the extent that even tentative supporters of EOF weren't aware of the toolchain update requirements on the rest of the ecosystem as well as 2) a lack of rigorous compatibility testing such that EOF exposes protocol level risks. 
+
+A Shah is of course centralized, but we've seen the decentralized alternative: First a tacit acceptance of a seemingly unnecessary EIP involving years of labor, approved by committee, and ultimately rejected by the Ethereum community. The costs on our collective time are large, not to mention the opportunity cost. 
+
+Ethereum could spare itself these innefficiencies by electing a Shah to manage the core dev roadmap and EIPs.
+
+## Specification
+
+The Shah SHOULD be elected by the Ethereum community, using a combination of ETH voting, social signalling, and core dev ratification.
+
+The Shah SHOULD be singularly responsible for deciding on the EIP inclusion roadmap, as well as having veto power over which EIPs to include.
+
+The Shah SHOULD maintain communication channels with the Ethereum community (holders, stakers, app devs & businesses) to understand their needs & request feedback on EIPs.
+
+The Shah SHOULD play a coordinator role in the All Core Devs (ACD) calls, and submit a quarterly progress update to Ethereum stakeholders.
+
+The Shah SHOULD NOT have any special privileges, for example: to relieve developers of duty at organizations not under the Shah's control.
+
+The Shah SHOULD explicitely call out blockers, communications breakdowns, and when deserving, the core devs that get in the way of addressing them.
path: EIPS/eip-7940.md
user: login: wjmelements
body: explicitly
created_at: 2025-04-30T04:40:41Z
author_association: CONTRIBUTOR

PR comments:
user: login: eth-bot
created_at: 2025-04-28T19:59:31Z
body: ✅ All reviewers have approved.
author_association: COLLABORATOR
user: login: potuz
created_at: 2025-04-28T20:05:00Z
body: Too bad github doesn't have :popcorn: and :rofl: as emojis on EIP descriptions. 
author_association: CONTRIBUTOR
user: login: github-actions[bot]
created_at: 2025-04-28T20:14:09Z
body: The commit 5a0038f39d14d8cc7df9472b316d24122a2c5737 (as a parent of 0f5fd24228dcce4ccba5c71a5238e7a4ce591f75) contains errors.
Please inspect the [Run Summary](https://github.com/ethereum/EIPs/pull/9704/files) for details.
<!-- Sticky Pull Request Comment -->
author_association: NONE