The commons called. It wants a runway.

Every so often, in the blockchain world’s usual cycle of funding scares, a team maintaining a widely used open source public good declares mayday. Libp2p is a core infrastructure stack that powers multiple Ethereum clients (among others) and a large part of Web3 infrastructure. It was, not long ago, one of the latest projects to put out a call for assistance as financial resources ran thin.

Ethereum’s public goods landscape (in the sense of “teams building and open-sourcing things that are maximally valuable to our ecosystem”) has no shortage of talent: the ecosystem is full of professionals doing work that is deeply technical, widely relied upon, and chronically under-incentivized. These are the projects that quietly keep the ecosystem secure, reliable, and capable of evolving.

They also tend to share a vulnerability: while they are strong at research and engineering, they often lack the fundraising, operational, and business capacity needed to remain future-proof.

The basic symptom is: everyone depends on shared infrastructure, but no one wants to risk ending up at a competitive disadvantage by being the one to fund it. Ad-hoc funding is fragile, political, and cyclical. Reliability of funding flows is almost as important as the funding itself.

Project Odin exists to close that gap: it is a structured support program designed to help a small set of strategic Ethereum Foundation grantees build credible pathways to sustainability over a two year horizon, increasing ecosystem resilience by reducing long-term dependency on a single funding source.

What Project Odin is, and Why it Started

The core mechanic is simple: each team gets an embedded strategic advisor who works alongside them on sustainability planning and execution.

Instead of a single workshop or occasional guidance, Odin is meant to be hands-on, iterative, and grounded in delivery. Over 12 months, participants move from exploration and diagnosis to option mapping, then into validation and execution, with the explicit goal of strengthening their runway by identifying and piloting revenue generating opportunities and ensuring they’re implemented effectively.

Odin began with a pattern we kept seeing across the Ethereum ecosystem (and beyond): some of the most critical teams (those maintaining infrastructure, languages, tooling) were in a perpetual state of fragility. This, of course, isn't a surprise: they deliver real value but their ability to plan beyond the next grant cycle was constrained by uncertainty, a narrow set of funding options, and limited bandwidth for “non-technical” capabilities like fundraising strategy, stakeholder communications or organizational design.

In many cases, sustainability planning arrived too late. Teams understandably focused on shipping and research while they had runway, and then, near the end of a grant, quickly refocused on securing the next round of funding. This forces distracting pivots and increases pressure. Historically, support on sustainability issues has often been informal and reactive: organizations jump in when a team is already under pressure, but that pattern means that this starts when choices are narrowest.

Odin inverts this dynamic by bringing in structure early, embedding support to reduce volatility and treating sustainability as something teams design from day one rather than something they patch later. While it borrows the accountability and cadence of accelerator-style support, the goal is not venture scale but long-term viability: helping public good projects become stable institutions that can keep shipping over multiple cycles without constant existential risk.

Issues Identified Among EF Grantees

The recurring problem is rarely technical excellence. Instead, the gap is usually a lack of a clear, viable plan to sustainable funding and the execution chops to achieve it. Many teams operate with a single dominant funding source. Without a strategy, they cannot survive market downturns, governance shifts, or changes in funding priorities.

Even when teams make a stab at diversifying, the landscape is difficult to navigate, and serious teams often struggle to identify which sustainability route is actually worth committing to. There are many potential sources (foundation grants, protocol/DAO grants, retroactive public goods mechanisms, quadratic funding, sponsorships and commercial or hybrid models) but each comes with different incentives, timelines, and risks. It’s easy to drift into grants applications rather than building a coherent long-term plan, and it’s hard to evaluate trade-offs (or even generate confident options) without structured guidance.

Operational maturity is another common constraint. A team can be excellent at engineering and still struggle with planning cadence, role clarity, decision-making, stakeholder communications, the right legal setup to offer services and the “translation layer” that turns research and development into outputs that others can reliably adopt, integrate, or even pay to support.

What we do, How we do it, And What Outcomes we Expect

Odin’s pilot focuses on EF grantees who have received significant grants before and whose long-term health matters to the ecosystem. “Critical” refers to a project that directly serves core user needs and materially supports Ethereum’s security, resilience, and day-to-day usability. The selection logic is not “who is struggling” but rather “who was largely funded in the past and likely to benefit from structured sustainability support”: especially where the team’s main bottleneck is fundraising/BD/ops rather than technical capacity.

The engagement takes place over the course of a year-long program and has 3 phases:

Research and map realistic funding and sustainability options available to the team, grounding the work in an understanding of the project’s current state, prior attempts, ecosystem context, and goals, and clarifying the trade-offs involved. This phase is not about forcing a single “correct” model and more about highlighting the range of options and an understanding of the tradeoffs with each funding channel, especially around predictability and operational burden. During this phase, multiple assumptions are formulated regarding the funding mechanisms best aligned with the project’s nature and goals.

Validating the most promising paths teams are comfortable with. It usually means beginning external conversations early (with potential funders, delegates, partner organizations, or potential customers where appropriate), shaping messaging, and constructing a plan that is concrete enough to execute. Defining an ideal customer profile becomes essential here, and leveraging our connections to make sure there is a relationship between the project’s dependencies and its users is the uttermost important outcome of this phase.

Executing or improving the team’s pipeline, building the materials needed for fundraising and partnerships, and, when relevant, helping the team structure and pursue contractable work or support agreements without derailing core public goods output.

Success is not measured by how polished a roadmap looks but by whether teams graduate with increased organizational resilience providing a credible path to reduced dependency on the EF. Concretely, this can look like diversified funding sources, improved operational cadence, stronger external communication and, when it fits the project, at least one repeatable revenue-like stream such as support contracts or service agreements that meaningfully stabilizes monthly operations.

