The EIP process is rigorous on technical spec, security, and implementation quality. This guide addresses a gap it doesn't cover: helping you validate whether your EIP has real ecosystem demand.
EIPs that need voluntary adoption from wallets, dApps, L2s, and infra providers benefit from early stakeholder engagement. Without it, champions risk reaching CFI on technical merit alone, only to discover that the teams who need to integrate haven't been consulted.
This guide recommends flipping the typical order: gather stakeholder feedback first, shape your research around real needs, then build with committed stakeholders already lined up. The result is an EIP that's harder to argue against at CFI and more likely to see adoption after mainnet.
Not all EIPs relate to market demand the same way. Ask yourself: does my EIP need voluntary adoption to be useful? The answer shapes what kind of evidence will make your case stronger.
Features that only work if wallets, dApps, or infra providers integrate them. Without voluntary adoption, there's no impact.
New primitives where users can't articulate demand yet because the thing doesn't exist. Inclusion is thesis-driven, not evidence-driven.
Changes invisible to end users, or security EIPs driven by external threat models rather than user demand.
This is a self-assessment to help you understand what evidence will strengthen your case. It's not a formal classification or requirement.
If your EIP is Tier A or Tier B, we recommend putting together a short Brief (~1 page) alongside your technical spec when you propose for CFI. It gives ACD participants the information they need to make an informed signal. The EF Protocol Support team can help extend your stakeholder reach once your EIP is CFI'd.
Two to three sentences from the user's perspective, not the protocol's. What can someone do after this EIP ships that they can't do today?
Tier A: documented conversations with 10+ entities. Tier B: a compelling thesis with whatever validation you can gather. See Gathering Stakeholder Evidence below.
Who integrates first? What's the realistic timeline for meaningful adoption after mainnet? (Or for Tier B: what needs to happen for adoption to emerge?)
Talk to at least 10 entities across the value chain — wallets, dApps, L2s, infra providers, protocols — who would need to build on or integrate your EIP. The “saturation point” is when further discussions stop generating new perspectives.
Structure conversations in two parts:
Don't lead with your solution. Start by understanding whether stakeholders actually experience the problem your EIP addresses.
Once you understand the problem from their perspective, present your approach. Don't ask if they like it — ask how they'd use it.
You won't have 10 teams ready to integrate something that doesn't exist yet, and that's fine. Make the case for why this will unlock value, what the adoption path looks like once the primitive exists, and what comparable attempts have been tried elsewhere. Where possible, validate the underlying problem even if the solution is still theoretical.
Every EIP that reaches CFI costs the ecosystem real resources: client team engineering hours, devnet infrastructure, tooling updates, and stakeholder integration work. Doing the demand work upfront is cheaper than finding out nobody wanted it after mainnet.
It's a one-page document, not a committee. You submit it alongside your spec. If anything, it saves time by surfacing adoption problems early instead of after months of implementation.
That's worth knowing before you invest months in implementation. It might mean your EIP is Tier B and the brief should reflect that. Or it might mean the EIP solves a problem nobody has.
Sentiment is useful context, but it's not the same as a wallet team telling you they'd integrate. The brief asks for evidence of real conversations with real teams, not engagement metrics.