The write-up below is the result of a Foundation effort to “evaluate Drips as a payout mechanism for enabling greater accountability and reducing the need for trust in how Radworks funds its Orgs,” as referenced in a post from @shelb_ee. By implementing Radworks’ own Drips as the payout mechanism for Radworks grants, the community can reduce risk of Orgs losing or misusing funds. Please provide your feedback on this idea by 14 May.
Currently, authors of Org proposals, which request significant grants from the Radworks Treasury, are trusted, existing contributors. If an Org’s proposal passes on-chain “Submission,” this triggers a one-time transfer of funds (usually USDC) from the Treasury to a multi-sig controlled by the Org.
There are critical issues with this setup - which become unsustainable as our ecosystem and our contributor-base expand:
- The ability to send large amounts of funds to Orgs has relied on the trustworthiness of the recipient and trust given by token holders; as the Radworks ecosystem expands or the structure of Orgs change, this trust dynamic is also impacted and potentially less reliable.
- There is little enforcement that can be exercised if it’s found that the Org is not using funds for the correct purpose (i.e. not in alignment with the Org’s approved proposal to Radworks).
- The severity of the risk of losing funds (due to accidentally draining the multi-sig or funds being stolen) or the multi-sig being targeted becomes higher with larger amounts of funds.
In 2024, we intend to have a new contributor leading an Org, meaning that they will be responsible for an entity in the Radworks ecosystem as well as its grant from the Treasury. That being said, it’s now more critical that we implement a new Radworks grant payout mechanism - by the 2025 Annual Proposal cycle - to enable greater accountability and reduce the need for trust in how Radworks funds its Orgs. Because when Orgs do not clearly spend funds in alignment with their proposal (and Radworks’ mission) or when funds are not secured, this creates risk for all community members and token holders.
We would like to require the use of Drips, a Radworks ecosystem product, to distribute grants from the Radworks Treasury.
At a high-level, this would look like:
- An on-chain “Submission” of an Org proposal includes code that, if approved, triggers the setup of two Drips (controlled by the Radworks Treasury) where the Org’s multi-sig is the “recipient.” The first Drip is to allow for quick accessibility of necessary operation funds, where the second Drip contains the budget for the rest of the year. These Drips would start dripping funds simultaneously:
- Drip 1: this is in the form of a contribution, where the first month’s budget is “given” instantly and available in a lump sum, allowing for quick accessibility of necessary operation funds for bulky month 1 (setup) costs, like annual prepayments.
- Drip 2: this is in the form of a “steam,” dripped over 365 days, and is the rest of the budget for the year.
- Funds are given (one-time) and streamed (over the year) to the Org’s Drips Account. To claim the funds, the Org must collect the already streamed funds via the Drips App, with their multi-sig.
This solution improves 1. security of funds received by the Org from Radworks, ensuring that the funds are being stored securely and accessed with thoughtful security standards and 2. accountability, ensuring that funds are being used in alignment with Radworks’ vision by giving the community power to turn funds off streaming to an Org that is acting outside or against its approved proposal.
Requirements and Recommendations
If we move forward with implementing this new grant-payout mechanism:
- We would need the Drips team to adapt the code used for the “Fund Radworks Dependencies” proposal to incorporate a “give” and “stream” for the Org. This proposal code will then be used by Orgs for their annual proposals when they setup their final “submission” for vote.
- We would need the Drips team to build code that could be used (submitted as part of a governance proposal) “Stop Stream” - i.e. stop a streaming Drip to a misbehaving or compromised Org.
From a practical perspective, we would recommend (though this will be up to each Org to decide) the following to Orgs for accounting for this flow of funds:
- If the Org uses a Safe multi-sig, there is a Safe App for making this interaction with Drips easier.
- USDC-based grants could be booked using the last 30 days’ average closing price based on coinmarketcap.com.
- RAD-based grants could be booked using the last 30 days’ average closing price based on coinmarketcap.com.
- If Orgs collect their dripped funds monthly:
- This could be done on either the last day of month or 1st day of the month - to tie in with having funds ready & transferred to fiat, if needed, for the mid-month payrun.
- This would minimize gas fee costs.
Next Steps
- We would like additional thoughts from the community about this use of Drips by 14 May.
- We will add a poll to this forum post on 14 May (with a deadline of 21 May) to see if there is general consensus for this idea.
- If there is general consensus for this idea:
- This will be included as part of a forthcoming proposal for Org Requirements, to be implemented in time for the 2025 Annual Proposal cycle.
- @shelb_ee will start working with @lftherios and Drips Team to adapt the code for the proposal “submission” and build the Stop-Stream code by 1 August 2024.
