ExpansionDAO

Author

floar.eth#4492

Description

This proposal aims to set up a structure and protocols to use for future payments made from the DAO. It classifies three different situations and proposes a payment structure and protocol for each. This should help the DAO making those decisions faster in the future, as well as implementing a certain protection around the treasury, given the anonymous nature of this space.

Category: Treasury

Status: New

Motivation

Currently payments from the DAO to collaborator’s, paid members of the community and one time payments are decided on the fly. This proposal aims to unify it and provide a framework to execute on.

Key Terms / Background (optional)

Sablier: Real time payment protocol, see here for an in-depth description: https://discord.com/channels/864147158777462854/961505506202095636/1012441319194501193

Details

This proposal differentiates between three types of payments:

1. Continuous payments, mostly tied to a time commitment. Examples are our monthly payments for CMO and mods, preparation for a workshop, holding weekly twitter spaces and so forth.
2. One time payments, tied to deliverables and one-off actions. Examples are: Donations, purchase of tokens, fees for speakers etc.
3. Royalty based payments

The proposal is to use Sablier for all payments of category 1). With one time payments for a time based engagement we are in the pickle of timing it. Provide it at the end of the engagement is good for the DAO (Making sure the DAO actually received the deliverable) but bad for the receiver (Needs to go into concession). Paying at the beginning of the engagement reverts this problem, giving all the benefit to the receiver (as blockchain payments are final) and all the downsides to the DAO. Sablier solves this problem by providing a continuous payment stream, starting from the beginning of the engagement. The receiver has the benefit of receiving value straight away and getting an exact idea of when funds will be available, the DAO enjoys the extra protection that a stream could be canceled, in case the situation demands for it. For type 2) payments this proposal indicates that payment should be received on delivery, with an option to convert a small part into a streaming payment, in case prior work is needed / this makes sense. (Example, someone makes a proposal for a workshop for 1Eth, that gets accepted. They will be able to receive 25% (?) streamed beforehand for preparing the workshop, the rest will be received when the workshop is held.)

We only have a single type 3 payment, which is the %-share of royalties paid to the CMO. The proposal would be to implement a smart contract splitter, that would receive the royalties as an escrow and split them between receiving parties. If we feel like this makes sense there will most likely be a follow up for implementation of this.

Implementation

If passed future payments are to be aligned with this framework. Rules and guidance will be put into #✨│dao-overview

Timeline

Cost

None (excluding development and deployment of the splitter contract for now)