FRAX Listing Proposal

Another reference point > Aave - Open Source Liquidity Protocol

1 Like

Thanks @inkymaze - it’s exciting to see FRAX supported by Aave. Since the original post, Frax has more than tripled in supply, completed an audit with Trail of Bits and also has a FRAX / USD Chainlink price feed which should address @jmo concerns:

It’s nice to see the interest in the newer generation of stablecoins that are actually stable (shoutout to FEI for their recent success and having an awesome community overall). Let me know if you have any questions, would love to move this forward.


Gently bumping this. Frax has been live and stable for nearly a year and has over 1bn FRAX circulating. Frax lending AMOs are currently supplying over $100m of liquidity to other lending platforms. If Compound adds FRAX, there will be liquidity. Frax has chainlink price feeds. If Gauntlet or other’s see any issues here, I’d be happy to try and find the right person to address them - otherwise would love to push this forward.

Gauntlet is recommending that FRAX be added as a collateral asset on Compound. FRAX is an exciting new stablecoin that will provide more stablecoin liquidity to the Compound protocol in addition to DAI, USDC, and USDT. By convention, assets are usually listed on Compound with a collateral factor of 0, but given the liquidity and volatility profile of FRAX, the Gauntlet Platform expects to ramp up the FRAX collateral factor post-listing.

Market Risk

FRAX is currently listed on exchanges such as Uniswap, Sushiswap, Solarbeam (on Moonriver), Pangolin (on Avalanche), and more. The liquidity for FRAX has been steadily increasing, with the 90, 60, and 30 day ADVs being $22M, $30M, and $43M respectively.

Note that while the ADV of FRAX is increasing, it is still substantially lower than DAI (roughly 10X lower) and USDC (roughly 50X lower).

FRAX has a 36% annualized volatility over the past month, which is more volatile than DAI (4%) or USDC (2%).


The top 10 FRAX token positions are listed below:

As seen in the chart below, the top 10 positions make up 87.6% of the total FRAX supply. However, the majority of those tokens are either locked in Curve’s FRAX3CRV pool, other exchanges, and bridges.

If FRAX is trading below $1 on exchanges, users are incentivized to burn FRAX in exchange for $1 of USDC and FXS. Conversely, if FRAX is trading above $1 on exchanges, users are incentivized to mint FRAX by depositing USDC and burning FXS, then selling FRAX on the exchange. This way the supplies of FRAX and FXS are controlled while maintaining a peg to the USD. While the FRAX protocol is decentralized, the collateralization mechanism relies on USDC as collateral, which is centrally backed.

Analyzing USDC and FRAX Pegs to USD

Given that FRAX is heavily dependent on USDC, Gauntlet’s platform will carefully analyze how Collateral Factor changes to both USDC and FRAX may affect their respective USD pegs.


Completely agree that FRAX would be a great addition to Compound and looking forward to seeing the proposal soon!

1 Like

Looking forward to seeing the proposal. FRAX has grown substantially over the lifetime of this thread, and the market has shown its durability. We support the addition of FRAX as an asset on Compound.

1 Like

Agree with the above, Blockchain at UCLA supports this proposal to add FRAX as an asset to Compound

Blockchain@Columbia supports this proposal to add FRAX to compound given appropriate risk parameters are added. We think that it is important to add more stablecoins on the decentralization spectrum to Compound to help support their usage in the ecosystem and give users the widest variety of assets to borrow/lend on Compound.

Hi guys, I’m with the Frax team and I’ve gone ahead and deployed the necessary contracts as well as added the necessary tests and configs to push this proposal onchain.


cFRAX: CErc20Delegator | 0x1ddaAfEe72Ffc6Cd60368f17cEB376692F69515F
New Uniswap Anchored View which includes cFRAX: UniswapAnchoredView | 0x15dE940e76Ad5771C49bb82D5083C9148Af9fDD0
cFRAX Validator Proxy: ValidatorProxy | 0x5B24EA09De554175Dd5431533Aad223c7C3583E4

cFRAX was deployed to match other stables:
Underlying: 0x853d955acef822db058eb8505911ed77f175b99e
Comptroller: 0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b
InterestRateModel (matches USDC): 0xd8ec56013ea119e7181d231e5048f90fbbe753c0
InitialExchangeRate(matches USDC): 2000000000000000000
Name: Compound Frax
Symbol: cFRAX
Decimals: 8
Admin: 0x6d903f6003cca6255d85cca4d3b5e5146dc33925
Implementation: 0x24aa720906378bb8364228bddb8cabbc1f6fe1ba

