TimelockV2: Veto Enabled

Summary

TimelockV2 has two modifications compared to the currently used Timelock contract.

• Change MINIMUM_DELAY from 2 days to 3 days
• Add Veto functionality for non-admins

Motivation

Chris Blec, a DeFi researcher and analyst on Twitter(https://twitter.com/ChrisBlec) recently noticed that the Timelock contract is in the control of the Ops Multisig, when it in reality should have been in control of the main Treasury Multisig with SBF, Leshner, etc.

He stated, correctly, that such control should not be in the hands of people anon to the public, and we have thus immediately taken measures to adjust this. Control of the Timelock is being prepared for transfer from the Ops Multisig to the main Multisig. This change needs to, ironically, pass through the timelock itself (48h) before the change can be executed, so we are queuing this transaction asap.

Specification

Detailed specification is described here.

For

For non-admin, they have power to veto against decisions if admin goes evil.

Against

Since delay will be extended, it takes longer time for a decision to be executed.

Poll

Do you want us to switch to it?
  • Yes, definitely!
  • Yes, but with some modifications.
  • No, I want status quo.

0 voters

1 Like

3 days is too long. During the recent attack on their DAI vault, Pickle’s other vaults were completely vulnerable for over 12 hours because they were unable to implement the fix due to timelock.

Timelock protects you from bad devs, it is actually a massive vulnerability against external bad actors – which is far more prevalent these days.

Sushi is not some sub 100k marketcap scamcoin. Sushi has re-established itself as a reputable project with integrity, it is also now large enough that a number of ‘eyes’ are monitoring the project at all times

Personally – I trust the devs to an extent that the 2-day timelock is long enough, that in the event 0xMaki or one of the other devs falls to the Dark Side, there would enough invigilators to catch them in the act.

If, on the other hand, a malicious external party finds an attack vector against Sushi… being unable to eliminate that vector for THREE DAYS would be catastrophic to the point of lethality for the project.

Please reconsider this proposal.

3 Likes

As I’ve said before, the deployed contract would not stop the execution of an attack if 3 out of 5 of the operational multisig signers would work together in an attack:

  • Operational multisig queues the same bad transaction 50.000 times or more. This is simple to do in a few batches.
  • Now all 50.000 transactions need to be individually be cancelled by a group of xSUSHI holders. They need to figure out how to automate this, write scripts for it and get all of them cancelled within 72 hours.
  • They may permanently lose all the xSUSHI they stake in the TimeLock because of a leak in _vetoedTxHashesForAccount. Items will be added, but never removed, and will be looped over during withdraw. Eventually this might get too large and exceed the max gas/tx limit.

Since queueing a tx is much cheaper than vetoing it and vetoing may have to be done by a group of people, the operational multisig can easily outpace those trying to stop them and get a malicious tx executed though the TimeLockV2.

Even if used for vetoing unpopular changes (not malicious), withdrawing will get more and more expensive over time for those who veto, due to the _vetoedTxHashesForAccount leak.

Therefore I’m against using this contract as it is now, because it introduces risk (unaudited new code) and doesn’t actually fix the issue it set out to solve and has an unfixed bug.

5 Likes

Thank you for the write-up :clap:t2:Totally agree with your analysis.
The array being unbounded was a sore point to me yesterday as well.
Here is the link to Boring’s implementation, it solves the problem: https://github.com/sushiswap/sushiswap/blob/master/contracts/TimeLockV2.sol#L140