Pre propose module design

Pre-propose modules provide a way to gate proposal creation. They may, for example:

• require a deposit to create a proposal;
• only allow DAO members to create proposals;
• or, require a non-refundable payment to create a proposal.

Any gating you would like to apply to proposal creation can be implemented as a pre-propose module.

cwd-pre-propose-base

In packages/cwd-pre-propose-base we provide a default pre-propose module that allows for the features listed in the examples above.

Here is a flowchart describing the proposal lifecycle from the perspective of that module:

In order to integrate this pre-propose module with a proposal module the proposal module ought to fire off hook messages on proposal completion and creation. Those messages ought to take the form:

pub enum PreProposeHooks {
    ProposalCreatedHook { proposal_id: u64, proposer: String },
}

Failure handling

If a pre-propose module ever fails to process one of the above hooks, the associated proposal module ought to evict the pre-propose module and allow anyone to create a proposal. This means that pre-propose modules, for the most part, fail open. Meaning that a bug that causes a panic or otherwise failed transaction in a pre-propose module ought not to lock the DAO or prevent proposals from being created.

Generally speaking, this eviction should be done by dispatching hooks as submessages that reply if they error, and then evicting the problematic hook receiver in the reply method.

cwd-pre-propose-base implements withdrawal functionality so that, in the event of a failure, the DAO may withdraw deposits in the module and return them to their intended recipients.