Ethereum’s Next Chapter: What ESP’s New RFP & Wishlist Model Says About the Road Ahead

TL;DR: The Ethereum Foundation’s Ecosystem Support Program (ESP) just shifted from an always-open, reactive grants funnel to a proactive, two-track model: an evolving Wishlist (broad priority themes) and time-boxed RFPs (specific, outcome-driven briefs). This tightens alignment with EF priorities, emphasizes verifiable outcomes, and orients funding toward core infrastructure, security, privacy, identity, UX, and community scalability.

What changed (and why it matters)

• From reactive to strategic. ESP paused open applications earlier this year to retool; the relaunch concentrates finite review bandwidth on ecosystem “must-haves,” not just “nice-to-haves.” Expect clearer signals, faster reviews within scoped topics, and less duplication across grants.

• Two clear doors:

  • Wishlist = broad ecosystem gaps (privacy, security, infra, app-layer, community). You propose how to tackle them.

  • RFPs = narrowly defined problems with deliverables, timelines, and measurable success criteria. You execute what’s specified.

• More coordination across EF teams. Expect funding to map tighter to protocol roadmaps, EF working groups (e.g., privacy/identity), and long-lived public goods.

Reading the RFPs: the themes behind the briefs

Below is what the mix of early RFPs suggests about Ethereum’s direction. (The live applicants/Wishlist pages and the launch post confirm the strategy; specific titles you shared align with those lanes.)

1. Hardening the protocol & clients (Security + Automation).
   RFPs using LLMs in protocol security and spec-compliance point to a push for continuous, automated conformance across clients/EIPs: CI hooks, PR bots, diff explainers, and machine-augmented review. This reduces human error and accelerates safe upgrades. Translation: quality-at-scale is now a first-class funding goal.

2. Identity that actually interoperates (did:ethr modernization).
   A dedicated identity RFP signals a desire to re-baseline Ethereum’s DID stack against current W3C/DIF work and L2 realities, with better reference tooling and test coverage. Expect identity to be a utility public good that other layers (credentials, compliance, zk access control) can rely on.

3. Privacy that’s usable and auditable when needed.
   RFPs around privacy disclosure frameworks, federated attestation registries, and cross-protocol privacy relayers suggest a modular privacy stack: users keep confidentiality by default, but opt-in, scoped transparency (view keys/zk attestations) is standardized for auditors/institutions. It’s privacy without isolation, so capital can flow.

4. UX that removes paper seeds (passkeys + smart accounts).
   A passkey-centric RFP in the AA (ERC-4337/7579) world shows EF wants mainstream-grade onboarding without custodial traps: vendor-neutral modules, ejectability, and wallet interoperability. This is how Ethereum makes self-custody feel like Web2 log-in without sacrificing sovereignty. Decentralizing the access layer (RPC, light clients, Portal).
   Grants that push verifiable, censorship-resistant RPC (light clients, P2P routing, Portal Network) are about removing single-provider chokepoints. The default endpoint of the future is provable and plural, not “whoever hosts the free gateway.” This is resilience work, not hype.

5. Truly decentralized frontends.
   A “secure & decentralized frontends” RFP aims for client-side verification, content-addressed distribution, and CDN/DNS independence—with real dapp integrations. Expect wallets/browsers to become distribution/verification surfaces for frontends, not just transaction signers.

6. Scaling community in the physical world (Meetups & Hubs).
   Community Meetups and Community Hubs RFPs extend “Ethereum Everywhere”: recurring in-person touchpoints, open community spaces, and transparent reporting. EF is funding social infrastructure as seriously as code because local density compounds contributors.

Big picture: the strategy in one line

Make Ethereum more verifiable, more private-by-default yet auditable-on-demand, more usable for normal people, and more resilient against centralized choke points while compounding community throughput. The grants machinery now mirrors that strategy.

What this means for builders (how to position your proposal)

• Anchor to a public good with crisp KPIs. Show how your work reduces risk, increases verifiability, or unlocks interoperability used by many. Map outputs to tests, CI hooks, reference libs, or standards drafts.

• Choose the right door:

  • RFP if you can ship scoped deliverables in 3–6 months with integrations (CI action, wallet SDK, spec PRs, demo in a major client/dapp).

  • Wishlist if you’re tackling an EF-prioritized gap with a novel approach. Bring a plan for milestones, adoption, and handoff/maintenance.

• Design for interoperability. Use existing standards (EAS, ERC-4337/7579, W3C DID Core), keep things permissionless and vendor-neutral, and document integration paths. That’s strongly favored.

• Plan the adoption story. Name design partners (wallets, clients, dapps), show how this lands in real PRs/releases, and commit to docs, SDKs, and governance/readiness beyond the grant window.

For investors and ecosystem operators

• Expect defensibility through standards & infra rather than token paywalls: EF-backed work will lower platform risks and raise the bar for compliance-friendly privacy and identity, expanding institutional comfort without centralizing the stack.

• Watch RPC decentralization and verifiable frontends: as these mature, reliance on single vendors drops: improving uptime, neutrality, and jurisdictional resilience for the whole app layer.

Practical next steps

• Browse ESP Applicants/Wishlist to see live themes and RFP windows; subscribe for updates.

• Read the launch post for intent, examples, and expectations around results & coordination.

• If you’re building community programs, look at Ethereum Everywhere touchpoints for alignment and signal.

Bottom line

ESP’s revamp is less about limiting grants and more about aiming them. If you can prove verifiability, interoperability, privacy with accountability, or resilient access and you can land production integrations, this model is designed for you.