We used the same Implementation/CErc20Delegate as cLINK and cWBTC2, which I believe is standard, but can change this in the proposal if it’s necessary.

The new Uniswap Anchored View has all the same configs as the existing one, 0x046728da7cb8272284238bd3e47909823d63a58d, with the addition of cFRAX. A diff of the config arrays, pulled from on-chain, can be found here:

The cFRAX Validator Proxy was copied from USDP’s recently deployed one. Aggregator is set to the one used by Chainlink FRAX/USD: 0x61eb091ea16a32ea5b880d0b3d09d518c340d750, and the Validator is set to the new Uniswap Anchored View: 0x15de940e76ad5771c49bb82d5083c9148af9fdd0. Ownership has been offered to 0x21f73d42eb58ba49ddb685dc29d3bf5c0f0373ca, like the other Validator Proxies.


I adapted @TylerEther’s tests which he made for USDP, which simulates the proposal, and it passes as expected.
You can see the tests here, and you can see a paste of the successful output here

Pull Requests:

I’ve opened three PRs in the Compound github to add the necessary configs and assets for if the proposal passes. They include the simulation, mainnet config updates for all the new contracts, and a shiny new cFRAX token icon.


Hopefully this is what we need to push the proposal on-chain!


Thanks, @corddry . As an update to the Compound Community, Gauntlet has been working on this listing with the FRAX team and has analyzed the economic risks of listing FRAX on Compound. We plan on putting up an on-chain proposal with an initial CF of 0% and reserve factor of 15%. On the smart contract and technical risk side, we would welcome analysis from the Community and any other interested parties, as Gauntlet is not an auditing firm.


@corddry good job managing to figure all of that out; it’s definitely not easy. Like my first deployment, you also made some similar mistakes :wink:.

Initial exchange rate is incorrect

To quote @mistertom from my LINK market addition thread:

The standard cToken initial exchange rate for Compound is 0.02 scaled . The goal is to have 50 cTokens = 1 underlyingToken when the market is first deployed. In our case for cLINK , the math is:

  • 0.02 * 10^(18 + underlyingDecimals - cTokenDecimals)
  • = 0.02 * 10^(18+18-8)
  • = 0.02 * 10^28 … floating-point representation …
  • = 2e26 … unsigned scaled integer representation … (value used for constructor)

Like LINK, FRAX also uses 18 decimal places, so the initial exchange rate should be 2e26.

Stablecoins have been using a different implementation

The stablecoin implementation is 0xa035b9e130F2B1AedC733eEFb1C67Ba4c503491F.

New stablecoins have been using an improved interest rate model

This improved interest rate model is 0xFB564da37B41b2F6B6EDcc3e56FbF523bD9F2012.

Good job so far!

Thanks @pauljlei for your help! How about a 25% reserve factor? This has become the standard for all new deployments.


Thanks for the feedback! cFRAX has been redeployed with the updated parameters alongside an updated UAV to match.

cFRAX: CErc20Delegator | 0xe7373A0D692F60400AF4A5ac6dfB927840414F86
UAV: UniswapAnchoredView | 0xa469ddb19f903f4de66fdae32eb0d5a87c3826b3

The ValidatorProxy has been updated to point to the new UAV, and I’ve updated the tests and pull requests. Test results are successful and can be found here

New cFRAX parameters:

    "underlying": "0x853d955aCEf822Db058eb8505911ED77F175b99e",
    "comptroller": "0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b",
    "interestRateModel": "0xFB564da37B41b2F6B6EDcc3e56FbF523bD9F2012",
    "initialExchangeRateMantissa": "2.0e26",
    "name": "Compound Frax",
    "symbol": "cFRAX",
    "decimals": "8",
    "admin": "0x6d903f6003cca6255d85cca4d3b5e5146dc33925",
    "implementation": "0xa035b9e130F2B1AedC733eEFb1C67Ba4c503491F",
    "becomeImplementationData": "0x"

Let me know if I missed anything!


