NewsFlash Articles Data Fundraising Skill&API

After the <Grant> is Spent, What’s Next for Ethereum Developer Tools?

Read this article in 23 Minutes

The past question was “Who should be funded”; the current question is starting to become “How can teams already proven to be important avoid being at the mercy of the next grant decision”.

Original Title: "What to Do After the Grant Runs Out: Ethereum Developer Tools"

On February 27, Raul Romanutti from the Ethereum Foundation's Grants Team published an article titled "This Is Fine (Until the Grant Runs Out)" on ETHPanda. The article introduced Project Odin—a structured sustainability support plan for a select few strategic teams who have previously received significant funding from the EF.

At first glance, Odin could easily be categorized as "EF launches another public goods funding program." However, it differs from a typical grant: the project teams do not receive a new lump sum of startup funding or a one-time open application opportunity; instead, they are part of a long-term support mechanism tailored for existing grantee teams. The EF Blog set a two-year timeframe goal to assist these teams in establishing a reliable sustainable path, reducing reliance on a single funding source; with the on-site strategic advisor's support and execution cycle lasting approximately 12 months.

Odin is concerned with the road after the grant.

The key point mentioned in 0xRahul's tweet is also here. He did not frame the issue as "Should the EF continue to fund public goods," but rather focused on the sustainability of developer tool teams: large, complex, heavily used open-source tools cannot rely on enthusiasm or short-term grants in the long run.

In past discussions within the Chinese community on public goods, the focus has been more on Gitcoin donations, RetroPGF grants, EF funding lists, or whether a project is suitable for donation. Project Odin points to a later stage: after a public goods project has proven its importance, how can it avoid being led by the next grant?

Grants Remain Important, but the Focus Is Shifting

First, let's dispel a misunderstanding: Project Odin is not a signal that the EF is halting funding for public goods.

From recent publicly available information, the EF continues to fund protocol research, clients, cryptography, ZK, developer tools, education, and public goods experiments. Projects listed in the EF Ecosystem Support Program 2026 Q1 Allocation Update cover various infrastructure and tool directions such as EthereumJS maintenance, BuidlGuidl, WalletConnect clear signing library, L2BEAT 2026, DISC-NG Geth, Lighthouse, Vero, formal verification, among others. Similar quarterly funding lists have been appearing consistently over the past few years.

The grant itself has not disappeared; it simply cannot solve all problems.

For early-stage projects, a grant can reduce the cost of getting started. For research-oriented work, a grant can cover explorations that are not easily commercialized. For community education and public infrastructure, a grant remains a significant source of funding. However, if a tool team that many projects rely on heavily has only one primary source of funding in the long term, the risk becomes concentrated.

As mentioned in the EF Blog, many teams do not lack technical capabilities; their weaknesses lie in non-technical areas such as fundraising, external communication, organizational design, and legal structure. Teams can write compilers, conduct research, and maintain network stacks, but they may not necessarily have the bandwidth to answer these questions: Who relies on us the most? Which users are willing to sign long-term support contracts? Which work can be procured by enterprises? Which revenue will not affect the project's neutrality?

Odin is trying to address this part of the capability.

Why Developer Tools Most Easily Get Stuck Here

0xRahul outlined four traditional developer tool models in a lengthy tweet: big company open source, bundling into a larger product, commercial SaaS, and voluntary maintenance.

When these four models are applied to Ethereum, they all have obvious limitations.

Developer tools from large companies are often robust but are long-term dependent on the company's strategy. When the company is willing to invest, the ecosystem benefits; when the company's direction changes, maintenance priorities also change. For an ecosystem like Ethereum that emphasizes trust and neutrality, entrusting key tools to a single company's long-term interests is not stable.

Bundling tools into a larger product is similar. It can serve a particular product line or platform users well, but it is challenging to remain entirely open. Ethereum's developer tools need to be used across wallets, clients, Layer 2 solutions, and protocols, and a walled garden would weaken its public nature.

Commercial SaaS can address some issues, but not all. Many crypto teams are still in the early stages, with limited R&D budgets. More importantly, tools such as compilers, languages, libraries, network stacks, and transparency platforms often contribute value to the overall ecosystem's security and efficiency and are challenging to directly charge per individual user.

