Who Is the EF Supporting? Polygon’s Sandeep Nailwal and Sonic’s Andre Cronje Reopen Ethereum’s Support-and-Funding Debate

The spark: A previously circulated letter from core developer Péter Szilágyi (longtime Geth maintainer) resurfaced with concerns about pay, staffing, and decision-making. Within the same news cycle, Sandeep Nailwal (Polygon) and Andre Cronje (Sonic; previously Fantom) offered pointed commentary about whether the Ethereum Foundation (EF) meaningfully backs the teams who translate research into user-facing activity. The result is a familiar but newly urgent debate: what should a neutral public-goods steward fund, endorse, or coordinate in a world where most usage now flows through Layer-2s?

The issue behind the headlines

Ethereum’s narrative has always balanced two poles. On one side are public goods—clients, research, security, and standards. On the other are the user rails—L2s, wallets, bridges, indexing, and tooling that let ordinary people transact cheaply and reliably. The EF has historically prioritized the first pole: client diversity, formal verification, ZK research, Devcon-style education, grants for protocol R&D. Builders like Nailwal and Cronje argue the second pole now needs more visible, structured support, because that is where adoption actually happens. When outages hit RPCs, when client regressions ripple into sequencers, or when cross-tooling breaks in production, it is L2s and app teams who carry the on-call pager. The question is not whether the EF cares; it is whether the existing mandate and processes map to 2025’s reality.

What the critics are really asking for

• Predictable lanes for money: Clear grant tracks for client maintenance, cross-L2 reliability work, incident-response capacity, and shared observability. Builders want to know which requests fit the EF’s remit, how decisions are made, and what reporting is expected.

• Transparent compensation scaffolding: Public reference ranges for long-term maintainers and security roles reduce churn, rumor cycles, and the need for back-channel negotiation.

• Operational collaboration without picking token winners: Joint testbeds, fault-proof drills, data-availability stress tests, and cross-vendor reliability programs that include the largest L2s yet remain vendor-neutral and open source.

• On-record recognition: When teams ship hard, measurable wins—client performance, new proving systems, onboarding breakthroughs—neutral praise from EF leadership boosts morale and signals what the ecosystem values.

The EF’s historical stance—and its constraints

The EF was designed to be a steward, not a corporate HQ. It funds public goods, avoids anointing commercial winners, and deliberately keeps a small surface area to minimize capture. Those constraints matter: too much centralization risks political fights over budget and favoritism; too little coordination leaves reliability gaps unowned. In past cycles that trade-off felt acceptable because most usage lived on L1 and research pipelines were the bottleneck. In 2025, the bottlenecks look different: user experience, cross-L2 consistency, and production-grade reliability now decide whether the next hundred million people stick around.

A constructive middle path

1. Codify four funding tracks: (1) Core clients and protocol security; (2) Cross-L2 reliability and observability; (3) Public documentation and standards; (4) Education and onboarding. Each track gets published intake criteria, timelines, review panels, and example deliverables.

2. Stand up a neutrality-preserving reliability program: EF convenes a rotating group of L2s, wallets, and infra providers to run quarterly game-days: sequencer failover drills, DA congestion scenarios, cross-client regression hunts. All artifacts are open, and no token is endorsed.

3. Publish a maintainer 'career lattice': Define roles, expectations, and representative compensation for maintainers, release managers, fuzzing engineers, and incident responders. This framework can live alongside Protocol Guild donations without replacing them.

4. Create incident playbooks and a common language: Require standardized post-mortems for high-impact incidents (SLOs breached, user impact, time to mitigation, action items). Normalize shared telemetry formats so tools interoperate by default.

Why this debate keeps returning

Open-source movements thrive on pluralism and suffer when credit becomes opaque. L2s ship user-visible wins, but their incentives can diverge. Research teams push the frontier, but their output is often invisible to end users. When markets turn choppy or outages stack up, frustration flows toward whoever is perceived as holding the purse or the microphone. Without explicit lanes for money, maintenance, and recognition, the same cycle repeats: a flare-up on social media, a few clarifying posts, and then silence until the next incident.

