This post aims to introduce people to Fluid Proposals, a new type of Conviction Proposal intended to improve how we, and other gardens, work together.

First, a bit of context…

At the core of what 1Hive has always been is an attempt to make truly decentralized autonomous organizations a reality. When I think about what a truly decentralized autonomous organization looks like, I think of a lot of individuals largely acting independently but aligned around and pursuing some common goal.

This ideal is why conviction voting doesn’t require a majority vote to approve funding from the common pool, it allows minority holders to influence how resources are utilized without having to come to consensus with the majority. On the one hand this can manifest as chaotic and as a lack of direction, on the other hand it is what makes it possible for contributors to act in a decentralized and autonomous fashion, it’s what makes 1Hive a DAO and not a glorified multisig.

In practice, most of the proposals we have seen since the introduction of conviction voting have been to fund ongoing work done by contributors. In practice this has meant contributors have had to periodically make proposals to get funding, and each proposal takes time and effort from both the proposers as well as the rest of the community to review, discuss, and choose to support. Often these discussions have become heated and stressful, which isn’t that surprising since compensation is always a sensitive topic. The binary (funded/not funded) outcomes make these discussions even more challenging. Sometimes, having a discrete funding outcome makes sense, but oftentimes it feels like a more continuous approach would just be more effective…

That line of thinking led to a hackathon project called Osmotic Funding and the idea of Fluid Proposals in Gardens. The Blossoms labs team has continued to work on the project and has recently started integration testing on Gnosis, so we are at a point where we can actually start trying this out.

A quick overview of how these fluid proposals work

Fluid Proposals leverage the existing “Signaling Proposal” feature of Gardens and a middleware contract which manages Superfluid streams from a Superfluid Aragon app in a separate Aragon organization. This means, we don’t need to make any changes to the 1Hive organization itself in order to start using the feature, we just need to send Honey to an address and use a version of the gardens frontend which supports Fluid proposals.

From a contributor perspective, they will be able to create a fluid proposal to stream honey from the common pool, and the rate of the flow will be determined based on the current level of support their proposal has. The hope is that this will reduce stress and overhead of periodic proposals from contributors, and make it easier for people to modulate their support for contributors without it being an all-or-none decision.

Additionally, with this implementation we are not streaming honey directly from the common pool but moving it into the superfluid protocol. We can think of this like a streaming buffer, which we will need to refill as funds are streamed. Initially we can simply fund this with a funding proposal, but if the pilot goes well we likely would want to improve and automate the process of refilling the buffer which will require some additional engineering and a TAO vote.

Flow rate calculations

The flow rate calculations has separate conviction params, which will allow us to determine the relationship between the common pool, accumulated stake on proposals, and the flow rate.

• decay → Used to determine the rate at which conviction accumulates and decays when stake is added or removed.  We can think about it in terms of a half-life, where conviction will double or half each X number of days until it reaches the target level of conviction.

• maxRatio → Used to determine the maximum ratio of common pool funds that can be streamed per month per proposal.

• minStakeRatio → Equivalent to the minStakeRatio param in conviction voting, it ensures there is a minimum amount of stake per proposal, relative to the total support in all proposals, to start flowing funds.

For the math geek 🤓

We analyzed the flow settings we wanted to start the Pilot with. If you are interested in play with the params and provide feedback, here is the desmos we used: Fluid Proposals

The first 3 params are the ones interesting to adjust, those are:

• F → The maximum amount of tokens that can flow to a proposal

• G → The minimum amount of tokens staked on a proposal to start the stream of funds

• s → The number of tokens staked on a proposal

Then the red line is the target rate per month. And the green line is the current rate per month.

The X axis is express on seconds. We calculate the decay so the flow rate reach 50% of target in 10 days (864000 seconds). Here it is a second desmos with those calculations: Conviction Decay

The initial Flow Settings we will start with are:

• decay → 10 days to reach 50% of target rate

• maxRatio (aka maximum amount of tokens flowing per month on a single proposal) → 5% of Common Pool (~430 tokens)

• minStakeRatio (aka minimum amount of stake a proposal need to start flowing funds) → 2.5% of Total Support (~140 tokens)

Note that 5% of Common Pool for maxRatio sound like a lot. But in fact if you review with the desmos using realistic amount of tokens staked on a proposal (~ 350-850 tokens) the flow rate per month will be 2-3% of Common Pool. Getting to the 5% mark get a lot harder.

Call to action

If the pilot prove to be successful we intended to integrate fluid proposals more tightly with Gardens so others communities can also leverage funding streams.

In the mean time we invite 1Hive contributors to start creating the first fluid proposals.

If you want to learn more about Gardens:

• Check the documentation

• Join our Discord channel

• Try it out