All articles
Security FundamentalsJune 14, 20269 min read

Why Public-Goods Funding Matters for Web3 Security

Open security tools, education platforms, audit infrastructure: under-funded by markets, over-relied-upon by the ecosystem. The funding mechanisms that work and the ones that don't.

By Carlos (Bloqarl)

TL;DR

  • Web3 security depends on public goods: open-source tools (Foundry, Slither, Echidna), education platforms, audit infrastructure (test corpora, vulnerability databases), and developer documentation. None of these capture revenue proportional to the value they create.
  • The market under-funds them. A protocol that uses Foundry to ship safer code captures the value privately; Foundry sees none of it. Multiply this by every protocol in the ecosystem and the misalignment is clear.
  • Three mechanisms work for funding public goods in Web3: quadratic funding (Gitcoin Grants, $50M+ distributed), retroactive public goods funding (Optimism RetroPGF, $50M+ distributed), and direct foundation grants (Ethereum Foundation, ~$30M/year).
  • Mechanisms that fail: ad-supported, paywall-after-launch, donation-only without matching multiplier. The first two compromise the public-good nature; the third under-aggregates small donations.
  • The TheDAO Security Fund's 2026 Ethereum Security QF round (500 ETH matching pool) is one example of a security-specific funding effort. Zealynx Academy participated.

Why this matters

If you're building a smart contract, you almost certainly use code that nobody pays for. Foundry's test runner, Slither's static analyzer, OpenZeppelin's standard contract library, audit firms' published findings, the EVM itself: all maintained by people working without direct revenue from the protocols benefiting.

This is a textbook public-good problem. Each protocol benefits privately from the shared infrastructure. None of them, individually, are incentivized to fund it. The infrastructure persists because of:

  1. Foundation grants from organizations like the Ethereum Foundation.
  2. Volunteer maintainers willing to subsidize their time.
  3. Companies whose business model intersects (e.g., audit firms maintaining their own tools).

The first source is finite. The second is unsustainable at scale. The third is partial coverage.

When a public-good fails to be adequately funded, the consequence isn't immediate. The tool stops getting maintained. Bugs accumulate. Documentation goes stale. Eventually, a protocol relying on the unmaintained tool ships a vulnerability the tool would have caught in the past, and somebody loses money.

If you're building Web3 infrastructure, this article explains the mechanisms that work for funding the work. If you're a Web3 user benefiting from these tools, this is the context for why funding rounds (like the TheDAO QF round Zealynx Academy participated in) are not a charity case.

What a public good is in Web3

The classical economic definition of a public good has two properties:

  1. Non-rivalrous: one person's use doesn't reduce another person's ability to use it.
  2. Non-excludable: there's no way to prevent someone from using it.

Open-source Web3 infrastructure meets both:

  • Foundry (smart contract testing framework): everyone uses it; my use doesn't slow yours; I can't prevent you from using it.
  • OpenZeppelin Contracts (standard library): same.
  • Slither (static analyzer): same.
  • Public audit databases (Code4rena reports, Sherlock contests): same.
  • Documentation and education (Solidity docs, MDN-equivalent for EVM, this Academy): same.

These are infrastructure. They have no native revenue model that captures their value. Every protocol that uses them captures the value privately, but the infrastructure is maintained by someone else.

This isn't unique to Web3. Linux, Python's standard library, browser engines, OpenSSL: all public goods that the web depends on. The history of those funding models is informative for Web3.

Mechanism 1: Quadratic funding (Gitcoin Grants)

We covered the math in the QF mechanics article. The mechanism distributes a matching pool to projects based on the breadth of their donor support.

In practice for Web3:

  • Gitcoin Grants: the canonical implementation. Has run dozens of rounds since 2019. Cumulative distribution: $50M+ in matching across thousands of projects. Round themes range from open source to climate to specific verticals.
  • TheDAO Ethereum Security QF (May 2026): a security-specific round with a 500 ETH matching pool (~$1.5M). Projects in the round included security tools, education platforms, audit infrastructure. Zealynx Academy participated.

What QF does well: surfaces breadth of community support. A small project with 200 enthusiastic donors can outperform a flagship project with 5 sponsors. This rewards genuine usefulness over name recognition.

What QF does less well: the matching pool size limits payouts. A round with $1M in matching can't fund a $10M-budget project. QF complements other mechanisms; it doesn't replace them.

Mechanism 2: Retroactive Public Goods Funding (Optimism)

Optimism's RetroPGF inverts the standard funding flow. Instead of giving grants in advance based on what projects promise, RetroPGF gives grants AFTER projects have demonstrated value, judged by a council.

The thesis: it's hard to predict which projects will succeed. It's easier to look back and identify which ones already did. Pay them retroactively for the value they've already created.

Mechanics:

  • A pool of OP tokens is allocated for retroactive distribution.
  • A council of judges evaluates projects based on impact in the recent period.
  • Top-ranked projects receive sized payouts.

Optimism has run multiple RetroPGF rounds, distributing >$50M cumulatively. Round 4 specifically distributed 8 million OP tokens.

What RetroPGF does well: rewards projects that already proved valuable. Reduces the speculation problem. Funds infrastructure that actually got used.

What RetroPGF does less well: requires judges (centralization). Projects need to be visible to the council; under-the-radar work can be missed. Long feedback loop (impact happens, then funding follows months later).

Mechanism 3: Direct foundation grants

The oldest mechanism. The Ethereum Foundation Grants program funds projects via direct application and review. Approximately $30M/year distributed across research, tooling, infrastructure, and education.