Lastly, there is voluntary maintenance. Small libraries or personal tools can be driven by short-term interests, but large-scale infrastructure cannot. Compilers require long-term testing and security response, languages need roadmaps, and community governance, P2P network stacks need cross-project coordination, and risk monitoring platforms require continuous data maintenance. These are not one-time efforts.

Developer tools often find themselves in an awkward spot: they are too low-level to be coveted yet too public to naturally monetize.

Project Odin Is Not an "Accelerator"

The EF Blog describes Odin as a structured support program, but it's not a typical startup accelerator.

Accelerators usually cater to growth-stage companies, focusing on product-market fit, fundraising, and scaling. Odin doesn't require public goods teams to pitch a venture-scale story; instead, it is concerned with whether these teams can sustainably deliver over multiple funding cycles, gradually evolving into more stable institutions.

The core of Odin is that each team is paired with an embedded strategic advisor. This advisor's role is not a one-time training; instead, they are involved long-term in the team's sustainability planning and execution. The whole process roughly consists of three stages:

· The first stage is mapping out reality. What is the team currently surviving on? What fundraising methods have been attempted in the past? Who benefits from it in the ecosystem? What funding channels are available? What is the cost of each channel?

· The second stage is validating the path. This involves engaging with potential funders, partners, corporate users, DAO delegates, or protocol teams to determine which directions are not just theoretical.

· The third stage is execution, which includes preparing fundraising or partnership materials, building partnership pipelines, and, if necessary, designing support contracts, service agreements, or other forms of recurring revenue.

While this process may not have the glamour of a "public goods" narrative, it addresses one of the most practical aspects of a project: teams cannot afford to start looking for the next funding round only when the runway is about to end.

Why Vyper Was Chosen

Vyper is the first pilot participant in Project Odin.

This choice is not surprising. Vyper is an EVM-centric Pythonic smart contract language that emphasizes security, simplicity, and readability. As mentioned in the EF Blog, Vyper has safeguarded over $27 billion in on-chain value at its peak. Even today, it continues to support thousands of contracts and billions of dollars in TVL.

Language and compiler are typical public infrastructure. Once they encounter issues, the impact is not limited to a single application but spreads to all protocols and developers depending on them. However, from a business model perspective, these projects are challenging to manage: the core language should remain open, secure, and capable of formal verification, which requires ongoing investment. Relying solely on community donations is difficult to sustain a long-term team.

The recently established Foundation for Verified Software by the Vyper team precisely addresses this issue. According to the FVS website, the organization focuses on formal verification research, open tools, and ecosystem support. Current projects include Vyper, Vyper-HOL, Verifereum, and HOL4. The EF Blog also highlights Vyper/FVS as the first pilot participant in the Odin discussion.

However, this is not yet a proven commercialization model. More accurately, it is an experimental organizational form: the foundation undertakes long-term research and open-source tools, while the team revolves around formal verification, auditing, training, and support for contract or enterprise POC, exploring the possibility of generating a stable income.

In the Chinese community context, Vyper is not just "a language project supported by EF." With the increasing demand for contract security in DeFi, L2, and institutional funds, the capability of formal verification may evolve from a research topic to a purchasable professional service.

libp2p and L2BEAT: Two Comparative Cases

The EF Blog mentions libp2p at the beginning. It is a P2P network stack used by many Web3 systems and Ethereum clients for node discovery, message propagation, block and validator vote dissemination. The EF Blog cites it as one of the recent funding pressure cases to illustrate that widely relied-upon open-source infrastructure may also seek assistance when resources are scarce.

This case demonstrates the financial dilemma of underlying dependencies: the deeper the layer, the more users, and the less clear the direct payment relationship. Every project hopes for libp2p's stability, but it is challenging to determine which project should bear the primary maintenance cost.

On the other hand, L2BEAT provides a different perspective.

L2BEAT is a transparency tool well-known in the Chinese community, tracking long-term risks and data related to L2, bridges, DA, ZK, etc. It is not a pilot of Odin, but it publicly discloses its funding sources, making it suitable as a case study for a funding portfolio.

According to L2BEAT's donation page, its funding sources include the Partnership Fund, Ethereum Foundation grants, Optimism RPGF, Gitcoin, rewards and compensations for participating in L2 governance frameworks, special grants, conference sponsorships, report and dashboard exploration, direct community donations, among others.

