The TUSD collateral type was onboarded to the Maker Protocol on June 4, 2020, containing the following risk parameters:
- Debt Ceiling: $2 million
- Stability Fee: 0%
- Liquidations: OFF
- Lot: $50k
Due to the fact that the TUSD token contract is upgradeable by nature, the TUSD team was able to upgrade the token implementation just 24 hours after it was added to the Protocol as a collateral type. Since the new TUSD upgrade, the new implementation has yet to be whitelisted to the Maker Protocol’s TUSD collateral adapter. As a result, all of the TUSD funds used to open vaults have been frozen within the adapter.
Upon review of the new implementation of TUSD, there are a few concerns about the new implementation and the TUSD collateral type as a whole.
1. Deposit Addresses
TUSD has functionality in its registry contract to declare addresses as “deposit addresses” and declare corresponding addresses where funds sent to the deposit address can get forwarded to. For example, if the registry declares
address1 as a deposit address for
address2 , any TUSD sent to
address1 would be forwarded directly to
This is quite a big concern with respect to our
join adapter because if the
join adapter itself is declared as a deposit address, any funds sent to
join() would be forwarded to the other address, while still allowing
vat.slip() to be called. Consequently, this would mean that users could mint DAI that is unbacked by collateral resulting in the internal accounting system of the vat contract being compromised.
By onboarding TUSD as collateral, the Maker community needs to trust that the TUSD team does not declare the TUSD join adapter as a deposit address. Additionally, the community must trust that the TUSD team’s private keys cannot be hacked.
2. TUSD Private Keys
If the private keys were to be compromised, it could result in two harmful outcomes:
- The join adapter could be declared as a deposit address.
- The implementation could be changed to a malicious ERC20 implementation, where a large amount of unbacked TUSD could be minted. This could result in the implementation being switched back to the whitelisted implementation, ultimately allowing a hacker to use this unbacked TUSD to mint (effectively) unbacked DAI.
3. Frozen Funds
Every time the TUSD contract gets upgraded, the token implementation address changes. When changed, the TUSD adapter is effectively frozen until the new implementation is reviewed by the smart contracts domain team and approved by Maker governance. During this time, users who have deposited TUSD into an MCD vault will not be able to exit their collateral. This could be avoided if appropriate time is given to the smart contracts team to review a deployed implementation’s code before it is switched by the TUSD team. Additionally, TUSD has “blacklisting” functionality that can freeze all TUSD funds that are held in the adapter.
4. Upgradeability/Diminishing Returns
The average ERC20 token implementation is roughly 200-400 lines of code. The latest implementation of the TUSD token is 2,457 lines of code. Each time these contracts are upgraded, the implementation has to be scrutinized to ensure that no critical bugs exist. Due to the fact that these contracts can be upgraded on an arbitrary basis and that the users’ collateral is frozen until the new implementation is approved by governance, it could lead to a substantial amount of time that the smart contracts team has to dedicate in order to maintain the TUSD collateral type.
The Maker Community needs to keep in mind that collateral onboarding is essential for the diversification of the collateral portfolio and fundamental to Dai’s stability. Therefore, the smart contracts team must consider whether the amount of time needed to maintain the TUSD collateral type is worth it as it can take time away from reviewing and onboarding other new collateral types. It’s important to note that the TUSD token is the only collateral type so far that requires this type of regular upkeep. This type of maintenance would be acceptable for a collateral type that provides a lot of value to the Maker Protocol, such as WBTC. However, TUSD has a low stability fee and a low amount of utilization. Thus, regular maintenance for a collateral type such as TUSD leads to diminishing returns.
Determining Next Steps
- Should we approve this new implementation of TUSD with the same risk parameters?
- Should we approve this new implementation of TUSD with the different risk parameters?
- Should we set the TUSD Debt Ceiling to 0?
This poll will be live for one week. After that, it will move to an on-chain ranked-choice poll, and then an executive according to the governance process after that.
What effect with the outcome have on the smart contracts team?
The smart contracts domain team has already done most of the work required to audit the new implementation. Further audit work would be required each time the implementation changes if we choose to keep TUSD. If we choose to eventually remove TUSD, that will require a one-time expense of work.
Due to the size and complexity of the code, the smart contracts teams agrees that we can’t be confident there isn’t a bug in the new implementation, which is likely to grow in complexity with further upgrades.