Multiple Choice Veto

contracts/external/dao-migrator/schema/dao-migrator.json

@@ -376,7 +376,7 @@
             "type": "boolean"
           },
           "timelock_duration": {
-            "description": "The time duration to delay proposal execution for.",
+            "description": "The time duration to lock a proposal for after its expiration to allow the vetoer to veto.",
             "allOf": [
               {
                 "$ref": "#/definitions/Duration"
@@ -770,7 +770,7 @@
             "type": "boolean"
           },
           "timelock_duration": {
-            "description": "The time duration to delay proposal execution for.",
+            "description": "The time duration to lock a proposal for after its expiration to allow the vetoer to veto.",
             "allOf": [
               {
                 "$ref": "#/definitions/Duration"

contracts/pre-propose/dao-pre-propose-multiple/src/tests.rs

@@ -77,6 +77,7 @@ fn get_default_proposal_module_instantiate(
             },
         },
         close_proposal_on_execution_failure: false,
+        veto: None,
     }
 }
 
@@ -1065,6 +1066,7 @@ fn test_instantiate_with_zero_native_deposit() {
                 },
             },
             close_proposal_on_execution_failure: false,
+            veto: None,
         }
     };
 
@@ -1127,6 +1129,7 @@ fn test_instantiate_with_zero_cw20_deposit() {
                 },
             },
             close_proposal_on_execution_failure: false,
+            veto: None,
         }
     };
 

contracts/proposal/dao-proposal-multiple/README.md

@@ -52,3 +52,55 @@ handling a hook.
 The proposals may be configured to allow revoting.
 In such cases, users are able to change their vote as long as the proposal is still open.
 Revoting for the currently cast option will return an error.
+
+## Veto
+
+Proposals may be configured with an optional `VetoConfig` - a configuration describing
+the veto flow.
+
+VetoConfig timelock period enables a party (such as an oversight committee DAO)
+to hold the main DAO accountable by vetoing proposals once (and potentially
+before) they are passed for a given timelock period.
+
+No actions from DAO members are allowed during the timelock period.
+
+After the timelock expires, the proposal can be executed normally.
+
+`VetoConfig` contains the following fields:
+
+### `timelock_duration`
+
+Timelock duration (`cw_utils::Duration`) describes the duration of timelock
+in blocks or seconds.
+
+The delay duration is added to the proposal's expiration to get the timelock
+expiration (`Expiration`) used for the new proposal state of `VetoTimelock {
+expiration: Expiration }`.
+
+If the vetoer address is another DAO, this duration should be carefully
+considered based on of the vetoer DAO's voting period.
+
+### `vetoer`
+
+Vetoer (`String`) is the address of the account allowed to veto the proposals
+that are in `VetoTimelock` state.
+
+Vetoer address can be updated via a regular proposal config update.
+
+If you want the `vetoer` role to be shared between multiple organizations or
+individuals, a
+[cw1-whitelist](https://github.com/CosmWasm/cw-plus/tree/main/contracts/cw1-whitelist)
+contract address can be used to allow multiple accounts to veto the prop.
+
+### `early_execute`
+
+Early execute (`bool`) is a flag used to indicate whether the vetoer can execute
+the proposals before the timelock period is expired. The proposals still need to
+be passed and in the `VetoTimelock` state in order for this to be possible. This
+may prevent the veto flow from consistently lengthening the governance process.
+
+### `veto_before_passed`
+
+Veto before passed (`bool`) is a flag used to indicate whether the vetoer
+can veto a proposal before it passes. Votes may still be cast until the
+specified proposal expiration, even once vetoed.