This is a proposal to add a Timelock contract to the protocol across the different chains on which the governance of the protocol is deployed. Transactions issued by the governance multisig of the protocol would need 48 hours before being finally executable.
Context
Angle Protocol is governed by veANGLE holders who vote on Snapshot for protocol improvement decisions.
Finalized votes are then implemented by a 4/6 multi-sig composed of community members.
This multisig, deployed on all chains where the protocol is live natively, has the ownership on many of the smart contracts of the protocol.
Proposal
Proposal is to give ownership across all the contracts of the protocol to the Timelock contract, and make the owner of this Timelock contract the existing 4/6 governance multisig.
The way future proposals would be executed with this setup is the following:
- Vote happens on Snapshot
- If good on Snapshot, the transaction payload is sent to the Timelock contract by the 4/6 governance multisig (which is the only address able to queue payloads to the system)
- Once the timelock delay is over, anyone can execute the transaction.
We propose as such to set the delay to 48 hours.
Implementation
Implementation suggested for the Timelock contract is that of OpenZeppelin TimelockControllerUpgradeable. It will be first set so that only the governance multisig can add payloads to the timelock.
In the first place, no one will have the possibility to cancel transactions except this governance multisig. This role could be granted to other specific contracts in the future (to implement Optimistic approval type of mechanisms).
Value to the protocol
The advantage of having a timelock is that leaves anyone the opportunity to take actions in case of a wrongdoing of the multisig. Should you see that the multisig has implemented a transaction to pull funds from the protocol (regardless of what has been voted on Snapshot), then you’ll be able to withdraw your funds before the transaction is finally executed.
Risks
The only risk with a timelock is that it reduces the delay for operational responses with the protocol if there is an issue that cannot be addressed by the guardian multisig.
Future thoughts
This is just a first proposal in order to increase the censorship resistance of the protocol and reduce the dependency on the governance’s multisig. Several other steps could be undertaken, and I am laying down some ideas so that anyone can give its thoughts on it. It could be the basis of future proposals:
- Add an optimistic approval feature → such that proposals can be cancelled by some stakeholders of the protocol. We’d need to define who and what’s needed for a proposal to be cancellable but that’s something that can be added modularly to the timelock contract
- Pass to a fully on-chain governance (using a system like Snapshot X where the payload of the transaction being voted is ready and known in advance, or using an OpenZeppelin GovernorUpgradeable smart contract logic). An optimistic approval feature could still be useful in this case to avoid for governance attacks. We could have this system exist in parallel with the current multisig system, but this would allow the protocol to still exist should the multisig be lost. This system would be quite easy to implement on mainnet, but harder to launch in the current setup where the protocol exists cross-chain.