Upgradeability in DeFi
In Blockchain we make much of the immutability of smart contracts; “in code we trust”. However frequently with DeFi protocols it is not the code you trust but rather the admin team that controls the upgrades. This is because the code can be upgradable. The admin teams, to varying degrees, can update or completely change the underlying smart contracts. They can have control over the user’s funds. In almost all cases the admin teams have been very trustworthy in the software upgrades of their protocols. However, they rarely document in a clear and transparent manner the level of control they actually hold.
DeFiSafety wants better transparency on this aspect.
If you open a Gnosis multisig the code is fully immutable. No one can alter the smart contract clauses. If you deposit to some DeFi protocols (even very large ones), then the admins can change every contract, completely rewriting the protocol. We are not against upgradeable contracts. Upgrades can improve security. The community and the DAO can watch, advise and vote on changes but the real power still rests with the admins.
It is not a bad thing to trust the protocol with users’ funds. But users should not have the impression they are using immutable code when they are not.
Effectively DeFiSafety is asking for one page of text in the governance section to fix this.
The degree of control the admin team has should be clearly documented in a consistent place and manner and language that the DeFi user (not a solidity developer) can understand. In DeFiSafety’s latest review process (0.7) we have added a section called “Access Controls” that checks for exactly the information described above. This is a very new demand for DeFiSafety to score. We are flexible in adapting our process until we find the balance for both the users and the protocol.
So, what do we ask to see?
First, make the information easy to find and in one place.
For most protocols there is a governance section, this seems the most logical location. After discussing the community voting capabilities, discuss how the proposals are implemented.
Second describe the changes the admins can do to the protocol.
If all contracts are immutable, say so. If the entire protocol can be updated, say so. If it is a mix, describe. Next describe how these changes can affect user’s funds. Make the description clear in non-software language.
Finally list the addresses that can update the contracts. Are they OnlyOwner, MultiSig or defined roles? If the addresses are controlled by a multi sig, give the users an idea of who can sign. We understand that signers don’t want their name publicized but users also want confidence that the signers actually are the set of people indicated. Find a balance.
If there are a set of values (such as fees) that the protocol will update regularly on a protocol via governance (even if the contract is fully updateable) do describe them and their impact on users’ funds. If there is a time delay on any changes, describe them clearly.
Ensure the writing is designed for users and explained in clear language.
A pause capability allows a protocol to stop part or all of a protocol, freezing transactions temporarily. Often this is used when a hack is underway to minimize damage before implementing a solution. If a pause capability exists, describe it.
We also believe pause capabilities should be tested or “fire drilled” regularly to ensure signators are able to react. This is a brand new concept that to our knowledge, no one does yet. The idea is that regularly (say once every few months) a test pause command is sent by a third party. The protocol should respond quickly. The time delay should be recorded publicly.