This list is quite interesting. It indicates that a public goods team doesn't necessarily have only two paths: relying entirely on grants or transitioning to a SaaS model. A team that provides long-term impartial data and expert judgment can receive support from various ecosystem roles. However, the key is to clearly articulate its funding sources, allowing external parties to consistently scrutinize its incentive structure.

Combine Funding Mechanisms Instead of Betting on One Answer

Over the past two years, the Chinese community has become quite familiar with public goods funding mechanisms such as Gitcoin, Optimism Retro Funding, Protocol Guild, and Drips. These are often discussed in the context of "diversifying funding sources" and "sustainable revenue streams."

However, these mechanisms address different issues: Gitcoin Grants are more suitable for aggregating community signals and can help early-stage public goods projects gain exposure and seed funding; Optimism Retro Funding rewards work that has already made an impact, fitting for compensating past contributions; Protocol Guild targets Ethereum L1 core R&D contributors, establishing a longer-term on-chain funding mechanism; Drips focuses on dependency funding, aiming to direct funds upstream to open-source projects based on their dependencies.

For large developer tool teams, the key is not to pick a single answer from these mechanisms but to understand the applicable boundaries of each funding type. QF projects need repeated lobbying, Retro Funding outcomes carry uncertainty, DAO grants are influenced by governance cycles and token volatility, direct donations are usually insufficient to cover stable team costs.

Project Odin's focus is not on inventing a new funding mechanism but on helping teams leverage existing mechanisms and potential revenue streams: grants can support research, retro funding can reward impact, DAOs or protocols can provide targeted support, enterprise users can purchase services or contract support, partners can collaboratively develop POCs.

While these may sound like common operational issues, for many public goods teams, operational capability itself is a weak point. What Odin truly addresses is translating the "project's value" into the ability to understand "who relies on it, who is willing to sustainably support it, and what revenue will not compromise its public nature."

In other words, "beyond grants" is not just a slogan but a set of specific funding combinations, partnerships, and organizational capabilities.

Understanding the Chinese Community

In the Chinese community, the concept of public goods has traditionally had two main entry points.

One entry point is through donations. For example, at the beginning of each Gitcoin Grants round, there are project recommendations, donation tutorials, and interaction guides. Here, public goods are seen more as a community participation activity.

Another entry point is through news. For instance, when the Ethereum Foundation (EF) releases its quarterly funding list, Optimism initiates Retro Funding, or a project receives a grant. Here, public goods are viewed more in terms of ecosystem fund flows.

The third entry point provided by Project Odin is the long-term stewardship of public goods teams.

For the Chinese community, this perspective is closer to developers and protocols. If a protocol relies long-term on an open-source library, a risk data platform, a compiler, a verification tool, or security infrastructure, it cannot just seek help when it is running out of funds. A more reasonable approach is to include these dependencies in its ecosystem budget: Which tools are key dependencies for us? Should long-term support be provided? Is there a need to purchase support contracts? Should we participate in dependency funding? Should public goods expenditures be reserved in the governance budget?

Labeling it as a charity issue is not accurate; it is more akin to a supply chain problem. Public goods are important not because they "deserve donations," but because many teams already rely on them in their daily development, security, data, and governance decisions. Since this reliance is real, supporting them is not just an act of kindness but also a form of ecosystem risk management.

If a protocol is willing to spend money on liquidity, incentives, growth, and branding but is unwilling to pay for the foundational tools it relies on, the saved cost is not a true saving; it merely shifts the cost to maintainers and the entire ecosystem. The reason Project Odin is worth paying attention to is precisely because it has taken this issue one step back from "who is willing to fund" to: "who truly relies on these teams and should therefore get involved earlier in their sustainability design."

Project Odin will not solve all public goods funding issues. Currently, it is only a structured support plan for a small number of strategically funded teams. However, it clarifies a long-delayed issue: public good projects should not only prove their value when applying for a grant but also determine who truly relies on them during day-to-day operations, who is willing to support them continuously, and what kind of revenue will not compromise their public nature.

This may be a signal that the Ethereum public goods discussion is entering the next phase. The previous question was "who should be funded"; now, the question is starting to shift to "teams that have already proven their importance, how can they not be subject to the life-or-death decision of the next grant."