The DAO claimed its AURA allocation and locked it in BIP-481, and later more claiming/locking occurred via BIP-551 and BIP-638. As a result the DAO multisig now has 2m vlAURA, which will become available to be relocked 2024-10-17 02:00UTC and will otherwise unlock 2024-10-24 02:00UTC.
The voting power is actively being used strategically every epoch, and the DAO would like to keep doing so. Therefore, in order to (1) prevent having to create a new BIP for every relock, and to (2) reduce the risk of the DAO multisig not being able to execute this relocking every cycle within the right time window, we developed a Safe module that does this automatically: AuraLockerModule.sol.
The proposal here is to enable this module on the DAO multisig, and to thus let the module, on behalf of the DAO multisig, relock all vlAURA automatically every cycle as soon as that becomes possible. If this were to for some reason fail, the DAO multisig will have the mandate to relock manually every cycle. The module can be disabled at any time to prevent relocking from occurring, if the DAO were to have other plans with its AURA allocation.
Risks
A variant of the same contract by the same author has been running in production successfully for a different DAO. This Dune query shows all of its successful automatic relocking events (note how almost all of them occur at the first block at midnight UTC). Besides Maxi’s internal reviews, a Balancer Labs contributor (@mkflow27) did a review of the contract. If the module fails to perform its task, the DAO multisig still has 7 days to relock via a manual call (0x3Fa73f1E5d8A792C80F426fc8F84FBF7Ce9bBCAC.processExpiredUnlocks(true)).
Payload
DAO multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f on Ethereum will call enableModule(0xfD20C63554A9916816dC5e5Df596A0333185F263) on itself.
Apologies for chiming in late here. I unfortunaly haven’t seen this BIP in time to challenge it before it went to a vote.
After recent incidents with multisigs (like Radiant’s) multiple people in the Balancer ecosystem got worried about the governance multisig enabling this module.
Even if these incidents hadn’t happened I would strongly be against this for 2 reasons:
This would set a very dangerous precedent of enabling modules on the multisig that controls the governance of the whole protocol. If anything goes wrong, governance will be taken over forever and even though LPs are not at risk (contracts are non-custodial) all governance decisions would be highjacked.
There is a much simpler way of getting the same outcome of auto-relocking our Aura using this module: simply spin up a new gnosis safe with the exact same signers as the main one, transfer all the Aura to it and enable this module there. This fully isolates the risks of this module (which though audited can certainly contain bugs and footguns) to only the Aura it would control.
The only downside I can see in my suggestion of cloning the governance safe is that signers would have to be swapped on the cloned safe every time swaps happen on the main one. A very minor downside compared to the risks of installing modules on the main governance safe.
