Payload with PR:
Background
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
.
Summary
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.