The Ethereum Foundation’s Funding Coordination team (Martin Hansen, Sophia Sukhinina, Devansh Mehta) used ETHPrague 2026 to publish three coordinated frameworks for Ethereum’s funding sustainability: the Ethereum Kernel (Hansen) — a $18M/year minimum-viable funding target for the protocol’s critical functions; Dependency-Aware Funding (Sukhinina) — a research thesis backed by the EU Cyber Resilience Act that the next wave of public-goods funding must follow SBOM dependency graphs; and Sourcing Funding for Ethereum Growth (Mehta) — concrete EIP-shaped proposals to reallocate validator yield, smart-contract revenue, and DAO treasury yield into ecosystem development. Together they form the operational successor to RPGF/QF as Ethereum’s funding architecture.

Key Ideas

The Ethereum Kernel framework — Martin Hansen

Hansen’s framing: map the kernel of the world computer, then fund it sustainably. The kernel is the set of critical functions that guarantee Ethereum’s uptime, programmability, and accessibility — distinct from the broader ecosystem of applications, services, and tooling that orbit it.

Kernel components (Hansen’s mapping):

  1. Clients (CL + EL) — Largest component. Client diversity is now synonymous with Ethereum; non-negotiable for the 100% uptime track record.
  2. Coordination — The overhead of multi-client coordination across hard forks. Hundreds of people, documentation, ACD calls.
  3. Research — Split into short-term (UX, hardening, scaling) and long-term (endgame solutions, post-quantum, the straw-map roadmap).
  4. Security specs & testing — Cross-protocol, separate from per-client testing.
  5. Language stack — Solidity, compilers, deployment tooling. Most assets are exposed via this layer.
  6. Core wallet infrastructure — Open-source wallet standards; the user’s interface to Ethereum.
  7. Critical tooling & dependencies — Source code verification (Sourcify), non-Ethereum library dependencies that infrastructure relies on.

The $18M/year minimum

Hansen’s exercise: assume zero cost basis (no prior funding, no token treasuries, no revenue), 85% to compensation, 15% overhead, $1M annual bug-bounty program, slightly slower-than-current development cadence. Result: $18M/yr minimum to keep the kernel operational.

The framing matters more than the specific number: it’s a floor, an estimate of what we need to find in neutral funding annually to avoid capture. Above that, additional funding accelerates development; below it, the kernel risks abrupt shutdowns or strategic capture.

Why neutral funding is the right frame

Hansen’s argument for the funding category: neutral funding has no strings attached. It protects against:

  • Abrupt shutdowns when other funders deprioritize a project.
  • Strategic short-termism induced by quarterly metrics.
  • Capture by entities with conflicting interests.

The onion model: kernel at the core, extended core infrastructure around it, tooling and services further out, applications at the outer ring. Neutral funding should flow toward the kernel first; revenue-generating models are appropriate at outer layers.

Mapping the dependencies of publicly funded open source — Sophia Sukhinina

Sukhinina’s hypothesis: a dependency-aware stack built on transparency, programmability, and intermediary minimization would provide a fairer, more efficient funding environment than anything that exists today.

The numbers that motivate it (2024 Harvard/Toronto working paper):

  • Supply-side value of open source: $45 billion.
  • Demand-side replacement value: $8.8 trillion.
  • 96% of demand-side value created by 5% of OSS developers — roughly 3,000 people holding up the foundation under banking, browsers, medical devices, government services.

The funding gap is brutal:

  • 5,001 companies surveyed by Linux Foundation + GitHub + Harvard.
  • 159 reported funding open source — $1.7B total.
  • 86% of that is employee labor (engineers contributing hours during paid time), which only flows to the top-level projects companies already depend on.
  • 14% is direct financial support: ~$239M.
  • After contractors, ops, legal, and audits, only ~$9.7M reaches maintainers’ pockets.
  • Divide by 3,000 maintainers: $3,200/year per maintainer.

The EU Cyber Resilience Act changes funding visibility

CRA fully comes into force December 2027 (partial September 2026). Every commercial digital product sold in the EU must publish its full Software Bill of Materials (SBOM) — the complete dependency graph. Critical implication: when funders open a project they want to support, they will see every dependency. Ignoring the deep dependencies becomes legally and morally indefensible.

Sukhinina’s demo at ETHPrague: a tool analyzing 10 projects funded by Schleswig-Holstein (German state government). 4,000 total dependencies across the 10 projects. For one specific project (foodsoft, a regional agricultural producer software), 55 of 86 direct dependencies are primarily maintained outside the EU. To fully fund this project, the funder would need to send money across 6 continents in 12 different currencies — economically impossible via SWIFT or SEPA, structurally enabled by Ethereum + stablecoin rails.

UNICEF Drips Network pilot

The first operational instance: UNICEF — the only UN agency permitted to receive donations in digital assets — launched a pilot with Drips Network on Ethereum. Five curated digital public goods, set up with smart-contract auto-splitting (currently equal weights, but Drips supports dependency-aware weighting). Donor sends value to the address, smart contract forwards 20% each. The dependency-aware redistribution capability is the prototype for CRA-driven funding flows.

Sourcing Funding for Ethereum Growth — Devansh Mehta

Mehta’s three-layer proposal for sourcing funding (not allocation):

