Add Markets: MKR, AAVE, SUSHI, YFI

With the oracle improvement done, the protocol ready to list new markets. I am proposing to add MKR, AAVE, SUSHI, and YFI. I consider all four coins to be blue-chip DeFi tokens and very logical additions to the protocol. Each token will have a zero collateral factor (initially), the same interest rate model (as COMP/LINK), and a reserve factor of 25% for each market (which is standard).

Credit to @elee for doing the dev work.


Price: $2600
Note: 21% of MKR is the Goverance Contract and 8% in the MCD Pause Proxy
Mintable: True by the liquidation system or governance.
Initial CF: 0
COMP rewards: 0
Borrow cap: 25K (recommended by @monet-supply)
Ropsten cToken: 0x107ce37C9C40Ad204DFf182e82d886e53Bcb6e90
Ropsten underlying: 0xeef6de7ec2fae93769b1c2e725d698b8a5d0fd9e


Price: $7.60
Note: 14% of SUSHI is in the Sushi Treasury
Mintable: False
Initial CF: 0
COMP rewards: 0
Borrow cap: 0
Ropsten cToken: 0x29f4542F050Eb3E31004a09AAdD89fF265487967
Ropsten underlying: 0x7c9243b94d2ccf40940a70171a8b868354822669


Price: $295.87
Note: 18% of AAVE is staked and 16% is held in the treasury.
Mintable: False
Initial CF: 0
COMP rewards: 0
Borrow cap: 200k
Ropsten cToken: 0xc840F7aB675fEe6E8Ce4E8D8923A8afE860075F9
Ropsten underlying: 0xe547acbd930e7a54e011a1fdd182933a823d826d


Price: $32,943
Note: the tokens are spread out thanks to the initial distribution.
Mintable: True, via governance proposal.
Initial CF: 0
COMP rewards: 0
Borrow cap: 1500
Ropsten cToken: 0x67BCc4e98445fFccCf9D4f4A6CD14B4181b9449A
Ropsten underlying: 0x35362e4e7d23ac00b17c151e3b24d4e343e4c889

Interest rate curve: 0x2341ba42eb00c63cf03559c9a2295a23ace7e4ad

Once the community confirms the ropsten cTokens deployments look correct, we will deploy the cTokens to mainnet, work with Chainlink to get the new oracle set up and post the simulation info for the new markets.

Since this proposal follows historical precedents and sets the collateral factor to zero for all markets, I think it should be a straightforward addition to the protocol. Due to the ten governance action limit per proposal, I’ll likely propose them individually or in pairs if there is strong support. Once the assets are listed, I intend on circling back to make a proposal/forum post to increase their collateral factors.


Great news! Reiterating that for SUSHI it would be nice to allow deposit of xSUSHI (i.e. staked SUSHI) to be used as collateral if oracle allows.


Since AAVE already supports xSUSHI, I think it would be beneficial to the DeFi ecosystem if Compound listed SUSHI. That being said, I do not see a reason why we could not list both of them.


It’s great to see the integration already starting to pay off with the addition of new assets. I can’t see any reason against adding blue chips like these (especially w/ a zero collateral factor to start),

Excited for more to come!


Adding these four markets makes complete sense, and I think these markets will have broad support.

Starting these markets at a 0% collateral factor, 0 COMP distribution allows them to be added without any controversy; afterwards, the community should discuss & debate the introduction of collateral factors & COMP distributions (and how and why they might vary by asset).

Fantastic suggestion, and thank you for getting the ball rolling @getty :muscle:


Stoked for this one! :sunglasses: great work @getty


Excited to see more blue chips being added to Compound! I’m wondering what the major benefits are to starting with a collateral factor of 0 if it is just going to be increased in the immediate future? Would it not be beneficial to hash out those details now?

Collateral factors parameters are set on a coin by coin basis. The goal with my proposal is to keep it at a high level so we can add these relatively quickly (2-4 weeks). Once a coin gets added, I intend on creating a separate forum thread for each market to tune the collateral factor. Plus, this gives the protocol a little extra margin for whenever an asset is added.

Update: We have redeployed the contracts now that Compound 2.9 is posted.

MKR: CErc20Delegator | 0xb9321ac47163d851d867a7e982cbf0c5ce22fb3f

npx saddle match 0xb9321ac47163d851d867a7e982cbf0c5ce22fb3f CErc20Delegator 0xeef6de7ec2fae93769b1c2e725d698b8a5d0fd9e 0xcfa7b0e37f5ac60f3ae25226f5e39ec59ad26152 0x2341ba42eb00c63cf03559c9a2295a23ace7e4ad 200000000000000000000000000 "Compound Maker" cMKR 8 0x2079a734292094702f4d7d64a59e980c20652cae 0x0295a48b76bc68662bd15bfaecedca075a4f568f "0x" -n ropsten

