hey @bendi thank you for your quick answers.
In summary, I think this approach is really not ok and therefore I will of course vote against it.
The current gov contracts were made to be upgradable in the first place and this approach of deploying new governance contracts every time we want to upgrade something, is really jarring.
And by jarring I mean what @fred expressed here much better than me:
Also, if there’s even the remote possibility that in less than 6 months, on March 2025 after the next planned change to allow flexible voting, Arbitrum DAO would have 3 different versions of sets of governors, instead of having just one canonical set of governors from it’s beginning, as it does now, this needs to be a decision that is very carefully justified, with much stronger arguments than “it’s less error prone”.
The consequences of changing the governance contract addresses for the biggest L2 in Ethereum needs to be taken into account. I don’t even know, I don’t think anybody knows to be honest, all of the consequences of that change. Numerous 3rd party apps, dune dashboards, internal tools, analytics dashboards, etc. will be impacted by this and will stop working out of the blue. That’s a huge impact.
As @dk3 said here:
And although @Frisson said above “this is planned” I’m not sure if there is a way to do this well at all, and even less, in a timely manner.
To be completely honest, it sounds to me that you, Scopelift and Tally, don’t want to hold the liability of developing the payload that upgrades a governance contract that controls billions of USD by potentially locking forever all of the assets in the arbitrum contracts and treasury. I understand if that’s the case, but please, don’t propose us down a path where we will be changing the governance contracts of the world’s biggest DAO, several times a year.
And honestly, if you continue to be adamant in proposing this approach, I think it’s time for the DAO to reconsider if open zeppelin governor contracts that need to be changed for every upgrade in functionality, are even what we want to use at all.
Because if we’re going to change the governance contracts, to be able to have more functionality like cancelling published proposals, and then change them again to be able to have flexible voting, we might as well just change the governance contracts once, to a new set of governance contracts that can do all of the functionality that the DAO requires and that can be in fact upgraded in-place and are designed from the beginning with modularity in mind, so that we can evolve our governance without having to go through these breaking changes several times a year.