Consensus layer (validator yield reallocation):

  • Validators flag a percentage of their yield for ecosystem reinvestment, similar to the gas-limit flag mechanism.
  • On a Nash equilibrium basis, validators commit a non-zero amount because increased ecosystem value increases the price of their staked ETH.
  • Solves the prisoner’s-dilemma problem (taxation is the real-world analog) — if 51% of validators commit, 100% participate, killing the free-rider problem.
  • Allocation via Condorcet aggregation of validator preferences: each validator publishes preferred addresses + weights; the protocol synthesizes the best-fitting contract; anyone can propose a better-fitting contract that replaces it.

Smart-contract layer (dependency markets):

  • Each smart contract publishes its dependency graph (CRA-style SBOM).
  • Open prediction market: traders predict expert-assigned weights to dependencies; trade resolution rewards close-to-expert predictions.
  • Mehta’s live deep.co.pm market demonstrated Helios’s 3,677-dependency dependency graph; $20K in prizes for trading models.
  • Manipulation-resistant: attempted manipulation gets shorted by other traders chasing the profit opportunity.

Application layer:

  • Frontends voluntarily route a percentage of fees toward public-goods funds.
  • Wallets and aggregators that don’t route fees compete with ones that do; users vote with their feet.
  • DAOs with treasury yield commit a default percentage to ecosystem funding — turning off requires an explicit vote rather than turning on requiring one.

The cumulative vision: a $100 swap → application layer routes some → smart-contract layer routes more to dependencies → consensus layer validators reallocate yield.

Diversifying Funding via FRCs (Raul Romanutti)

Romanutti’s FRC (Funding Round Contracts) proposal: standardize the funding round itself as an on-chain primitive. A funding round contract specifies eligibility criteria, voting/matching mechanism, allocation function, and reporting requirements. Multiple FRCs can run in parallel for different ecosystem segments (security tooling, language stack, research, education). The current QF-round-as-event becomes the QF-round-as-protocol.

Details / Subtopics

Why the kernel reduces over time

Hansen’s framing: as endgame solutions land (ZK-EVM, FOCIL, single-slot finality), the kernel can shrink. Today’s kernel is larger than 2020’s kernel; 2030’s kernel may be smaller. Funding the kernel today is also an investment in eventually needing less of it.

The supply-chain attack relevance

Hansen’s “other critical tooling and dependencies” category is exactly the layer that the 2025 supply-chain attack wave (Bybit’s $1.5B loss, the smart-contract security 2026 statistics) hit hardest. The kernel framework explicitly internalizes the lesson: dependencies that are Ethereum-adjacent but not Ethereum-native are kernel-critical because their compromise breaks Ethereum-adjacent applications.

How the EU funding flows already work

Sukhinina’s overview of existing EU funding for open source:

  • NLNET (Dutch) — Direct-to-developer grants since 2019, supported 1,200+ projects with €140M, 80K active contributors.
  • Sovereign Tech Agency (Germany) — €25M+ since 2022, 60+ projects. Funds libraries, protocols, dev tools below the application layer (the dependency layer).
  • EDIC (EU-level pilot, announced one month before ETHPrague) — Scales the Sovereign Tech model to EU-wide.
  • Horizon Europe + Digital Europe — €100B umbrella programs; open-source projects qualify.

The shift Sukhinina observes: EU funders are now interested in following dependency graphs, but lack the financial-rails infrastructure to actually fund cross-continent maintainers. Ethereum’s stablecoin rails are the obvious fit, but governments don’t yet know it.

The principal-agent problem in validator-yield reallocation

Mehta’s honest disclosure of the weakness: stakers are not the same as users. The proposal works at the protocol level only if validators’ preferences align with users’ preferences. They often don’t — staking operators want issuance increases (more rewards); ETH-holders-delegating-to-stakers want issuance decreases (less dilution). Mehta’s mathematical analysis suggests no Nash-equilibrium cartel can form (always profitable to defect against a cartel), but the principal-agent problem remains.

The dependency-market manipulation defense

Mehta’s claim about manipulation: in the live market for Helios dependencies, an attempted manipulation of one repo’s weight (someone bought a position pushing it far above its actual market clearing price) was quickly arbed back to normal by other traders. Manipulation attempts become profit margin for the honest traders, not equilibrium-breaking events.

Disclosure: short-run vs long-run security

A question from the floor: doesn’t publishing the full dependency graph hurt security by revealing attack surfaces? Mehta’s answer (citing Shannon’s principle): security by obscurity is not a valid security model. In the short run, more vulnerabilities will be found and exploited; in the long run, more vulnerabilities will be fixed because they’re seen. The same trade-off as open-source vs. closed-source generally.

Connections

Open Questions

  • $18M/year — credible neutral source? Current candidates: EF treasury (under pressure from kernel expansion), validator-yield reallocation (Mehta’s EIP, untested), governmental neutral funding (Sukhinina’s CRA path, also untested), DAO-treasury yield commitments. Some mix is plausible; no single source covers the floor.
  • Will the CRA’s SBOM requirement actually drive dependency-aware funding, or will it become a compliance checkbox without behavior change? The legal pressure is real but compliance-fatigue is a known failure mode.
  • The validator-yield EIP is structurally one of the most ambitious EIPs ever proposed. Does it survive ACD process, or does it die in the way most non-technical-coordination EIPs die?
  • The dependency-prediction-market manipulation defense is empirically defensible at small scale; does it hold at scale when manipulators have $100M+ to spend? Open.
  • Does the EF survive intact as the kernel-coordination entity, or does the Mandate-era controversy fragment it into sub-foundations (one per kernel component)?