SUSHI: CErc20Delegator | 0x1fcab19e3cfa9437648c240410a941c13b59ccc9

npx saddle match 0x1fcab19e3cfa9437648c240410a941c13b59ccc9 CErc20Delegator 0x7c9243b94d2ccf40940a70171a8b868354822669 0xcfa7b0e37f5ac60f3ae25226f5e39ec59ad26152 0x2341ba42eb00c63cf03559c9a2295a23ace7e4ad 200000000000000000000000000 "Compound Sushi Token" cSUSHI 8 0x2079a734292094702f4d7d64a59e980c20652cae 0x0295a48b76bc68662bd15bfaecedca075a4f568f "0x" -n ropsten

AAVE: CErc20Delegator | 0x12671d7a90adacac177b4cb79183890284c0c431

npx saddle match 0x12671d7a90adacac177b4cb79183890284c0c431 CErc20Delegator 0xe547acbd930e7a54e011a1fdd182933a823d826d 0xcfa7b0e37f5ac60f3ae25226f5e39ec59ad26152 0x2341ba42eb00c63cf03559c9a2295a23ace7e4ad 200000000000000000000000000 "Compound Aave Token" cAAVE 8 0x2079a734292094702f4d7d64a59e980c20652cae 0x0295a48b76bc68662bd15bfaecedca075a4f568f "0x" -n ropsten

YFI: CErc20Delegator | 0x829a3187954c7a87683212c6c0b2186af7a87500

npx saddle match 0x829a3187954c7a87683212c6c0b2186af7a87500 CErc20Delegator 0x35362e4e7d23ac00b17c151e3b24d4e343e4c889 0xcfa7b0e37f5ac60f3ae25226f5e39ec59ad26152 0x2341ba42eb00c63cf03559c9a2295a23ace7e4ad 200000000000000000000000000 "Compound" cYFI 8 0x2079a734292094702f4d7d64a59e980c20652cae 0x0295a48b76bc68662bd15bfaecedca075a4f568f "0x" -n ropsten

Once someone from the community confirms this is correct, we’ll deploy to mainnet.

1 Like

Completely in support of this - thanks to @elee & @getty for putting this together, makes total sense to have blue chip tokens as markets on Compound. Do you think it would be valuable to codify the general ways that we approach token listings for blue-chip, medium-risk and high-risk tokens? If so - would love to help out in any way we can.

That’s not a bad idea to explore IMO. I know there have been discussions around things like Reserve Factor Standardization for different asset types (which led to Prop 31). However I don’t think anything regarding collateral factors or interest rate models is official/codified AFAIK.

1 Like

Definitely makes sense to do imo - as DeFi expands what we consider to be blue-chip tokens will as well and it’ll speed up these proposals and require less discussion if we codify for collateral factors & interest rate models.

I’m in favor of adding these markets, but I’d strongly advocate for a different sequence of events here.

I believe it’s time for the Compound community to come up with a framework for adding new assets so that additions don’t feel ad-hoc.

I propose that prior to adding these new assets, we codify v1 of such a framework, and then evaluate these token additions by the terms of the new framework.

@getty @rleshner I’d be happy to work with others on this work if there’s appetite to take this on.


I would definitely advocate for having a set proceedure (that you can maybe deviate off a little), which would definately help for adding more assets. We should make some sort of “whitepaper” for this

1 Like

I can confirm that this set of contracts has been deployed correctly and matches the code at commit ae4388e780a8d596d97619d9704a931a2752c2bc. Be sure to enter the correct admin (timelock) and Comptroller when deploying to mainnet.

I do agree with @brendan_dharma that a more formalized process here is definitely needed and now is the time to set it up.


Agreed, would be good to codify before and let these markets be a clear example of how v1 of the framework can be leveraged. Would love to help out here as well! We should set up a call sometime in the next few days to get the ball rolling.

It is hard to make a formal framework when everything is changing as fast as it is in DeFi. That being said, I’m happy to give my input if someone wants to take the lead on this.

Here is the general flow I am following/doing:

  1. Before the forum post: The proposer really needs to ask themselves if their proposed market is ready to be on Compound and they need to ask themselves if they are willing to fight for it to be listed.

  2. Forum post: It should include a summary/bio of the asset, some info on token distribution, mintability, liquidity/trading stats, why Compound should add it, proposed parameters, and testnet deployment.

  3. Initial community feedback: If the forum post has a warm reception and the testnet deployment is good then launch on mainnet.

  4. Mainnet community feedback: If the mainnet token deployment is done correctly and the community is happy the proposer should make a governance proposal or CAP to add the asset.

  5. After initial listing: The proposer should post a recommendation for a collateral factor (and any other parameters they want to set) and rationale.

  6. Parameter community feedback: Give the community an opportunity to give their input. If a rough consensus is reached then deploy a proposal/CAP for the changes.

