[TFIP-6] Assign CANCELLER role for TrueFi DAO Governance


To protect the DAO from potential governance attacks, we propose assigning the CANCELLER role to the multisig 0x16cEa306506c387713C70b9C1205fd5aC997E78E.

In the past, this multisig has governed many TrueFi protocol smart contracts. While some of this multisig’s rights have already been passed to the DAO (as indicated in TFIP-2 and TFIP-3) this multisig continues to hold responsibility within TrueFi.

Members of this multisig have been vetted by Archblock, and the following security measures have been undertaken:

  • All signers are using hardware wallets
  • Members are geographically dispersed
  • There is a stringent procedure in place for reviewing all proposals, which includes performing reviews and simulations before execution.


After last week’s Tornado Cash governance attack it seems increasingly important to protect the DAO from a similar scenario. To safeguard TrueFi DAO we propose setting the CANCELLER address in our Governor to 0x16cEa306506c387713C70b9C1205fd5aC997E78E. The CANCELLER role is already implemented in our Governance as a result of TrueFi using OpenZeppeling’s governance contracts, but it has not previously been set.

What CANCELLER can do:

  • In case there is a proposal that is faulty or adversarial - canceller can execute a transaction that would render the proposal ineffective.

What CANCELLER can’t do:

  • Canceller can NOT make any decisions or execute any transactions on behalf of the DAO. Its only power is to CANCEL proposals.

There is precedent for something like this at major protocols like Curve that have their Emergency DAO (https://dao.curve.fi/emergencymembers) in the case of malicious behavior.


It is worth noting that there are certain scenarios where CANCELLER could actually collude with a black hat hacker to extract value from protocols by delaying “rescue proposals”. As a result, CANCELLER should be treated as a temporary measure until there is more value in the protocol and/or a better solution is found.

Transaction details

We need to call Timelock’s (“0x4f4AC7a7032A14243aEbDa98Ee04a5D7Fe293d07”) grantRole(role, account) function with args: grantRole(“0xfd643c72710c63c0180259aba6b2d05451e3591a24e58b62239378085726f783”, “0x16cEa306506c387713C70b9C1205fd5aC997E78E”)


Makes sense no? What similar x improved solutions have been implemented w other protocols? Looking through

Yes, it seems that makes a lot of sense. Having said that - we have learned that the multisig that I pointed to within this proposal already has a lot of “TrueCurrencies” related responsibilities. We 100% want to avoid mixing these two. And we would not be able to re-configure who the signers are (right now it is 95% AB folks). So we’re building new mutlisig that will be 2 AB, 2 WF, and 2 independent long-time community members. I will repost this proposal with the new address soon.