Request for a Maintenance Upgrades Working Group

[SEEDGov]

Hi @cliffton.eth, thanks for your reply!

@cliffton.eth

I’d personally agree that the Security Council would be the most apt body to take on this role as well, and think that this falls nicely under the non-emergency actions category (as per the Constitution, this is defined as implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting). While there might be concerns over the 6 month rotation of signers, this could be addressed as part of the onboarding process for elected members.

While we agree that these are non-emergency actions that fall under the category of routine upgrades/maintenance, we’d like to emphasize what it would mean for the Security Council to carry out the entire process.

As you correctly pointed out in your previous comment, there’s a process of about 2 to 3 weeks that includes initial engagement from the proposal author through a template, followed by a thorough review by the responsible committee.

In this sense, we believe that proposing a specialized committee for this task makes more sense, as we can ensure its composition meets the criteria required for executing these responsibilities. The composition proposed by Tally is reasonable, as it directly involves OCL and AF (from our perspective, they must remain involved), and it also includes technical specialists who can support them.

One alternative we previously considered was to replace Security Auditors A and B with one Security Council member from each cohort. This would preserve Security Council involvement while significantly reducing rotation, especially considering the Foundation has published a proposal to extend the Security Council term to two years.

@cliffton.eth

@SEEDGov also proposes good alternatives around creating a WrappedL2Timelock with a dispute mechanism - our concern around this, and this might be an edge case, is that a malicious delegate with >5M voting power could just raise disputes on all proposals created by the committee/security council, essentially forcing all these proposals to go through the constitutional proposal path. Perhaps the threshold being higher could address this concern, but from a process design perspective, we think that having all proposals go through a veto period with a sufficient veto quorum mitigates this potential issue altogether.

Regarding this, we agree it’s a low-probability edge case.

First, if a malicious delegate had >5M VP, they could cause more harm by directly creating proposals on Tally than by simply spamming disputes to delay the listing of a token. In other words, if we had such a delegate, we’d be more concerned about their broader influence than about the delay of routine maintenance updates.

Second, we consider this to be a highly unlikely scenario — as acquiring 5M VP today would require over $2.5M in capital just to delay a token listing. And even then, that wouldn’t be enough to stop it, as other delegates would still need to support the dispute in order to cancel the upgrade.

We continue to believe that the most sensible approach is to only require a vote when strictly necessary, instead of having a default vote/veto process. It’s worth noting once again that the proposed 7-day veto window with a 3% quorum would require a constitutional amendment. Otherwise, we’d revert to a 14-day veto period with a 4.5% quorum to cancel a malicious transaction.

We also believe that the approach we proposed minimizes the number of changes required to the Core Governance contracts, and once again, we’d be interested in understanding — from a technical perspective — the implications of the proposal made by Tally, as we previously asked in our earlier response:

@SEEDGov

As we asked before, it would be interesting to know the technical nature of the proposed changes, whether we are dealing with a new governance module that should be included as a proposer in the L2Timelock, or if we are making changes directly to the existing Governor.