TUSD Smart Contract Update Request

Hey folks, we would like to make a small update to the TUSD smart contract and are requesting that the Maker community take a vote to approve it in the adapter. We’ve already contacted the smart contract team and they will be posting an update once they’re finished reviewing the new code. Thanks for your help.

Details on the update:

  • On Sept 16th we upgraded the TUSD smart contract based on feedback from the Maker smart contract team and other protocols. This upgrade massively simplified the TUSD smart contract but also left out one feature which we’re now realizing was important: supporting our legacy (pre-Jan 2019) TUSD smart contract.

  • The legacy contract was launched in March 2018 before the upgradable proxy pattern was standard, and instead of full upgradability, it included the ability to forward transfer() calls to a new address. We migrated to an upgradable proxy in Jan 2019 with a full announcement and instructions for integrators.

  • After the on Sept 16th, we were contacted by IDEX who is having the following issue: they were continuing to rely on the legacy TUSD smart contract, and while they are able to integrate the new TUSD smart contract, their smart contract is unable to understand that ‘old TUSD’ balances are actually now ‘new TUSD’ balances (of course all balances are moved over, the old smart contract just forwards calls similar to a 301 redirect on the web). This issue with IDEX affects about $130k TUSD.

  • We want to make sure these IDEX users are taken care of and that’s why we’re requesting this vote.

Of course we would not perform an upgrade without the Maker community taking a vote to approve the new implementation. The new implementation has already been audited, both code and audit are linked below.

Thanks for working with us, and please let us know if you have any questions or concerns.

Relevant links:


The MakerDAO smart contract domain team has reviewed this update and we are recommending that the new implementation be approved in the join adapter in this Friday’s executive (10/02/2020). @LongForWisdom, please let us know how you would like to proceed.


Isn’t collaboration just the best? :heart_eyes:


I think this can and should go straight to executive rather than through polling, for the following reasons:

  • Governance has approved TUSD in the past (indicating that Governance approves of the collateral type)
  • You guys are now ratified as domain actors (indicating that Maker Governance trusts you to audit these changes and warn if they are problematic)
  • The alternative to upgrading is essentially freezing all the TUSD vaults (meaning that we’d only really want to not upgrade if there was judged to be a greater risk by whitelisting the upgraded implementation.)

I just have a hard time seeing any poll or vote on this resolving in a negative outcome. If governance wants to stop using TUSD as a collateral type, they can signal and vote on that directly. There are much better ways of winding down usage (if that even is the desire, and I have no reason to believe that it is) than failing to whitelist a valid and non-malicious new implementation.

Given that the outcome is pretty much a no-brainer, and that a negative outcome would actually be damaging, I’m happy just skipping the poll.


This confused the hell out of me because date formats. Can we meet in the middle and go with YYYY/MM/DD? (I’m probably guilty of this as well, but I’ve been trying to make an effort to use YYYY/MM/DD)


Ugh, that date format. Sorry, my elementary school indoctrination leaks out sometimes. I usually use YYYYMMDD, but was looking at a calendar using this broken date format. I owe you 10 DAI if this ever happens again.


@LongForWisdom thanks for your support, we’ll plan on doing the TUSD upgrade shortly after the executive vote is executed.

One thing I wanted to mention:

We wouldn’t upgrade without the TUSD smart contract without prior approval from Maker. If the Maker community didn’t feel comfortable with the new implementation, for any reason, we’d hold off on any upgrades until we can figure out a path forward together. We’d only proceed unilaterally if every attempt to find a solution both communities were happy with was exhausted.


FYI I use following datecode for all files in subdirectories for over 3 decades now.

CCYYMMDD_HHMMSS_MakerPost_TItleWhatever (SS if I need it).

Sorts naturally and always no matter what retains the date code even if the filesystem file creation/edit date is changed as long as you put 0’s in right places.

20200930_0140 - etc.

I have argued that people remember better when they did something than the name they gave it in the filesystem much less the place they stuck it. This gets horrifically bad when one has hundreds of people all doing work on the same machine (commissioning for example) and putting everything in myriads of directories/subdirectories/etc. We literally can’t find anything related to our commissioning - especially stuff from people who have already left because of the hands off approach to directory and file naming.

There are times I have considered writing up a document on this for RFC to try to come up with some form of directory system file naming standardization. My friend reminded me when I brough this up that the color of a light indicating an on status even on devices isn’t a ‘standard’ color (look around your house and count the number of colors for lights on devices that just show ‘on’) so if we can’t standardize that - forget about standardizing anything else.

I loath 3/4/2020 as a date code because is the first a day or a month? And don’t even try to sort or find

It was a humbling when he pointed it out the whole ‘on’ light issue to me.

1 Like

Executive vote has passed and we’ve gotten the green-light from the AAVE team as well, and so, as planned, we’re commencing the upgrade today. Will post here once it’s complete.

UPDATE: TUSD upgrade is complete. Post-upgrade tests have passed. If you encounter any issues, please let us know.

For reference, this TXN performed the upgrade: https://etherscan.io/tx/0x9b3084b24ae7a0869ef73b845417a2e7a8162167434263c14770c75db9e0a7a4



This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.