Have a streaming budget for public goods instead of a fixed one

[AvsA]

This is something I think it’s a pain for Gitcoin: because they have grants rounds, every round they need to rally everyone up to decide which projects get grants. This requires a massive effort on having people donate and vote every round. This is also bad for projects: if they are sucessful they need votes and grants every year.

Imagine that instead of having your current job, the default would be that you’d get fired every year and then have to get rehired again, from scratch. Development is not a seasonal work, like fruit picking (I bet even most fruit pickers would prefer not to have to search a new job every season!).

So proposal: use the budget for the Public Goods working group as a series of streams. The working group still needs to ask for the DAO to get a new budget every year, but that budget then is immediately converted into a stream.

Jobs on that stream aren’t single grants, but rather streams. Many people make streaming proposals and all of them are voted. Every voter picks a number between 1 (really support) to -1 (really opposes) for every proposal and submits all the votes at once. Their choices are then multiplied by their vote weight and summed, and ordered in a list. The ones that makes the cut become active streams.

Here’s an example UI I cooked up: here a vote is simply a five choice between .

Untitled

This way, new proposals can be made all the time and things that aren’t working can be “fired” at any moment. In order to create a bit more stability for the person under an active proposal, each proposal could be overfunded by 8% that would go to a “severance buffer”. Meaning that someone that had worked for a year, once they were fired, would still get paid for another 4 weeks so they could finish their jobs properly.

I shared this prototype with the superfluid people, they are interested in helping build such tool for ENS.

[alisha.eth]

A streaming experiment could be run within a subgroup of the public goods working group, but it is unlikely that the public goods working group would approve the (entire) budget for this purpose.

From what I have observed, the issue with using open voting to fund public goods projects is that the people voting don’t typically have a good understanding of what public goods are. This isn’t necessarily because voters don’t understand the basic characteristics of public goods, being non-rivalrous and non-excludable, but rather that the definition of public goods is not set in web3.

For the purposes of grants rounds, Gitcoin hasn’t adopted a single definition of public goods. Instead, they use voting to show what the community values and distribute matching pool funds accordingly.

Article 3 of the Constitution states that income not used to fund and improve ENS can “be used to fund other public goods within web3”. Before the Public Goods working group can distribute funds to projects deemed to be public goods in web3, it seems prudent to first develop some sort of consensus around what public goods are and what types of public goods should be funded by the ENS DAO.

Questions I feel the PG working group should answer before funding any project include:

1. What are public goods within web3?
2. What types of public goods should the ENS DAO be funding?
3. How is the DAO going to fund those public goods?

Once we have established what public goods are within web3, we then need to develop strategies to distribute funds. A forward-looking model, like streaming, is certainly an option. However, to the extent that streams would need to be topped up at certain intervals and projects can be “fired” at any moment, I question whether this strategy offers more certainty to recipients than something like a Gitcoin Grants round every few months. An alternative method to distribute funds is the retroactive funding model used by Optimism PBC.

Whichever method(s) the ENS DAO chooses to experiment with will likely be decided following discussions within the working group that are able to take place once the definition of a ‘public good within web3’ has been established by the public goods working group.

[matoken.eth]

Can we have a clarification of whether this proposal is A: to use streaming funding using existing tools like superfluid, or B: the ENS DAO to fund building such a tool/integration? This question is more about “How” to distribute funds than “What” to fund. The discussion of “What” is important if the topic was meant for B, but it’s a bit out of scope in this discussion if meant for A

[nick.eth]

I like the idea of streaming funds for many applications - and there are a couple of existing solutions we could try this out with. One thing to bear in mind is that most applications won’t work with just streaming funds; they will need a lump sum to get started, and then streaming funds for ongoing operations.

[AvsA]

@alisha.eth

A streaming experiment could be run within a subgroup of the public goods working group, but it is unlikely that the public goods working group would approve the (entire) budget for this purpose.

Yes, this isn’t a specific proposal for funds yet, this is the start of a discussion that I believe streams to be superior than single grants. Maybe this would not be ideal for the public good working group, but rather could work in another area, for example as means for the DAO to pay for the services of TrueNames LLC, Delegates, or other “service providers”.

@alisha.eth

However, to the extent that streams would need to be topped up at certain intervals and projects can be “fired” at any moment, I question whether this strategy offers more certainty to recipients than something like a Gitcoin Grants round every few months.

