Ethereum’s grant lists show why maintenance competes with new research

The Ethereum Foundation’s 29 April allocation update describes support for the first quarter of 2026. The list includes EthereumJS maintenance, Lighthouse development, L2BEAT transparency work and a WalletConnect clear-signing library. It also names cryptography research and performance-testing infrastructure. These are different types of output: maintaining a dependency is not the same task as publishing a new protocol idea. The update supplies project descriptions, but should not be treated as a ranked list of finished products or a comparative performance score. Source.

The 18 August update covers second-quarter support. It includes Lodestar and Lighthouse client work, a private-information-retrieval library, formal-verification tools and research on economic incentives. Some descriptions concern ongoing development or testing rather than a released feature. The two lists show recurring support for infrastructure that applications depend on, alongside longer-term research. They do not provide a uniform dollar figure for every named entry in the pages reviewed, so a precise project-by-project funding comparison cannot be reconstructed from those tables alone. Source.

Our view is that a grant portfolio should be assessed by the work it sustains, not by how many novel names appear in an announcement. Maintenance can be difficult to market precisely because success often looks like continuity: a dependency stays compatible, a client survives an upgrade, a test catches an error before production. Research has a different uncertainty profile. A useful follow-up tracks deliverables, repositories, adoption and unresolved problems for each kind of work. Treating every grant as a startup investment obscures those differences. Treating every funded description as completed progress makes the opposite mistake.

For a maintained client, follow-up evidence might be a merged change, a test suite or documented compatibility with an upgrade. For a research grant, the output might instead be a paper, a negative result or a clearer limit on an approach. Different deliverables need different evaluation methods; counting them as interchangeable project launches loses that information.