Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proposal Module Message Limits #694

Open
JakeHartnell opened this issue Apr 10, 2023 · 2 comments · May be fixed by #872
Open

Proposal Module Message Limits #694

JakeHartnell opened this issue Apr 10, 2023 · 2 comments · May be fixed by #872
Labels
feature A new exciting feature.
Milestone
v3.0

Comments

@JakeHartnell
Copy link
Member

JakeHartnell commented Apr 10, 2023 •
edited
Loading

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 JakeHartnell added the 2.5 Targeted for v2.5.0 release label Jun 27, 2023
@JakeHartnell JakeHartnell added this to the v2.2 milestone Jun 27, 2023
@JakeHartnell JakeHartnell removed the 2.5 Targeted for v2.5.0 release label Aug 18, 2023
@JakeHartnell JakeHartnell removed this from the v2.5 milestone Aug 18, 2023
@JakeHartnell JakeHartnell added the improvement adds a new feature label Aug 18, 2023
@JakeHartnell
Copy link
Member Author

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 JakeHartnell added this to the v3.0 milestone Aug 30, 2023
@JakeHartnell JakeHartnell mentioned this issue Aug 30, 2023
Closed
@JakeHartnell JakeHartnell added feature A new exciting feature. and removed improvement adds a new feature labels Aug 30, 2023
@JakeHartnell
Copy link
Member Author

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

@JakeHartnell JakeHartnell changed the title Proposal message limits Proposal Module Message Limits Apr 3, 2024
@JakeHartnell JakeHartnell linked a pull request Aug 2, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature A new exciting feature.
Projects
None yet
Milestone
v3.0
Development

Successfully merging a pull request may close this issue.

WIP Msg filter DA0-DA0/dao-contracts
1 participant
@JakeHartnell