This proposal aims to cover important smart contract upgrades that will allow for the rescue of user funds, improved pausing functionality and additional safeguards via blacklisting.
This proposal will not cover the execution of the proposed rescue function and unpausing. Those items will be addressed later via a future BIP.
Upgrade all affected Setts with the following new functionality:
- add rescue function to transfer sett tokens from attacker wallets to recovered.badgerdao.eth (one time use - patchBalance() function)
- add a ‘global pause’ feature that allows all Sett contracts to be paused and unpaused simultaneously with the same permissions as current pausing functionality
- add global blacklist to block actions, set to the attackers wallets listed below
Blacklisted Attacker wallets:
NOTE: Approval to execute the following actions will be submitted via a future BIP that will undergo the Badger Governance Process:
- Execute the new patchBalances() function to rescue funds from the attacker to the recovery multisig
- Unpausing the Sett contract to resume normal operation
Badger is committed to reopening smart contracts as soon as it is safe to do so. Given the timelock considerations, waiting for the standard timeframe before making these upgrades would add a minimum 3 day lag once the final BIP to execute the proposed actions to rescue funds and unpause is decided.
As such, this proposal uncouples the smart contract upgrades from the execution of the rescue action and unpausing so that the execution decision can follow Badger’s governance process, while also ensuring the resulting governance decision can be enacted promptly.
Given this BIP will go directly to snapshot, it will require a supermajority of over 70% at a quorum of more than 200,000 votes in order to pass.
Additionally, among the older contracts, 1 Sett and 8 Strategy contracts have the Timelock set as their governance address. In order to align them with the rest of the infrastructure, Badger will change their governance to the devMultisig.
This will give Badger the ability to handle unpausing and transferring tokens away from attacker wallets atomically and with agility, which is the preferred technical approach to the situation. Badger intends to propose using the timelock for all key parameter changes as part of the future governance 2.0 initiatives.
Note that the timelock is still needed for upgrades or adding new strategies which are the critical operations that involve handling of user funds.
This transaction will require going through the Timelock process. Once executed, the unpausing of the whole infrastructure will be handled by the devMultisig directly and no timelock will be required for it.