Web3 Funding Fatigue: a growing problem

Web3 Funding Fatigue: a growing problem
Investigating the funding fatigue in supply and demand side web3 public goods.
Authors: Vengist + Owocki

TLDR

“Funding fatigue” is a growing issue in Web3 public goods funding.

Grantees experience fatigue from maintaining and promoting multiple grants across platforms, while funders face overwhelming requests and high attention costs in evaluating numerous proposals. The system’s complexity is a barrier for both sides.

Proposed solutions:

  • Aggregation: Aggregating labour supply and demand.
  • Mechanisms: Introducing a “common app” for grantees, interoperable registry protocols, weighted lists for funding, and tools like Drips, 0xsplits, and Protocol Guild Forks to streamline the process.

Introduction

Public goods funding in Web3 is essential but increasingly strained by “funding fatigue.”

Grantees are overwhelmed by managing and promoting multiple grants across fragmented platforms, while funders struggle with an influx of proposals and high computational costs in evaluating them. This imbalance between supply and demand complicates the funding process.

Grantees face visibility challenges, needing constant promotion, while funders must navigate numerous deserving projects with limited resources. The system’s complexity worsens these issues.

Our proposed solution is aggregation. By formalizing grantee applications and funding decisions through tools like a “common app,” registry protocols, and guilds, the process can be simplified, reducing strain on both funders and grantees. Protopian increase in probabilities that desired public goods are realized.

Problems:

Grantee fatigue: supply-side

Grantees have to maintain grants on many diff platforms, across (often) multiple grants. And for QF they have to shill each of them. This is causing grantee fatigue.

Combating the matthew’s effect: intensive effort to become visible in the distributed, complicated public goods funding ecosystem.

Supply fatigue: demand-side

There are DAOs that are overwhelmed with requests for funding from multiple worthy (but attention consuming to validate) causes.

Computational overhead:: observing, orienting, deciding, acting all take too much computation currently for a funder to navigate the public goods funding ecosystem, mismatch of supply and demand. The system is currently very complicated, instead of complex.

Solution

Aggregation of Supply

Grantee Common App - a webapp that allows you to apply to multiple grant programs at once.

Registry Protocol Interop - build an a way to push/pull grants from one registry to another.

Aggregation of Demand

One solution may be Weighted Lists of causes that share sales/marketing/governance responsibilities.

One important primitive here is the self-curating registry (SCRs), popularized by protocol guild. SCRS (and nested SCRS of SCRS) could self to aggregate demand to navigate the funding of the commons.

Useful tools: Drips, 0xsplits, Protocol Guild Forks

Computation savings: Aggregated guilds act as high level strategies that funders can more easily navigate. Each guild serves as specialized tactics down stream of high level strategies. The low governance overhead of the SCRs, simply maintenance of the registry’s weights, allows for low-cost formation and operation of guild-like entities.

Ex. A self-curating registry of ethereum public goods

Because SCRs are just a simple address with governance + splitting logic, they can be chained and nested together in a number of interesting ways.

Let’s imagine creating an SCR to represent Ethereum Public Goods. Instead of individual contributors, we can just add various guilds with reputable contributions to public goods. We would only need to determine the orgs, and the funding flows directly through to their contributors, based on the logic local to their context.

Lets envision what funding flows look like before and after this fatigue issue is solved.

Conclusion

Addressing “funding fatigue” in Web3 public goods funding is critical to ensuring a sustainable ecosystem. The current system overwhelms both grantees and funders, leading to inefficiencies and missed opportunities. By focusing on solutions that aggregate supply and demand locally, both sides can operate with more efficiency and legitimacy. Tools like a “common app” for grantees and funding guilds for funders could reduce complexity, lower computational overhead, and improve the overall flow of funding. Simplifying these processes is key to maintaining the health and vitality of the Web3 public goods ecosystem.

5 Likes

I like the way this streamlines funding. Checking my understanding:

  • In this scenario the Guilds do the shilling and the down stream public goods do the building. This solves the fatigue for the public goods builders but doesn’t it just shift the fatigue to the Guilds?
  • How does this solve the Funder fatigue? Aren’t the Guilds going to be shilling to the funding sources regularly to keep funds flowing?
3 Likes

In case the guilds approach doesn’t take root, another detail piece I’ve seen could be helpful is a portable profiles app/protocol for projects. So it’s easy for projects to own their grant listing and be able to easily pull it in to the specific grants program they’re applying to and make modifications necessary for the specific grant. Ideally that listing could be available across platforms, for example across Gitcoin, Charmverse, Giveth, Octant, etc.

Description of the problem: As the # of Gitcoin rounds has proliferated, when a project is eligible for multiple increasingly specific grant parameters there, they’ve had to write multiple different applications (just Gitcoin rounds, not talking about all the other Web3 grants programs). If there was a way for a project to keep a stored core of what their project does, and add details specific to a specific funding team’s ask, that could streamline efforts from the project’s side.

The reason I think this might be more helpful for a project than say, a Google or Hackmd file with the project’s description, is that it also allows more flexibility when it comes to assigning streaming/drips, and also for any dashboard like apps like allow funders to see across different platforms and filter by stage, scale, focus vertical, region, any other common params.

The UI/api port for the project listing in any funding app would look like "Enter your core project description here or pull in from [The Protocol].

2 Likes

anyone can do the shilling. but there is an opportunity to pool bd/shilling resources at the guild level, so not every project needs a shiller/salesperson.

it makes it easy for anyone to fund an entire category of public goods, instead of having to pick every little project themselves.

1 Like

yes portable profiles are definitely a key piece of the puzzle! i want to fund a “Common App” that can make it easy to transport grant profiles across registries. eventually ill get my life together and write an RFP for this

2 Likes

Its an interesting solution but I think the current problems will just get transferred to the guilds who have less of an incentive to allocate effectively.

That said:

  • Curated Registries are :pinched_fingers:
  • Self service is with agency on the builder sider is good.
  • Building on chain reputation by consistently delivering to spec :pinched_fingers:

In an ideal world:

  • Grantees can publish initiatives they are looking to get funded.
  • Initiatives map to macro themes set by Guild/Network
  • Discovery is facilitated by theme
  • Multiple Funding sources may fund themes or Initiatives
  • Funding sources evaluate delivery
  • Everything is on-chain.
2 Likes

We are trying to solve the portable profile problem at Karma by helping project owners aggregate all their grants, milestones, progress updates and roadmap in one place and onchain (as EAS attestations). See Example here. We have about 3k project profiles and we see hundreds of projects posting updates on a weekly basis and keeping their project/grant updated. I am very interested in building this Common App given lot of the data is already in project’s GAP profile and this is a logical extension of it. Infact, multiple common apps can be built given that this data is all onchain and in clear structured format. Getting all the platforms onboard is the most challenging problem imho.

5 Likes