Towards a more flexible proposal deposit system.

[0xekez]

This proposes the creation of a pre-propose module that interfaces with proposal modules. When attached, proposal modules will only allow proposals to be created via that module. The module listens for proposal status change hooks to release deposits when needed.

Despite being easy to explain in natural language, an actual implementation of proposal deposits can be quite complex. To name a few things:

1. If proposal deposits are not refunded on failure, they must be returned to the DAO on proposal close, and not kept in the proposal module.
2. Changing proposal deposit behavior, or adding new denominations requires a good amount of code that touches many sections of a proposal module.
3. Proposal deposit code is largely identical across modules.

Additionally, extending our current system to support more sophisticated pre-proposal requirements is non-trivial because logic needs to be duplicated across modules.

To address these issues, I propose that we move all pre-proposal checks into a new module interface we call cw-dao-pre-propose. We can then modify our proposal modules so that an enum describes who may submit a proposal:

enum WhoMayPropse {
	Anyone {},
	Module { address: String },
}

In the Anyone {} case, any address may create a proposal to the DAO. In the Module {} case, only the specified address may do so. Proposal modules will set this globally in their Config struct and return this information in response to GetConfig {} queries.

The ExecuteMsg::Propose variant should then be extended with a proposer field which may only be set if a module is configured to create proposals:

pub enum ExecuteMsg {
    /// Creates a proposal in the proposal module.
    Propose {
        /// The title of the proposal.
        title: String,
        /// A description of the proposal.
        description: String,
        /// The messages that should be executed in response to this
        /// proposal passing.
        msgs: Vec<CosmosMsg<Empty>>,
	/// The address that is proposing this proposal. Setting this
	/// when the module is configured to allow anyone to create a
	/// proposal will error.
	proposer: Option<String>
    },
	// ...
}

Setting a module as the proposer for a module will add that address to the module's proposal hook receivers. If the module ever errors handling a proposal status change hook, the WhoMayPropose enum will automatically fall back to the Anyone {} state to prevent a bad pre-propose module from locking a DAO.

With these changes we will remove all proposal deposit logic from proposal modules. Because the pre-propose module receives proposal status change updates, and controls who may create a proposal it can issue refunds when proposals complete, and impose arbitrary constraints on proposal creation.

Building draft proposals with this design.

Draft proposals come pretty easily with this model. We write a pre-propose module that allows new proposals to be created inside of it and allows editing of those proposals. Once the proposal is deemed ready, it is proposed in the parent proposal module.

Accepting native tokens for proposal deposits with this design.

This is just a pre-propose module that checks the funds field of a message before passing it along to the main DAO.

Accepting cw20 tokens for proposal deposits with this design.

This is functionally the same as our current logic. Proposers will give an allowance to the pre-propose module, and the pre-propose module will transfer that allowance to itself on proposal creation.

Security concerns.

This design fails open meaning that a buggy or compromised deposit module will not lock the DAO. Failing open here is desirable as proposal deposits function primarily as an incentive to create good proposals and not as a critical security feature of DAOs.

Frontend integration.

This will require changes in the DAO DAO frontend on the query side, but for an initial implementation that has feature-parity with our current deposit logic this will not require any cosmetic changes or new designs.

Implementation

Proposal modules need to be instantiatable with a pre-propose module. This will require moving the ModuleInstantiateInfo struct to a shared package.

Pre propose module needs to be agnostic to the actual structure of the propose execute message. Modules should store that in a Binary object submitted by the proposer. This can still support editing for drafts later because the Binary that gets submitted can be updated.

[0xekez]

Should think about if we want to move IsActive {} checks into the pre-propose module as well..

If the pre-propose module is removed if it fails to handle a hook. This opens an attack vector where someone may attempt to get the pre-propose module into a bad state, causing it to be removed and the active check to be removed as well.

If we choose to leave active checks inside of individual modules it doesn't open that path. It may be nice to keep security critical logic out of these deposit modules.

[0xekez]

Also investigate what the intermediate state should be while we're replacing or setting the pre-propose module. If we set it to ProposalCreationPolicy::Anyone {} there is a moment where anything fired off as a part of the pre-propose module instantiation can create a proposal on the DAO. This may be bad - this may be OK.

[0xekez]

For deposit modules, I think these are going to end up sharing a lot of code so I think we should take the cw721-base approach and build a generic base contract (cw-pre-propose-base) that others can plug into.

This contract will have the same ExecuteExt, QueryExt, and InstantiateExt generics as cw721-base. We'll differ in that we'll swap out the MintExt generic with a ProposalMsg. In the case of cw-proposal-multiple this will be a MultipleChoiceProposal and in the case of cw-proposal-single this will be a SingleChoiceProposal.

To start, our goal is that we can use this base contract to implement:

1. The existing deposit system for cw-proposal-single.
2. The existing deposit system for cw-proposal-multiple.
3. A deposit system like the one ION DAO has implemented which allows for multiple addresses to contribute to paying a proposal deposit.

Across all of these, the shared logic is:

1. If configured, proposal deposits should be returned on the proposal failing and otherwise be sent to the DAO.
2. Proposal deposits should be returned on proposals succeding.
3. Optionally, only members with staked tokens may create proposals.
4. Deposits can be paid in both native and cw20 tokens.

My plan is to implement this functionality entirely in the base contract. To support (3) above, that contract will need to override the Propose method on the deposit contracts so that deposits can be collected gradually over time. Otherwise, it'll be able to reuse all of the refund and configuration logic that happens during instantiation and upon receiving proposal hooks.

[JakeHartnell]

❤️

[0xekez]

Here is a diagram of the design as of now:

Some thoughts:

1. We do not guarantee currently that the deposit module is the first receiver of the new proposal hook. If a hook before us were to update the deposit information for the pre-propose module, snapshotting the deposit state would fail. We need to do some deep thinking here if this is possible to do from a hook. My instinct is that if a hook receiver could modify the configuration of the deposit module this would break other security assumptions we make or require that the hook has entirely compromised the DAO anyhow (needs to ram through a proposal to update the deposit config in a single TX => you're pwned anyway).
2. We need to think about the behavior of these modules if one does malfunction or get removed. What happens to deposits currently inside of it? Modules should likely implement a withdraw method to allow removing the funds.