We are in the discussion phase, of course. The comparison here would be to be a freelancer versus an employee (and I use these terms as comparisons, not in any legal sense that these would be employees). If you are a freelancer you are hired for specific jobs with a specific duration, and then yo have to get the next one. As someone who hires others, you keep changing the providers. A salaried employee is hired once and has some sort of expectation that he will be working for some time on that job. There are set expectations: if they do a bad job, or if the overall market changes and they see the next year budget will not be as big, they can have expectations on either they will continue to work there. Having the buffer would be an interesting way of getting some sense of permanence: you know that for every 12 months your contract is active, you get another month of “notice/severance” for which you are guaranteed to be paid.

@matoken.eth

A: to use streaming funding using existing tools like superfluid, or B: the ENS DAO to fund building such a tool/integration?

There are tools for streaming but none to vote on streamings as governance process. I am not asking for the ENS DAO to create it. I am willing to fund it out of pocket with the help of Superfluid team–what I am asking is: if this was to be build, would the ENS community be interested in using it?

@nick.eth

One thing to bear in mind is that most applications won’t work with just streaming funds; they will need a lump sum to get started, and then streaming funds for ongoing operations.

It depends on the use. If it’s a grant, then that is true. But if you are hiring someone for ongoing work (let’s say to pay someone to make memes all day, or a lawyer, or a team of moderators for something–in superfluid streams can be daisy chained) then it makes sense for it to be just a stream.

Of course, a grant can be delivered by giving a lump sum plus stream, but I’m more interested in the governance side than the actual delivery method: a system in which instead of a time limited voting to either hire or fire some service, the vote is a continuous delegation of support, in which you slowly move up or down.

[nick.eth]

@AvsA

There are tools for streaming but none to vote on streamings as governance process. I am not asking for the ENS DAO to create it. I am willing to fund it out of pocket with the help of Superfluid team–what I am asking is: if this was to be build, would the ENS community be interested in using it?

I would love to see something like this, personally. One option to consider is that rather than a threshold vote - x gets funding or doesn’t - we could use continuous voting to allow people to decide how to apportion the funds proportionally on an ongoing basis.

@AvsA

It depends on the use. If it’s a grant, then that is true. But if you are hiring someone for ongoing work (let’s say to pay someone to make memes all day, or a lawyer, or a team of moderators for something–in superfluid streams can be daisy chained) then it makes sense for it to be just a stream.

Even a workstream will often have up-front lump-sum costs, however.

[AvsA]

@nick.eth

we could use continuous voting to allow people to decide how to apportion the funds proportionally on an ongoing basis.

But that’s exactly what this is, isn’t it? The only threshold I have is the necessary budget. If we have $10k per month as budget, then you add all the requested budget for the top supported projects until it reaches that limit.

On up front costs: the code could easily be changed to have a sort of upfront cost, but I’d personally prefer if the limit between on and off was not as clear. For example if the main budget was not fixed but based on Yield farming, then there could be a “yellow area” in which streams were some months active and others not. Thanks to the buffer, that would not mean those projects didn’t get streamed, just that they knew they might be ending soon. But maybe that’s too much for some people.

[fig]

@AvsA this was really fun to play with and think about more.

Seems like “streaming” the budget can create clear priority on different builds / projects and allow for uninterrupted progress.

How would this tool affect current governance models? Would it make Snapshot obsolete?

Also - what is the threshold to force something out of budget? How many downvotes (or negative votes) does it require?

[Alex-moore2021]

Streaming funds is something I too am a proponent of. However, I’ve witnessed many projects though (gitcoin included) be routed by bad actors. My take on this is streaming is good but automation is bad. There are certain things in this space that require a human touch. Specifically giving people money for work performed the trick is to prevent the reviewers of quality from becoming gatekeepers. My take is this works in a hive manner, where the stewards are monitoring the work of teams and teams are monitoring the work of stewards. Would also like to see cross team/steward reviews. Data is power and all of this creates a lot of data that can help us make decisions.

[earthwindfirewater]

Hi everyone! I’ve really enjoyed following the thoughtful discussion here around the tradeoffs between streaming payments and grants for DAOs looking to fund longer-term programs.

As you evaluate possible solutions, please consider Drips, which is a new protocol built on Ethereum for managing recurring/streaming payments, of exactly the sort you’re describing. With Drips, DAOs can create streaming DAI payments on Ethereum mainnet (and soon Polygon) without having to use wrapped tokens or trust any 3rd parties. Here’s a Mirror post about Drips if you’re interested in more details.

I’m a member of the Drips core team and we’re talking with a number of DAOs right now around exactly the use case described here, so I’d be happy to answer any questions you might have.

[Elle97]

Another problem Gitcoin faces with funding public goods is the means to ensure the projects funded by the public actually live up-to their potential and keep building after receiving the grants.
Without the DAO being a centra-intermediary how do you ensure that these sub groups are incentivized enough to keep building the public goods?maybe reward them retroactively instead?