Proposal Module Message Limits

[JakeHartnell]

Currently, proposal modules that are enabled on a DAO can execute any message. This was a natural first step, but limitations on messages that can be executed via proposal modules can be very useful.

Polkadot's OpenGov has the notion of Origins and Tracks, the idea behind that you should have different governance processes and settings for different types of proposals (i.e. software upgrade should have a different process than treasury spend).

This can be sort of done today with proposal modules (and pre-propose modules), but what's missing is being able to scope the permissions for the type of message a proposal module is able to execute.

There are many forms these permissions might take, for example:

• Specifying exact messages that are allowed to be executed.
• Spending limitations
• Types of messages
• Particular accounts or smart contracts allowed to be interacted with
• allow and deny variants

Obviously, this will need design. There are many in the wild examples to pull inspiration from including Authz.

Ideally as part of the create proposal flow, any messages should be validated to ensure the proposal module has permissions to execute them.

Some user stories for inspiration:

• As a DAO, we would like to have a SubDAO where users can only submit text proposals, no smart contract messages.
• As a DAO with a treasury, we would like to set limits on the maximum amount that can be spent from that treasury for any given prop (or over a given time period).
• As a an NFT DAO, we would like to have a applications SubDAO where the only action is to mint an NFT.
• As a DAO with a constitution, we want to enforce that only the proposal module dedicated to the constitution can update it, and that no other proposal modules can touch it.
• As DAO managing a DeFi protocol, we would like to create different governance processes or "tracks" for different types of decisions and to ensure that economics oriented tracks cannot interfere with the scope technical tracks (and visa versa).

[JakeHartnell]

Strawman implementation idea... the first version can be very simple, the intention of this is not to recreate Authz but to build a better user experience around DAOs (i.e. I want a DAO that only does one thing).

We could make a dao-voting::msg_limits module that would handle valdiation logic and have some standardized types.

Limit the number of messages, specify an exact message, or specified allowed keys for generic CosmWasm smart contract calls.

#[cw_serde]
pub struct MsgLimit {
  /// Specify exact messages a DAO can execute
  /// If set to None only `count` will be used for validation
  allowed_msgs: Option<Vec<AllowedMsg>>,
  /// The number of messages that can be included in a prop?
  /// Must be greater than zero?
  count: u8
}

#[cw_serde]
pub enum AllowedMsg {
    /// An exact message to call, the message must match this message
    Exact(CosmosMsg),
    /// A generic smart contract message that only checks the method
    /// being called, allowing for the proposer to customize the contents /// of the message.
    GenericWasmExecuteMsg {
      /// The smart contract this message is intended for
      contract: Option<String>,
      /// Validation deserializes the binary and checks key matches
      key: String,
      /// Specify funds a DAO proposal can't exceed
      funds: Option<Vec<Coin>>,
    }
}

Validation:

• Check message count does not exceed limit or count
• For each allowed message, try to see if it's a match or is valid smart contract call (with the right key), don't throw errors unless there are no matches for eash message
• If there is a successful match, proceed validating other messages

Questions:

• Do this in pre-propose or proposal modules? Perhaps pre-propose-base would lead to the most code re-use?

[JakeHartnell]

Might also be cool to add a custom validation hook, which could be a separate smart contract that does custom validation.