New Vanilla cTokens

Recently, there’s been interest in listing new ‘vanilla’ cTokens – cTokens whose underlying ERC-20 is provably basic and no different than other existing cToken behavior. These are tokens which don’t and can’t do anything special on transfer aside from moving balances and modifying allowances. Vanilla tokens are somewhat easier to add to the protocol, since they don’t pose any new threats to the protocol, and therefore require less intensive auditing.

Obtain Price

For listing a new vanilla token, probably the biggest barrier will be ensuring the underlying asset has a price in the price oracle. The new Open Price Feed provides a framework for doing so.

Use cDAI Delegator

In listing a cToken nowadays, the Compound team recommends using the upgradeable form of the contract. At the time of this writing, the only upgradeable cTokens are cDAI and cUSDT. There was a minor optimization made to the delegator contract before deploying cUSDT, which created a quirk by returning extra bytes that some ABI-decoders have difficulty with. Thus the recommendation is to merge this PR which reverts the contract back to its previous form, making it easy to deploy new cTokens without the padding issue, and which map to a commit in the ‘official’ repository.

Other Gas Optimizations

There are some other improvements that could be made fairly generically to the cToken implementation contracts, if one were so inclined. However these should not be made without proper auditing. One potential change is removing CarefulMath and/or moving to reverts everywhere instead of Failure codes.

Perhaps the lowest hanging fruit would be to remove the *Verify hooks from the end of each cToken call. Essentially the inverse of this change, except also inlining any checks that are currently present in the Comptroller. At the time of this writing, this is the only such check.

1 Like

What’s the benefit to list vanilla ctokens?

Potentially the same as any other token - vanilla-ness of the token doesn’t really imply anything about its utility

Roger that. Sure this will come in help sometime soon…

1 Like

When moving to reverts, would it be preferable to send error codes which are described in compound docs or try to write a short description of the error in the message?

I think including the old error codes is a good idea. Could either be just the codes or maybe better to add a little more reason like ‘description… (CODE_NAME)’

I like this. Essentially this is just proposing a simplified process to create new markets for the most simplistic asset types, correct?

Would be curious to see a list of tokens that fall into the “Vanilla” category?

Assuming security is a constant there is no downside I see to adding more assets!