As for what default parameters the proposer should use. I recommend finding the most similar asset on the protocol and using that as a starting place. Much of what has been done so far in this proposal is based on the recent cLINK and cCOMP additions.

I think there is a balance between bureaucracy and efficiency. I don’t know what the answer is but I hope to set a good example for the community


I think this is a great sequence to follow, but I meant more a risk framework for determining if an asset should be added to Compound.

Some of the factors that come to mind for me:

  2. Liquid MCAP
  3. Avg Daily Trade Volume on DEXes
  4. Avg. Volatility (1hr, 6hr, 12hr, Daily, and Weekly)
  5. Mintable?
  6. Economic Concentration (Herfindahl Index? Known Treasury / Founder / VC holdings?)
  7. Time since Token Launch
  8. Time since last exploit

The idea being we can use this risk framework to make these decisions less arbitrary and more rule-based.


Just wanted to state full agreement here about Compound being overdue for an asset listing / risk assessment framework.

For context, Aave’s risk framework (Methodology - Risk) is quite extensive and actively used in discussions on new asset listings and selecting / adjusting collateral ratios. It’s hard to envision any of these new markets being listed and moving off of a zero collateral factor without a similar framework that Compound’s community is aligned on.

Happy to help provide input too, from having been in those discussions within the Aave community. Any community members with risk analysis / actuarial expertise should absolutely jump in too btw, would be a great way to lead and contribute.

Going back to the topic at hand - in support of adding these markets @getty and IMO given that they’re being added at 0% collateral factor, OK to move forward. I don’t see a big risk of setting precedent here, since it seems like there’s enough interest to start on codifying an asset listing framework shortly.

Franklin @ Pantera Capital


Update: We have deployed the contracts to mainnet.

MKR: CErc20Delegator | 0x95b4ef2869ebd94beb4eee400a99824bf5dc325b

npx saddle match 0x95b4ef2869ebd94beb4eee400a99824bf5dc325b CErc20Delegator 0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2 0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b 0xd956188795ca6f4a74092ddca33e0ea4ca3a1395 200000000000000000000000000 "Compound Maker" cMKR 8 0x6d903f6003cca6255d85cca4d3b5e5146dc33925 0xa035b9e130f2b1aedc733eefb1c67ba4c503491f "0x" -n mainnet

SUSHI: CErc20Delegator | 0x4b0181102a0112a2ef11abee5563bb4a3176c9d7

npx saddle match 0x4b0181102a0112a2ef11abee5563bb4a3176c9d7 CErc20Delegator 0x6b3595068778dd592e39a122f4f5a5cf09c90fe2 0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b 0xd956188795ca6f4a74092ddca33e0ea4ca3a1395 200000000000000000000000000 "Compound Sushi Token" cSUSHI 8 0x6d903f6003cca6255d85cca4d3b5e5146dc33925 0xa035b9e130f2b1aedc733eefb1c67ba4c503491f "0x" -n mainnet

AAVE:CErc20Delegator | 0xe65cdb6479bac1e22340e4e755fae7e509ecd06c

npx saddle match 0xe65cdb6479bac1e22340e4e755fae7e509ecd06c CErc20Delegator 0x7fc66500c84a76ad7e9c93437bfc5ac33e2ddae9 0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b 0xd956188795ca6f4a74092ddca33e0ea4ca3a1395 200000000000000000000000000 "Compound Aave Token" cAAVE 8 0x6d903f6003cca6255d85cca4d3b5e5146dc33925 0xa035b9e130f2b1aedc733eefb1c67ba4c503491f "0x" -n mainnet

YFI: CErc20Delegator | 0x80a2ae356fc9ef4305676f7a3e2ed04e12c33946

npx saddle match 0x80a2ae356fc9ef4305676f7a3e2ed04e12c33946 CErc20Delegator 0x0bc529c00c6401aef6d220be8c6ea1667f6ad93e 0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b 0xd956188795ca6f4a74092ddca33e0ea4ca3a1395 200000000000000000000000000 "Compound" cYFI 8 0x6d903f6003cca6255d85cca4d3b5e5146dc33925 0xa035b9e130f2b1aedc733eefb1c67ba4c503491f "0x" -n mainnet

Once someone from the community confirms the deployment has the expected parameters, I will work with Chainlink to deploy the new oracle contract.

1 Like