The proposal inverter is a funding primitive that enables multiple groups or individuals to collaborate on common proposals. It inverts the typical Proposal / DAO relationship to facilitate cross-DAO initiatives, such as co-funding shared research.
The proposal inverter 'inverts' the DAO-proposal relationship. Such that, instead of having many proposals for a single DAO, we will have many DAOs for a single proposal. This enables the collaborative funding of proposals that benefit multiple DAOs throughout the ecosystem. You can think of this as solving the byzantine generals' problem for the collective funding of public goods for DAOs.
Ultimately, it is proposed as a lower overhead funding mechanism for continuous work that delivers shared benefits to multiple groups.
Proposal Inverter Mechanism Framework 0.1
The nascency of DAO tools has developed somewhat siloed, non-standardized proposal systems that incur large transaction costs in information and attention from their contributors.
A future of increasing DAO2DAO interaction patterns will require more seamless collaboration on joint initiatives, particularly those with shared benefits like open-source research or other public goods. It is to this end we consider the “Proposal Inverter” mechanism. The proposal inverter is a funding primitive that enables multiple groups or individuals to collaborate on common proposals, inverting the typical Proposal/DAO relationship to facilitate cross-DAO initiatives, such as co-funding shared research, which will help DAOs to scale in a more efficient way.
Proposal Inverter Mechanism Framework 0.2
Our aim with the Proposal Inverter is to make it easier to co-fund and collaborate on important research initiatives while cutting down on administrative overhead. We should continue to build and iterate tools that make it easier to collectively fund public goods. Within our own DAO ecosystems, public goods like research, education, and community building are particularly important because we can use them to further leverage the effectiveness of DAOs as new institutional tools for social benefit.
Prime has identified several stacked primitives within this one assembled mechanism, which we will discuss in further detail below. We believe these primitives and mechanisms could be combined in multiple ways to form varying types of Proposal Inverters for differing use cases.
Level 1: Basic “Flow Wallets”
This first primitive is a wallet that acts as a simple fund splitter, allocating its entire funds all at once **among whitelisted contractors according to a static allocation policy. This would allow incoming payments to be split among N contractors per the agreed-upon policy. The term “flow wallet” stuck in our discussions, as this primitive would essentially turn funds in these wallets from stocks into flows, fundamentally changing their nature. Tools of interest that already exhibit some of this functionality include the Disperse App.
Example: Three trusted contractors of the DAO split a one-time $5000 payment according to their previously agreed static allocation policy of 50%, 25%, and 25% of the total funds, earning them $2500, $1250 and $1250 respectively.
Level 2: Rate-limited “Flow Wallets”
This primitive combines the simple fund-splitting Flow Wallet introduced above with a standing reserve and a “leaky integrator.)” function to include temporal flows into the payments mechanism. You can think of a leaky integrator like a bucket of water with a small hole in the bottom, or a dam that rate-limits the outflow of water. New water (i.e. funds from a DAO) can flow into the top of the bucket/dam, which flows out over time according to the static allocation policy decided by contractors. Tools of interest that already exhibit some of this functionality include Sablier, Superfluid, and the Commune App.
Example: Three trusted contractors of the DAO split 20% of the total funds available per month according to their previously agreed static allocation policy of 50%, 25%, and 25% of the monthly funds. If total funds available were $25,000, the monthly outflow would be $5000 and the allocation per contractor would be $2500, $1250 and $1250 respectively.
Level 3: Rate-limited Dynamic Allocation “Flow Wallets”
This third mechanism integrates the functionality of the previous two primitives, as well as includes a dynamic allocation policy through the introduction of a bonding curve, which manages access rights to a portion of the monthly funds allocation. This mechanism enables a dynamic allocation policy among available contractors, as well as revenue sharing agreements and more complex interactions between DAOs, contractors, and even external agents who wish to delegate tokens to signal support for work they see as valuable. In a proposal with productive outputs, these staking agents could potentially also receive a portion of the revenue generated by those outputs. Tools of interest that already exhibit some of this functionality include The Graph’s delegator role and this new cadCAD model on revenue-sharing bonding curves
Example: Three trusted contractors of the DAO split 20% of the total funds available per month according to the dynamic allocation policy of the bonding curve. Contractor 1 holds 50% of the bonding curve tokens, contractor 2 holds 25% and contractor 3 holds 25%. If total funds available were $25,000, the monthly outflow would be $5000 and the allocation per contractor would be $2500, $1250, and $1250 respectively. Note that the bonding curve greatly reduces the negotiation barrier to more entrants, and also encourages discovery and financial support of productive research teams (in this context).