What builders can do today

• Be precise with asks: Submit reproducible issues, benchmarks, perf traces, and budgets. 'Fix performance' is vague; 'remove X% of allocations in module Y with PR Z and a three-month maintenance budget' is fundable.

• Contribute upstream even when it hurts: Fixing bugs in clients, provers, or standards costs time but reduces total toil for everyone—including your own team—over the next year.

• Standardize signals with peers: Share dashboards and incident formats across L2s and wallet vendors. Reliability becomes a shared language rather than a brand exercise.

• Document SLOs: Publish service-level objectives for your sequencer, bridge, or indexer. Clear commitments are the basis for cooperative improvement.

What the EF could publish in the next quarter

• Grants rubric: A short document that spells out 'in-scope vs. out-of-scope' with example proposals and acceptance criteria.
• Quarterly maintainer report: Aggregate the number of active maintainers across clients, releases cut, critical CVEs patched, and hours invested in incident response.
• Reliability scorecard: Vendor-neutral metrics: mean time to detection, to mitigation, and to resolution for cross-ecosystem incidents; coverage of chaos tests; rehearsal frequency.
• Recognition framework: A neutral way to highlight teams that deliver public goods, whether or not they run a token.

Risks of doing nothing

If the ecosystem treats reliability and compensation as 'someone else’s problem,' three risks compound. First, maintainer attrition—experienced engineers drift to better-funded verticals. Second, coordination debt—incidents repeat because no shared practice emerges. Third, narrative drift—talented founders conclude their effort is undervalued and move to stacks where operational collaboration is explicit. None of these outcomes require malice; they are the default when incentives are underspecified.

Counterarguments worth addressing

• 'Endorsing L2s breaks neutrality.' Coordinating reliability standards and incident hygiene does not pick business winners; it picks good engineering. The work can be public, open-licensed, and vendor-agnostic.

• 'Comp bands turn EF into a corporation.' Publishing representative ranges for public-goods roles is not corporate bloat; it is an anti-opacity measure that helps retain critical talent.

• 'The market should fund edges.' Markets underfund non-rival, non-excludable goods. Clients, testing infra, and incident tooling are precisely the domains where philanthropy and neutral stewardship shine.

Six- to twelve-month scenarios

1. Best case—structured collaboration: EF codifies funding tracks, launches a reliability program, and publishes maintainer data. L2s participate without brand theatrics. Outage quality improves; social flare-ups recede.
2. Middle path—incremental progress: Ad-hoc grants and occasional joint drills happen, but documentation lags. Tension surfaces intermittently, yet user-visible reliability inches forward.
3. Worst case—coordination stall: No clear lanes, rising maintainer churn, repeated incidents with minimal shared learning. Builders redirect energy to stacks with crisper operational compacts.

Practical KPIs that would show progress

• Client health: Releases per quarter, time-to-fix for critical bugs, and cross-client parity on major features.
• Reliability drills: Number of cross-org game-days executed, issues discovered, and fixes shipped to production within a quarter.
• Maintainer stability: Net change in senior maintainers and mean tenure by role.
• Incident hygiene: Percentage of P1 incidents with public post-mortems and tracked action items closed within 60 days.

FAQ

Bottom line

This is not a 'EF vs. builders' standoff; it is a coordination problem. The ecosystem can keep neutrality while getting serious about the user layer. Publish clear lanes for funding, articulate compensation for public-goods roles, run vendor-neutral reliability programs, and celebrate verifiable wins. Do those four things, and the recurring 'Who is the EF supporting?' thread fades into the background while users, developers, and maintainers focus on the work that keeps Ethereum resilient.

Editorial note: This analysis synthesizes public commentary and long-running community discussions. It is not investment advice and does not represent any project’s official view.

Further Reading and Resources

Altcoin Analysis | Exchanges | Apps & Wallets