⚠️ No Changeset found

Latest commit: e56c8b2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

#5301

Looks good other than some comments. Would it make sense to call it something like GovernorCancelCouncil to be more explicit? I could imagine daos having multiple different "security" related councils.

Compound Governance already has a feature like this where the council is called the proposalGuardian. If we aren't too against the wording we could reuse it.

https://github.com/compound-finance/compound-governance/blob/15614c913d548c7a7a4a3f3543069562d120eb7d/contracts/GovernorBravoDelegate.sol#L768-L784

What's the rationale to allow a proposer to cancel a proposal at any time?

I think the contract would be simpler if it just focus on allowing the guardian to cancel at any time and otherwise fallback to their original behavior with super.

The inspiration for this PR is in #5260 which was then replaced by #5301. There is some context missing but will try to give a TLDR.

• The assumption that governance correctly identifies all faulty proposals is flawed.
  • There are times that a proposal needs to be created strategically but then need to be cancelled.
  • Proposals very often have to be cancelled after the pending period (see compound governance)
• Compound governance allows cancellation by proposers at any point which is what Enable proposal cancelation by proposer after pending period #5260 advocated for
• @Amxx pointed out that this gives a possibly exploitive permission to the proposer over the community as they could manipulate governance by cancelling at any point.
  • Say governance wants to do A but proposer X wants A to be delayed by a week. Proposer X would frontrun another proposer to propose A so other community members wouldn't propose. Proposer X cancels proposal A right before execution, requiring a whole new proposal process.
• While I don't know of any occurrences of the above, the possibility makes it preferred that the cancellation comes from a trusted community proposal guardian (hopefully a multisig)
  • If governance does not actually set the cancel guardian, it is definitely preferred to pass this authority over to the proposers.

@Amxx pointed out that this gives a possibly exploitive permission to the proposer over the community as they could manipulate governance by cancelling at any point.

Right, this was my interpretation as well. I also don't have any concrete example of such an exploit.

Getting back to the whole idea of enhancing cancellation capabilities, one concern I have with this design is the pattern:

if (...)  {
  ...
  _cancel(...);
} else if (...) {
  ...
  _cancel(...);
} else {
  super.cancel();
}

The reasoning is that we're allowing to bypass cancel side effects. By not calling super in certain situations (i.e. whether the caller is the proposer or the guardian). This is why I wanted to reduce the branches as much as possible

Consider a contract that inherits from GovernorProposalGuardian, but also inherits from an abstract contract that counts how many cancellations have been made (e.g. GovernorCancellationCounter), so that:

contract GovernorCancellationCounter {
  uint256 cancellations;

  function cancel(...) public override virtual returns (uint256) {
      cancellations++;
      super.cancel(...);
    }
}

contract MyGovernor is ..., GovernorCancellationCounter, GovernorProposalGuardian { ... } // Order is important

In this case, the count would be missing the internal branches that don't call super. Although it's easier to override _cancel, I would say there may be legitimate reasons to prefer cancel.

I'd feel more comfortable if Governor implements an internal:

function _validateCancel(...) internal virtual {
    // Current logic
    uint256 proposalId = hashProposal(targets, values, calldatas, descriptionHash);
    _validateStateBitmap(proposalId, _encodeStateBitmap(ProposalState.Pending));
    if (_msgSender() != proposalProposer(proposalId)) {
        revert GovernorOnlyProposer(_msgSender());
    }
}

...


function cancel(...) public virtual returns (uint256) {
  _validateCancel();
  return _cancel(targets, values, calldatas, descriptionHash);
}

I think this way users can override _validateCancel and we can use it in GovernorProposalGuardian to implement the newer branches without missing the super.cancel.