OversightDAO address change makes a proposal impossible to veto.

[giuliostramondo]

The anti-veto check scans proposal messages for MsgUpdateParams that modify OversightDaoAddress. If it finds one — regardless of what the new address is — it blocks the veto. So you could set the Oversight DAO address to literally any other valid address (doesn't need to be the gov module), and the proposal becomes unvetable. The anti-veto protection was designed to prevent the DAO from blocking its own replacement, but it's too broad — it protects the entire proposal, not just the address-change message.

We should make the anti-veto check more targeted — only block veto of proposals that exclusively change the OversightDAO address.

[giunatale]

what? how would you do that? it hardly makes sense to me. I mean sounds ok on paper but in practice I don't see how you would implement this effectively without adding some contrived logic

[giunatale]

also, no, exclusivity is not a good criteria to decide on preventing or not the veto option. The only true option I see is to prevent entirely making Params change that contain oversight DAO changes alongside anything else (they need to be done by themselves) but it requires adding more logic that I don't necessarily like as I was saying

[giuliostramondo]

what? how would you do that? it hardly makes sense to me. I mean sounds ok on paper but in practice I don't see how you would implement this effectively without adding some contrived logic

Essentially, you build a proposal where the first message contains an update to the oversight_dao_address parameter, then you can put any other message in the proposal, e.g. :

{
  "messages": [
    {
      "@type": "/atomone.coredaos.v1.MsgUpdateParams",
      "authority": "$GOV_ADDR",
      "params": {
        "steering_dao_address": "$STEERING_DAO",
        "oversight_dao_address": "$NEW_OVERSIGHT",
        "voting_period_extensions_limit": 3,
        "voting_period_extension_duration": "604800s"
      }
    },
    {
      "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend",
      "authority": "$GOV_ADDR",
      "recipient": "$ATTACKER",
      "amount": [{ "denom": "uatone", "amount": "1000000000000" }]
    }
  ],
  "deposit": "512000000uatone",
  "metadata": "",
  "title": "DAO Reform and Development Fund",
  "summary": "Upgrade oversight infrastructure and fund development"
}

If the Oversight DAO tries to veto the proposal it would receive the following error:
failed to execute message; message index: 0: proposal with ID 5 contains a change of the oversight DAO address, vetoing it would prevent the replacement of the current oversight DAO: oversight DAO cannot veto this proposal

So I think the fix here - if we want to keep the DAO update method - is to verify that the only thing the proposal does is to modify the Oversight DAO address without any other effects.

I can write a POC if you want :)

[giunatale]

Yes but my point here is that this proposal would clearly be faulty in nature, and it would still require a 2/3 majority to pass. The issue I see is that preventing this scenario - which is weird anyway - requires an annoying and kinda ugly patch, and the benefit is really marginal since this is a fringe case anyway, and again still would require 2/3 majority minimum to pass. Anyway I'll take a look

[giunatale]

The only way to do this practically is to do it at the ante level since for example the sdk gov module does not have any knowledge of the existence of the coredaos module. Adding a custom ante handler is the less ugly solution imho