Add Markets: MKR, AAVE, SUSHI, YFI

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

MKR, AAVE, SUSHI, and YFI are well established projects in the space and they will be valuable additions to Compound. The decision to use a starting collateral factor of 0 also mitigates the risk posed by the asset listing and we look forward to discussing how we can raise those collateral factors over time. LINK is also ripe for a CF update.

Brendan makes some good points about potential risk factors, to chime in here, one other potential risk factor is the behavior of borrowers, which can change over time. The more aggressive people are with their collateral ratio, the more collateral is at risk for liquidation. At Gauntlet, we’ve thought about these risk factors quite a bit, and I’d be happy to help with a listing framework as well.


Manually verifying the following:

cMKR: 0x95b4eF2869eBD94BEb4eEE400a99824BF5DC325b
cSUSHI: 0x4B0181102A0112A2ef11AbEE5563bb4a3176c9d7
cAAVE: 0xe65cdB6479BaC1e22340E4E755fAE7E509EcD06c
cYFI: 0x80a2AE356fc9ef4305676f7a3E2Ed04e12C33946

  • Underlying addresses correct
  • Admin correct
  • Comptroller correct
  • Decimals correct
  • Implementation correct
  • Initial exchange rates correct
  • Interest rate models are good
  • Names look good
  • Symbols look good
  • Source code looks good
  • Contract compiled with version v0.5.16+commit.9c3226ce and optimized using 200 runs as is standard
  • Everything else looks good

Now we just need some simulations similar to this one to ensure that the proposal and market addition work as expected.

Great work @getty !


Would just like to advocate about the addition of xsushi vs sushi.

The idea is to bring in more liquidity to the protocol, it would be hard to draw individuals to bring in sushi itself and earn anything near the yield via sushi/Kashi.

Most holders enjoy the ability to stake then have the ability of utilizing xsushi to use as collateral while still enjoying the staking apys and the platform fee kickback.

Been doing a deeper dive into other protocols allowing xsushi to be deposited as collateral.
Cream 0%
Aave .02%
Rari 0%
Kashi .01%

I’m not familiar with the technicals of supporting the xsushi token, but would be worth a longer convo.

The new price oracle has been deployed: UniswapAnchoredView | 0x6D2299C48a8dD07a872FDd0F8233924872Ad1071

A simulation of the new price oracle and cMKR is ready as well. Here is the snippet. I’ll post the link to the Github fork with all of the simulations tomorrow.

`#!/usr/bin/env yarn repl -s


– Token holder addresses for mocking
Alias CompHolder “0x7587caefc8096f5f40acb83a09df031a018c66ec”
Alias MakerHolder “0x05e793ce0c6027323ac150f6d45c2344d28b6019”
Alias CUSDCHolder “0x5e34bc93a7506ecc8562ade4d5c8b090247a6349”

Web3Fork “” (CompHolder MakerHolder CUSDCHolder)
UseConfigs mainnet

– update to the new oracle implementation
Alias NewOracle “0x6D2299C48a8dD07a872FDd0F8233924872Ad1071”

– Delegate and propose update
From CompHolder (Comp Delegate CompHolder)
From CompHolder (GovernorBravo GovernorBravoDelegator Propose “Update Oracle” [(Address Comptroller)] [0] ["_setPriceOracle(address)"] [[(address NewOracle)]])

Print “New Oracle Set”

– Fast forward, vote, queue, execute
AdvanceBlocks 14000
From CompHolder (GovernorBravo GovernorBravoDelegator Proposal LastProposal Vote For)
AdvanceBlocks 20000
GovernorBravo GovernorBravoDelegator Proposal LastProposal Queue
IncreaseTime 604910
GovernorBravo GovernorBravoDelegator Proposal LastProposal Execute

– Delegate and propose update
From CompHolder (Comp Delegate CompHolder)
From CompHolder (GovernorBravo GovernorBravoDelegator Propose “Add MKR Market” [(Address Comptroller) (Address Comptroller) (Address cMKR)] [0 0 0] ["_supportMarket(address)" “_setCollateralFactor(address,uint256)” “_setReserveFactor(uint256)”] [[(address cMKR)] [(address cMKR) 0] [250000000000000000]])

– Fast forward, vote, queue, execute
AdvanceBlocks 14000
From CompHolder (GovernorBravo GovernorBravoDelegator Proposal LastProposal Vote For)
AdvanceBlocks 20000
GovernorBravo GovernorBravoDelegator Proposal LastProposal Queue
IncreaseTime 604910
GovernorBravo GovernorBravoDelegator Proposal LastProposal Execute

– Assert cMKR market supported
Assert True (Comptroller CheckListed cMKR)

– Ensure accrue interest works
CToken cMKR AccrueInterest

– Mint test
From MakerHolder (Erc20 MKR Approve (Address cMKR) 10e18)
From MakerHolder (CToken cMKR Mint 10e18)
Assert Equal (Erc20 MKR TokenBalance cMKR) (10e18)

– Borrow test
From CUSDCHolder (CToken cMKR Borrow 1e18)
Assert Equal (Erc20 MKR TokenBalance CUSDCHolder) (1e18)
Assert Equal (Erc20 MKR TokenBalance cMKR) (9e18)

– Repay borrow test
From CUSDCHolder (Erc20 MKR Approve (Address cMKR) 1e18)
From CUSDCHolder (CToken cMKR RepayBorrow 1e18)
Assert Equal (Erc20 MKR TokenBalance CUSDCHolder) (0)
Assert Equal (Erc20 MKR TokenBalance cMKR) (10e18)

– Redeem test (note: 50 cMKR == 1 MKR initially)
From MakerHolder (CToken cMKR Redeem 50e8)

Print “cMKR integration ok”`

Expect to see a governance proposal for adding MKR to the protocol tomorrow or in the next few days.


The simulations for each asset can be found here

1 Like

The proposal has been submitted on chain. Voting begins after the 2 day governance analysis period - you can set up or change your delegation during this period before voting goes live.

Thanks to Getty and Eddy for pushing this forward!


The compound multisig has accepted ownership at 0x6D2299C48a8dD07a872FDd0F8233924872Ad1071. See the transaction here:
TX details


Does anyone mind if the next proposal groups SUSHI, AAVE, and YFI? I think they will all pass unanimously. To be timely and efficient, I think we should group them.


First off, kudos to everyone on this thread in getting cMKR proposed :clap:

@getty if there are no strong arguments against the idea of grouping AAVE/SUSHI/YFI, I think a single proposal to add the remaining assets would make a lot of sense; the updated price feed will already be live, and the addition of three should add little risk over the addition of one.


Bundled proposal to add AAVE, SUSHI, & YFI has been submitted. Voting starts Thursday at ~ 2300 UTC.


Excited to see these tokens potentially coming to Compound!

I’d reiterate the benefits shared above of using xSushi over Sushi, which tends to get much higher engagement on other lending platforms. @getty you said potentially both could be added?


I think listing the underlying is more useful than listing xSUSHI, but we could certainly list it as well. Maybe in a month or two, we can evaluate the SUSHI market and consider adding xSUSHI.