Hi @TylerEther , thanks very much for all your help here and for your thoughts. There are tradeoffs to be made whether we list with a 25% versus 15% Reserve Factor. Listing with a higher reserve factor increases protocol revenue from the start. In addition, there might be less user friction in decreasing the reserve factor down the line as opposed to increasing the reserve factor. On the other hand, listing with a lower reserve factor incentivizes suppliers with a higher deposit APY. Incentivizing supply here can be particularly useful given that users won’t be able to use FRAX as a collateral asset from the start. Although most new assets on Compound have listed at a Reserve Factor of 25% (LINK, AAVE, SUSHI, YFI, etc), most stablecoins (with the exception of USDP) currently have a Reserve Factor of 7.5% (and DAI is 15%), therefore, 15% is closer to a steady state value that most other stablecoins have. For these reasons, we will initially list FRAX with a 15% Reserve Factor but our platform will continuously ingest on-chain data to track how market conditions and user positions evolve.

1 Like

As an update, we plan on posting an on-chain proposal to list FRAX the week of February 21. We want to give this 2-weeks long notice period in order to provide enough time to @cylon Open Zeppelin and Community developers to assess and become comfortable with any smart contract / technical risks.



Looks good!

1 Like

Hi everyone, the OpenZeppelin team has been working on a security recommendation for how to handle asset listings that the community needs to consider before moving to list FRAX.

We’ve learned in our ongoing audit of the Compound protocol that the security risks for listing new assets are greater than most of the community might be aware. We’ve also found that a prior Critical issue related to an asset listing already existed and we’ve already worked with the Compound Multisig and the team behind the affected asset to ensure it is patched without incident. We’ll be releasing the complete Compound Audit Report and more details on the bug that was patched in the coming weeks.

Given what we’ve now learned, we believe that asset listing proposals such as this should receive more security attention going forward. We recommend that the community hold off on listing new assets for now as we work to put together a more detailed policy to ensure asset listings do not cause integration issues that could endanger the protocol. One option is to have OpenZeppelin audit each listing proposal although we need to consider the impact this might have on our existing backlog of protocol changes and the priority to assign to each one.

I will follow up early next week with more detailed guidance on a path forward for the FRAX proposal. I understand that it may be frustrating to hold off on listing new assets right now so I ask for your patience as we work to create security processes that will protect Compound while also minimizing proposal wait times as much as possible.

If any of you want to learn more or share thoughts on securing asset listings, please don’t hesitate to reach out to me.


Hey @cylon thanks for sharing your thoughts. I’d love to learn more about the thinking behind your recommendation. What is the best way to do so / reach you?

Hi @josh

We’ve developed an asset listing process at this repository that walks through the process of preparing for an asset listing. The main thing is to provide information requested in the Checklist and then get community validation, have a market analysis from Gauntlet and then perform testing before moving forward.

It looks like you’ve already provided some of the info and gotten simulations and market analysis, so I’d recommend starting by checking what you’re missing from the Checklist. You can reach out to me on Telegram at @cyloncat if you have any questions on this. More on info this process is also described in our April Security Updates

Thank you for the reply and for sharing the checklist. I will run through things on my end and assess where it stands vs. the checklist standards

1 Like

Hey guys-- picking up on this thread with some updates to fill in some pieces of the checklist that might not have been addressed fully before the audit.

Token contract: Frax Finance: FRAX Token | Address 0x853d955acef822db058eb8505911ed77f175b99e | Etherscan

Token Distribution: As a stablecoin integrated deeply throughout DeFi, all of Frax’s top holders are smart contracts. ~700M resides in a curve pool against 3crv and another ~150M resides in the new FraxBP. The rest of the holders with >2% of the supply are FPI-FRAX on Curve, UniV3 FRAX-USDC, UniV2 FXS-FRAX, and the Olympus DAO Treasury.

Permissioned Functionality: The Frax stablecoin has no blacklist, is not pausable, has no external mint perms, etc. The Frax protocol has no ability to change user balances or prevent transactions from happening. The only privileged roles belong to the protocol itself to allow the Frax mint/redeem process and Frax’s signature AMOs. There are no mint permissions outside the protocol. This makes Frax essentially identical to DAI in terms of functionality of the token contract.

Upgadability: The Frax contract has no proxy patterns and the implementation cannot be changed. The only parts of the contract which can be updated are minor parameters regarding the mint/redeem system such as oracles.