Equally important is producing reusable tools and guidelines: templates, playbooks and measurable success metrics that can be applied to future cohorts so sustainability support becomes more systematic over time, not reinvented per team.

Vyper and the Reality of Funding options: Treating Funding Diversification as a Risk Management Technique

The Vyper core team (supported by grants since the language’s early development) has recently established the Foundation for Verified Software as the institutional home for this work, and gracefully became Odin’s first pilot participant. Their product serves as a valuable case study due to the easily observable implications: they produce important work with ecosystem-wide value but long-term sustainability isn’t automatic. Like many public goods, Vyper can attract grants and community support, yet still face a somewhat delicate operating reality if funding is unpredictable or overly concentrated.

Vyper is a Pythonic smart contract language for EVM, conceived by Vitalik Buterin in 2016, that focuses on security, simplicity, and readability, aiming to make contracts easier to audit and less prone to common pitfalls while still producing gas-efficient EVM bytecode. In nine years of continuous development, 76 releases, 231 contributors and 5,100+ GitHub stars, it became the canonical choice for high-stakes DeFi infrastructure. At its peak, Vyper secured over 27 billion USD in on-chain value and it is led by the team now founding The Foundation for Verified Software.

Why do we want the Foundation for Verified Software to succeed? Why is AI-assisted formal verification their north star, and why are they now building both research and commercial infrastructure around it? At a general level, language diversification is essential for Ethereum resilience, and Vyper's footprint makes that concrete. Today, 7,959 Vyper smart contracts secure more than 2.3 billion USD in total value locked (TVL) across leading blockchains, with an all-time-high TVL secured reaching over 30.0bn USD. On the ground, Vyper presents a clear opportunity to onboard the next generation of Ethereum smart contract developers, for them to have an unprecedented level of safety and trust in their code, and for the institutional capital that demands a higher level of security guarantees beyond those the traditional audits can provide. It is designed from the ground up for formal verification and represents the next generation of formal-verification-first languages: an approach that prioritizes machine-checkable correctness as a first-class property of software, not an afterthought. It is an opportunity for smart contract developers to have an unprecedented level of safety and trust in their code.

With Vyper, we confirmed that different funding channels, particularly those defined as grants or donations, behave very differently under stress:

Retroactive funding can be powerful, but it is inherently uncertain; Quadratic funding can work, but it often demands repeated campaigning and can be sensitive to matching-pool volatility and attention cycles; DAO and protocol grants can be substantial, but they introduce governance overhead and, in some cases, token volatility risk.

This is why Odin treats diversification as a risk management tool. Our program highlights revenue-generating and hybrid options, not as a rejection of public goods funding, but as a way to add predictability in funding flows. For a project like Vyper, paid support contracts, SLAs, training or consulting services can coexist with grants and retroactive funding, providing stable baseline operations while public goods mechanisms fund core development and long-term research.

Success in engaging with Vyper means the focus shifts from pursuing a single ideal funding source to constructing a resilient portfolio. This involves maintaining legitimacy and community support through ecosystem-aligned public goods mechanisms, while simultaneously establishing one or two reliable funding streams to cover a significant portion of operational expenses. Over time, as delivery discipline strengthens and outputs become more contractable, that trajectory begins to resemble the Frontier Research contractor pattern: sustained frontier work funded by a blend of grants and contracts, grounded in real stakeholder needs.

How Odin Could Evolve into the FRC Vision

Today, Odin functions like an accelerator for Ethereum-related public goods. If it proves effective, the longer-term goal is to move beyond supporting individual teams and toward a new institutional form the ecosystem currently lacks: Frontier Research Contractors (FRCs). FRCs would fund advanced technical work through a mix of grants and contracts, solving others’ engineering problems with strong delivery discipline and customer focus. They’re needed because existing categories don’t fit fast-growing projects: (1) startups often need product focus and can’t always justify contract-driven work to investors, and (2) larger research organizations excel at coordinated, long-horizon efforts but struggle to meet sharp, fast-moving, high-context needs in an ecosystem like Ethereum.

The Foundation for Verified Software by Vyper is not just an example of this trajectory: it is the first concrete case of what an FRC looks like in practice. It is not a startup: there are no investors requiring it to subordinate long-horizon verification research to product velocity or market timing, while a separate commercial entity can pursue those opportunities without compromising the Foundation’s research mandate. It is not a large research organisation: it moves quickly and can respond to sharp, fast-moving engineering needs that coordinated academic institutions are structurally unable to serve. It sits in exactly the gap the FRC model is designed to fill.

The FRC model fills this gap by providing a durable “delivery engine” for frontier engineering and research. Project Odin is a stepping stone: emphasizing clear outputs, alignment with ecosystem needs, operational rigor, and a stable funding portfolio. In that sense, Odin is not just a support program: it is also a laboratory for understanding what it takes to create durable research-and-delivery institutions for public goods. The common thread among FRC founders will not be the specific form of their technical vision but their ability to sustain and finance progress by addressing real customer needs while pursuing those visions. A future post will dive deeper into this vision.

Why This Matters

Ethereum’s resilience depends on the resilience of its public goods, especially from teams doing work that is foundational, technically difficult, and not easily monetized. If such teams operate under constant funding fragility, the ecosystem pays the price in slower iteration, higher risk, and institutional knowledge loss. Project Odin is an attempt to change the default by treating sustainability as a design problem and address it early: with structure, accountability and hands-on support.

This initiative, along with other projects that the EF's Funding Coordination team is working on, aim to chart a clear direction for Ethereum's public goods ecosystem. If you want to learn more about project Odin, please contact us at funding-coordination@ethereum.org.