Other foundations operate similarly: Gnosis Safe Foundation, Solana Foundation, Polkadot Treasury, etc.

What direct grants do well: high upfront capital for projects that need it. Strong relationships between funder and project. Predictable timelines.

What direct grants do less well: scale poorly. The foundation has limited bandwidth for review. Projects without foundation relationships are invisible. Selection bias toward established teams.

What doesn't work

Ad-supported infrastructure

A few Web3 sites have tried to support open-source tools with display advertising. The model fails because:

  • Web3 developers are sophisticated audiences. Most run ad blockers.
  • Crypto ads are higher-fraud than mainstream ads (rugpulls, phishing). Reputable infrastructure doesn't want to host them.
  • The CPM rates don't cover the work.

Paywall-after-launch

Some open-source projects launch free, build a community, then introduce a paid tier. This works for some products (developer tools with a "team" SKU) but fails for foundational public goods because:

  • Forks immediately appear, free, breaking the pricing power.
  • The paywall damages trust with the community that made the project successful.
  • The original maintainers have to fight forks instead of building.

Donation-only without matching

A "buy me a coffee" link or Patreon page captures real but small dollars. Without a matching multiplier (which is what QF provides), the donations are linear in donor enthusiasm and rarely cover full-time engineering.

This is why QF specifically (with matching multipliers) outperforms pure donation: each $5 donation triggers an additional $50-$100 from the matching pool. A protocol relying on direct donations alone is leaving 10x of funding on the table.

Case studies: Foundry, Slither, Echidna

Foundry

The dominant Solidity testing framework as of 2024-2026. Created by Paradigm; original lead maintainers worked there.

Funding model: Paradigm pays the maintainers as part of their broader research mission. This works because Paradigm is a venture firm whose portfolio benefits from better testing tools. They're effectively pre-paying for value their portfolio captures later.

Limitation: Paradigm can stop funding at any time. The community would have to step in. The QF / grant ecosystem is part of the contingency.

Slither

The dominant static analyzer for Solidity. Created by Trail of Bits.

Funding model: Trail of Bits is an audit firm. Slither is part of their internal tooling that they open-sourced. Maintenance is funded by the firm's audit revenue.

This is similar to Foundry's pattern but more sustainable: the audit firm directly benefits from a better static analyzer (it makes their audits more thorough), so the funding alignment is tight.

Limitation: if Trail of Bits' audit business contracted, Slither's maintenance would suffer.

Echidna

The dominant fuzzer for Solidity. Created by Trail of Bits.

Same funding model as Slither. Same alignment, same limitation.

The pattern

Looking at successful Web3 public goods, a few patterns emerge:

  1. Adjacent revenue: the maintainers have a separate business that benefits from the public good (Trail of Bits → Slither, Echidna; Paradigm → Foundry).

  2. Foundation-funded: the maintainers work for or are funded by foundations (Ethereum Foundation funds many Solidity-ecosystem tools).

  3. Crowd-funded: the project participates in QF rounds and accumulates matching across multiple rounds (smaller projects, education platforms).

The QF + RetroPGF + Direct Grants triad is what makes the third pattern viable for projects that can't rely on adjacent revenue. Without these mechanisms, the only sustainable public goods are those that happen to align with someone's commercial interests, which is a narrow band.

Related questions

Why doesn't the market fund public goods? Because public goods are non-excludable. A market depends on the seller being able to charge the buyer. If the seller can't exclude non-payers, they can't capture revenue. The market mechanism breaks.

Could public goods be funded by token-curated registries (TCRs)? Some experiments tried this. None scaled. TCRs produce list maintenance value, not direct goods. Adjacent but different.

What about Bitcoin's transaction fees funding the network? The network IS the public good in Bitcoin's case, and transaction fees are the funding mechanism. Bitcoin's funding model works because users pay to use the network atomically. Most Web3 public goods don't have this fee-on-use property; using Foundry to test a contract doesn't generate any fee to Foundry.

What's the role of foundations going forward? Foundations are the bridge mechanism. They fund public goods directly while QF and RetroPGF mature. Long-term, the goal is to have community-driven mechanisms (QF rounds running continuously, RetroPGF rounds annually) cover most public-goods spend, with foundations handling the long tail and contingencies.

Can VCs fund public goods? Sometimes. Paradigm-funding-Foundry is a VC-funding-public-good arrangement. Works when the VC's broader portfolio captures the value. Doesn't work when the public good is too far from the VC's interests.

How does this affect Web3 founders? Founders building protocols are USERS of public goods. If you ship code, you used Foundry. If you audited, you used Slither. If you read the Solidity docs, you used Ethereum Foundation-funded documentation. Some of the value your protocol creates should flow back to that infrastructure. Direct contribution to grants programs, participating in QF rounds as a donor (not just recipient), and supporting maintainers are all relevant.

Where to see this in Academy

The eMBA Module 3 (Security from Day One) Lesson 2 on security budgets covers protocol-side spending on audits and tooling, including how budget allocation reflects public-goods funding considerations.

The QF mechanics article (linked) covers the mathematical mechanism that makes QF work. This article covers the broader context.

If you want to participate in funding Web3 security as a public good, the most direct routes are:

  • Donate to projects in the next Gitcoin round.
  • Participate in TheDAO QF rounds (the next one will be announced after the May 2026 cycle).
  • If you operate a protocol, allocate part of your treasury to ecosystem-positive grants.

The cumulative effect of many small contributions through these mechanisms is what funds the infrastructure your own protocol depends on. The math is in the QF mechanics article: $5 from many is the most powerful unit of funding in this system.

Tagged

Public GoodsWeb3 FundingOpen Source