TUSD Update (Forum Poll): Concerns Surrounding the TUSD Collateral Type


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.

Review Outcomes

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 address2 .

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:

  1. The join adapter could be declared as a deposit address.
  2. 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?

0 voters

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.


We should not be bothered with any new coins until DAI is back on the peg. We have more important issues:

  • fix the DAI peg
  • prepare for more and more expensive tx fees (optimize voting etc.)
  • fix the auction system

TUSD ownership keys changed 8 days ago because TrustToken quietly ousted their CEO Jai An.

Besides the new registry owner 0x1BA5194b6384b150854a47E0F7a7F7d4b0549CD0 the Deposit Address Registry can write the deposit address flag.


Seems like 1, 2, and 3 are all reducible to what we already expect, which is that TUSD is a centralized stablecoin and may become worthless to Maker at the discretion of those who control TUSD. Issue 1 seems acceptable so long as the losses are limited to the debt ceiling for this vault type.

Regarding Issue 4, sounds like keeping TUSD is probably not worth the effort, especially since the last update took place without any notice. However, it also sounds like the latest implementation has already been vetted, and is not much extra work at this point.

If Maker adds the current implementation, and it gets some significant use, then they update the contract again and Maker decides to not approve the next implementation, would there be a way for the Vault owners to get their funds back, and if so, how difficult would that be to implement?

1 Like
  1. New collateral types are the best way we have to fix the peg. We need to onboard collateral faster, not stop onboarding collateral.

  2. Transaction fees are part of the layer 1 protocol, not part of maker’s implementation. Although it’s possible we could look into maker protocol changes to use layer 2 tech, and sidechains, these would be significant changes which probably would take at least months to roll out. (Although definitely worth talking about if we want to go down that route!)

  3. Yes the auction system needs to be fixed, and we have begun discussion about that, but I would also like to see that implemented ASAP! Lots of discussions around solutions to fix the peg depend on an improved auction system to some extent.


I think before I vote on this my question is whether we could be going though the same situation with other stablecoins as we are dealing with on TUSD.?

1 Like

Hi @Spidomo!

So what you are asking is essentially what option 3 is in the poll. Approving a new implementation and setting the debt ceiling to zero would allow all current vault holders to exit their positions while preventing new vaults from being opened.

1 Like

I appreciate the desire to get governance input on this issue. But I’d be grateful if you could consult the Practical Guide to the Signaling Process when creating threads like this.

Specifically I’d like to see clear lines of progress laid out. How long is this poll going to be live for? Do you expect to poll for it on-chain, subsequent to on the forum (we probably should)? What affect will the outcome have on the activities of the Foundation smart contracts team?

1 Like

Thanks @LongForWisdom! I have added answers to the questions you’ve outlined at the bottom of the post.


Other stablecoins, like USDC, also use an upgradability pattern. This pattern is mostly antithetical to immutability and could expose Maker to extreme collateral risk. To that end, TUSD is no different than USDC: we can only trust the team and jurisdiction of the project.

However, TUSD is still different in a number of ways. The code is already more complex than that of USDC and it took a number of us a considerable amount of time to moderately review this implementation. There are lots of features tacked on to this ERC20, which is not a secure design pattern (at least not one we follow). This means that each time there is a new implementation, we are going to need to spend a large amount of time vetting that implementation. What’s more, it’s already difficult to attest to the security of TUSD, which will only be exacerbated with each upgrade. Given the lack of confidence in the existing security, one cannot imagine Maker wanting to take on much more collateral risk with TUSD. Which begs the question, if we have more conservative risk parameters for TUSD, will there be sufficient usage of this collateral to justify a time consuming audit these future upgrades?

All of this being said, the TUSD engineering team has been great. They were happy to answer questions, and very helpful in our review. I’m a little concerned by @wjmelements comments above, as the new implementation already has a number of features that make trusting the registry owner critical.


Hey @cmooney thank you for taking time to reply. I think ultimately I am soliciting opinion from the experts on this.

You write my opinion on this best as a question below.

I have been asking the community what we think is the required real value to the protocol on these collateral additions. Which would require some kind of accounting of time, report to community (what is ROI keeping TUSD generally, as well as any of the other tokens). I am skipping the time governance has to put in to review SF, RP, DC changes over time.

This is a general question regarding costs of operations for what we get on some of these additions and have to defer to the people who are doing the work. What is your thinking here on cost vs. reward for TUSD in particular?.

I am back to mine…

Simple math on even a 10M DC facility (which is a 5-6% system risk at this point) at 4% SF system earns 400K max/yr if used fully (worth it imo). A 2M facility to manage risk IF maxed and SF at 4% on it would only yield 80K/yr profits (if TUSD - not sure if worth it).

I would be back to my expert doing the work on this and paying for it.

DO YOU think it is worth it? Because I honestly can’t make that judgement still with the information provided.

As always thank you for any additional comments and insight. My gut says to ditch TUSD if it is a hassle and in particular if there is some consensus that we will be limiting DC so that possible profits from use do NOT outweight expense and hassle of maintaining it. I also have concerns about people using the facility getting funds trapped periodically. It just doesn’t seem positive from a user experience point of view here if their TUSD gets locked because of yet another contract change that requires lengthly review before opening up again.


Voting “set TUSD debt ceiling to 0” because I think MakerDAO should seek a high level of stability from collateral ERC20 contract implementations.

The kind of change TUSD experienced should be seen as similar to migrating from a current token to a new one, except that the new and old version won’t work in parallel.

When the likelihood of migration to a new implementation is high, the value of adding the current version is relatively low.

1 Like

Hey folks, Rafael from TrustToken here. I get why you’re concerned and I’ve posted a reply and some next steps here:

Would appreciate if you could give it a read and let me know what you think.