Title: [RFC] Improving Protocol Security via Timelocks
Author(s): @martin_shift, SHiFT Asset Management (https://shiftam.com/)
Submission Date: 6 February, 2023
The proposal is to discuss the implementation of a timelock contract along with the existing 4/9 multisig (0x25Aa4a183800EcaB962d84ccC7ada58d4e126992) to safeguard protocol’s upgrades, including changes in individual asset configurations.
It is imperative for a Euler Finance’s development to introduce a timelock on the upgradeable smart contracts, which will allow users to have some time to take necessary actions before a change is implemented in Euler Finance’s system of smart contract.
With the growing adoption of DeFi among institutional investors it is necessary that DeFi protocols also provide a transparent mechanism to control smart contract exploit risks associated with providing liquidity to their platforms. Euler Finance is among most innovative lending protocols with a unique architecture, however the team multisig currently holds excessive power over deploying changes to the protocols smart contracts and, under certain conditions, might put user funds at risk. This RFC seeks to initiate a discussion on the issue.
Despite being in early stage of development, DeFi has attracted a substantial number of institutional investors, who are more naturally more rigorous in their investment approach in comparison with retail investors. This means that DeFi platforms should strive to be more thorough in managing smart contract exploit risks and provide assurance to liquidity providers that their funds are safe.
EVM allows anyone to create open-source, immutable and censorship resistant smart contracts. Once deployed, an EVM smart contract cannot be changed, however, there is an option to make them upgradeable (e.g. using proxy contract). While it is desirable (and sometimes necessary) to have upgradeability in the protocol’s architecture, this flexibility comes with a caveat of additional attack vectors.
Any protocol could be drained by changing an implementation of a core smart contract with liquidity to allow a bad actor to withdraw funds. Another classic attack vector, particularly for lending markets, is changing risk parameters in a way that enables illiquid tokens with high centralization as collateral. This would allow for price manipulation via continuously (lending bad assets, borrowing stablecoins and buying that asset), which will eventually drain the market of “good” assets and result in bad debt for the protocol.
There is no question whether DeFi lending platforms (in their current form) need to have a degree of upgradeability to accommodate changes in risk profiles of specific assets available for lending/borrowing – it is vital to have the optionality of adding/delisting/updating risk parameters of assets to maximize efficiency of DeFi lending markets. However, these updates should be properly managed.
The two existing options for managing exploit risks are multisig and timelock smart contracts. The former option mitigates the risks of a single EOA having power over the protocol’s upgrades, while the latter allows LPs to have a specified time interval before changes are implemented to contracts. Multisigs have been proven to be less resilient to attacks, since signers could collude or compromise their access to multisig due to the human factor. Timelocks, in contrast, could be front run – suppose an exploitable bug was found in a protocol’s contract – by the time the team deploys the patched implementation of the contract there might be an exploit. So both options have their advantages and drawbacks. This is why a combination of these tools is used in top tier lending markets like Aave and Compound:
Aave implemented a long (7 days) and short (1 day) timelock executor contracts in V2, their highest TVL lending market. The short timelock executor is used for risk parameter updates, while long time lock executor is used for governance and AAVE token upgrades.
Additionally, Aave implemented the Guardian multisig with doxxed member who are voted on via governance proposals. This Aave Guardian serves as emergency backstop mechanism against hostile governance takeover, it can stop the implementation of a proposal. On top of that, Aave Guardian has the prerogative to pause Aave V2 market in case of emergency.
As per documentation, each protocol’s contract is controlled by the Timelock contract, which can modify system parameters, logic, and contracts in a ‘time-delayed, opt-out’ upgrade pattern. The Timelock has a hard-coded minimum delay of 2 days. The Timelock contract queues and executes proposals that have passed a Governance vote. The Comptroller contract designates a Pause Guardian address capable of disabling protocol functionality. The Pause Guardian cannot unpause an action, nor can it ever prevent users from calling Redeem, or Repay Borrow to close positions and exit the protocol. COMP token-holders designate the Pause Guardian address, which is held by the Community Multi-Sig.
In the current Phase 1 the team multisig was granted the
updateAdmin role, which can deploy new modules and update existing modules and set a new
governorAdmin role, which can change risk configurations of assets on Euler’s market. Even though a Timelock contract exists, it can be bypassed by an attacker who has access to the multisig.
Euler Finance team declared their intention to transfer
governorAdmin role from the team’s multisig to the Timelock contract deployment in Phase 2 and similarly transfer
updateAdmin role in Phase 3, however no specific dates are mentioned by the team. Transition to Phase 2 assumes a decentralized and fully functional on-chain governance, which is the potential hurdle that is holding back the process.
It is imperative that Euler Finance adopts stronger security standards in order to facilitate the arrival of the institutional investors on Euler Finance. A possible solution could be prioritizing the migration of both
updateAdmin roles to a timelock contract on top of the existing multisig, while the governance takes its time to mature and become sufficiently decentralized. The multisig can be designed to have emergency pausing functionality where supply and borrow functions are banned, but users can still repay their debt and withdraw supplied assets. This approach is in line with the industry standards set by Aave and Compound. The community is welcomed to discuss any other options which can help the protocol mature and attract more institutional grade liquidity providers.