Initialize Compound III (USDC on Polygon PoS)

{Parts of this proposal have been taken from rleshner’s proposal for USDC on Ethereum.}

Background

Compound III is a next-generation collateralized borrowing protocol, designed for security, capital efficiency, low gas costs, and streamlined governance.

Each deployment of Compound III features a single borrowable asset. Borrowers supply collateral, which is isolated and remains their property–it is never rehypothecated or withdrawable by other users (except during liquidation).

By removing every unnecessary feature and use-case, upgrading the risk engine (and capital efficiency), and focusing on a single borrowable asset, the protocol has the potential to be the safest & most appealing tool for borrowers ever designed.

Polygon PoS is a proof of stake chain built on Ethereum. WIth over $1.8 billion in TVL across DeFi protocols, Polygon is the largest DeFi ecosystem across all Ethereum scaling solutions. Alongside Compound, Polygon acknowledges Ethereum as the premier blockchain for decentralization and developer talent, however the gas fees can be prohibitive for many users. With a mission to provide #DeFiForAll, Polygon aims to provide an extremely cheap yet secure DeFi experience for users across the globe, regardless of wealth status. In order to create the best DeFi ecosystem across blockchains, Polygon hopes to see Compound III launch so that users can benefit from a robust lending system in an affordable manner.

Proposal

Initialize Compound III on Polygon with USDC as the borrowable asset. Seed the market with 500k USDC.

At launch, we propose accepting:

  • WETH
  • WBTC
  • MATIC
  • USDC
  • DAI
  • USDT

Protocol Launch

Referencing rLeshner’s proposal, the launch of a new compound III market first begins by raising the supply caps of the collateral assets (each individual). The function called is updateAssetSupplyCap in the Configurator 5. This will be a total of 8 actionsThe supply cap changes are summarized below:

Asset WETH COMP DAI USDT MATIC WBTC
Supply Cap 5400 40000 7500000 5000000 3000000 420

The next (9th) action is to deploy and upgrade to the newly configured implementation for the market. The proposal calls the deployAndUpgradeTo function of the ProxyAdmin contract, which is the only contract capable of changing the implementation of the proxy. This wrapper function also takes care of deploying the new implementation from the factory contract 1, using the previously set configuration in the Configurator.

The final (10th) action is a simple ERC20 transfer from the Timelock to the new market, adding 500,000 USDC of reserves.

Reasoning:

As an EVM compatible chain, the deployment of Compound III markets on Polygon will be seamless. Given the contracts have been tested, audited, and deployed to production for the USDC market on Ethereum, there should be little security concern for also deploying on Polygon.

Having USDC as the borrowable asset brings two major benefits, namely in security and utilization. Referencing the IMF’s Global Financial Stability report from April of this year, over 90% of borrowing in DeFi is denominated in stablecoins. Thus, to ensure sufficient utilization of borrowed assets, USDC presents a highly demanded asset. Additionally, having USDC as the borrowable asset enables safer borrowing for users. By accepting volatile assets such as WETH, WBTC, MATIC as collateral, users need only track their collateral value to ensure they avoid liquidation, rather than worrying about the borrowed asset increasing in value while the collateral decreases. While Compound has a robust liquidation mechanism, this brings benefits to users of the platform so that they can practice healthy borrowing.

Seeding the market with 500K USDC at launch will help create a sustainable market from Day 1. Reserves create a liquidity and loss cushion for users, and enable new dynamics introduced by the upgraded interest rate models in Compound III.

9 Likes

been waiting for compound on polygon, this looks like the perfect implementation

1 Like

In general i believe it would be good to expand v3 to polygon. Though there are some concerns in that proposal. I don’t see issues with WETH, WBTC as being collateral, as well as other smaller tokens like Uni, Comp can be also added.

USDT isn’t a collateral asset on Compound it needs a discussion even if should be a collateral at all.
DAI is also up to debate if it should be supported as collateral, as bringing stable token as a collateral to v3 is also debatable proposal. It’s possible, but up to governance.
USDC can’t be a collateral, as you propose it as a base asset.

MATIC isn’t a supported token in Compound so far. It’s a perspective one though, and it might be benefitial to onboard it, but it requires a governance decision by itself.

So, i’d say one thing is to initialise comp v3 on polygon with already supported selected assets, and the other thing is to have the proposal in it’s full. I’d suggest to split it in several stages, with first one possibly launching on polygon with same configuration as on eth mainnet. And following it with additional proposals concerning other perspective assets.

3 Likes

:tada: @hamzahkhan! Great to see momentum towards a Polygon PoS proposal :raised_hands:

The Compound team is actively working on testing a Mumbai deployment, governed from Goerli; analogous to the setup between mainnet Ethereum and Polygon PoS. While true that the protocol contracts will be the same, there are a couple of new contracts involved (a bridge receiver contract and timelock), and the assets should all be vetted and price feeds confirmed/discussed.

There are restrictions on what assets can be listed as collateral in v3 (i.e. non-rebalancing, no transfer fee), so the assets should be triple and quadruple checked by the community. The price feeds must be reliable and governance should deem each of them as non-manipulatable, understanding the power each price feed address has in the protocol.

I also agree with @Sirokko that the initial set of assets should be relatively minimal, to ease the governance decision-making for launch.

4 Likes

Really excited for this.

1 Like

This is awesome news, been waiting for this for a very long time!

1 Like

The cross-chain governance aspect is especially exciting as it is new for Compound. Are the bridge receiver contract and L2 timelock publicly posted in the comet github yet? I didn’t see them there but I might have been looking in the wrong place. Maybe this isn’t the right place for questions about the mechanism, but I’m curious whether the bridge receiver is specifically for governance-initiated asset transfers, like seeding the USDC reserves from the Comptroller on mainnet, or if there would be any interfacing with the bridge receiver contract by third-party contracts / EOAs.

1 Like

Great questions! It’s all being worked on in the public GitHub repository (warning: this PR is under active development :construction:).

Overall, the current scheme for multi-chain would cover any deployment which can be governed directly by Compound Governance on mainnet. There are other possibilities besides that, but those are probably further in the future and require other development. In general this means, using a message-passing bridge which Governance decides to trust to deliver messages. Within that set, the idea is to start first with L2 deployments (which essentially by definition have a native bridge), since this reduces the Governance decision to trusting just the L2 chain. The step after L2s, would be to build a receiver for some other (Governance trusted) message-passing bridge, which could then be used on whatever chains that bridge is bridged to.

The interface needed by governance is the ability to send a message to a contract on the L1, which encodes a set of actions (targets + calls) for the remote chain. The interface needed by the protocol, is a ‘governor’ (contract) address (which is the Timelock contract on mainnet). In general, we think there should also be a Timelock in front of the protocol (on the receiving side of the bridge), which is its governor, and the admin of that should in turn be some provable governance proxy address, which depends on the details of the message-passing bridge interface, which is effectively what the bridge receiver contract is.

So, the bridge receiver doesn’t have any knowledge or details about assets like USDC. That would be handled by Governance deciding what the USDC address is and constructing the protocol deployment using it, and using whatever mechanisms are available for bridging or providing that asset are already/externally available for it. The bridge receiver is the local address for a contract which Governance believes to be a reliable proxy for its messages on the bridged chain.

5 Likes

:shushing_face:

2 Likes

Yes please :slight_smile: . Would be massive.

Following the conversations on this thread, recent community calls, Discord, and GitHub, a cUSDCv3 market has been deployed to Polygon from this pull request.

The parameters to enable the market are being finalized on this pull request, and will be discussed next week on the upcoming developer call, as we await Gauntlet’s recommendations on the following risk parameters:

WBTC: $_ supply cap (_ tokens), _% CF, _% LCF, and _% liquidation fee
WETH: $_ supply cap (_ tokens), _% CF, _% LCF, and _% liquidation fee
WMATIC: $_ supply cap (_ tokens), _% CF, _% LCF, and _% liquidation fee

The interest rate model is currently configured the same as cUSDCv3 on mainnet. After the launch of the market, Gauntlet will monitor and consider recommendations to the interest rate model based on preliminary utilization & growth.

The assets and price feeds of the deployment use the following inputs:
The base asset, USDC, uses 0xfE4A8cc5b5B2366C1B58Bea3858e81843581b2F7.
For WBTC, 0xDE31F8bFBD8c84b5360CFACCa3539B938dd78ae6.
For WETH, 0xF9680D99D6C9589e2a93a78A04A279e509205945.
For WMATIC, 0xAB594600376Ec9fD91F8e885dADF0CE036862dE0.

Considerable effort has gone into testing this deployment, however this will be the first multi-chain deployment of Comet, as well as the first proposal executed across the bridge on mainnet, we therefore recommend relatively conservative parameters when it comes to seeding reserves and rewards for the new market. We do recommend seeding these values though, to account for the current interest rate model and bootstrapping phase.

OpenZeppelin has completed an additional audit of the bridged governance contracts and flows.

Finally, see the Initialization Proposal section below for more information about the next steps to enable the deployed market. Note that the proposal includes the actions from the recent Initialize ENS proposal (which failed to reach quorum). Maintaining the official markets list is an important precedent to establish as governance moves forward into governing a multi-chain world.

Deployed Contracts

cUSDCv3: 0xF25212E676D1F7F89Cd72fFEe66158f541246445

This is the main proxy contract for interacting with the new market. The address should remain fixed and independent from future upgrades to the market. It is an OpenZeppelin TransparentUpgradeableProxy contract.

cUSDCv3 Implementation: 0x58db165A3CC86A2955f7A270120E68236b57D819

This is the implementation of the market logic contract, as deployed by the Comet Factory via the Configurator.

cUSDCv3 Ext: 0xbdE8F31D2DdDA895264e27DD990faB3DC87b372d

This is an extension of the market logic contract which supports some auxiliary/independent interfaces for the protocol. This is used to add additional functionality without requiring contract space in the main protocol contract.

Configurator: 0x83E0F742cAcBE66349E3701B171eE2487a26e738

This is a proxy contract for the ‘configurator’, which is used to set and update parameters of a Comet proxy contract. The configurator deploys implementations of the Comet logic contract according to its configuration. This pattern allows significant gas savings for users of the protocol by ‘constantizing’ the parameters of the protocol.

Configurator Implementation: 0x9c4ec768c28520B50860ea7a15bd7213a9fF58bf

This is the implementation of the Configurator contract, which can also be upgraded to support unforeseen changes to the protocol.

Proxy Admin: 0xd712ACe4ca490D4F3E92992Ecf3DE12251b975F9

This is the admin of the Comet and Configurator proxy contracts. It is a ProxyAdmin as recommended/implemented by OpenZeppelin according to their upgradeability pattern.

Comet Factory: 0x2F9E3953b2Ef89fA265f2a32ed9F80D00229125B

This is the factory contract capable of producing instances of the Comet implementation/logic contract, and invoked by the Configurator.

Rewards: 0x45939657d1CA34A8FA39A924B71D28Fe8431e581

This is a rewards contract which can hold rewards tokens (e.g. COMP, WMATIC) and allows claiming rewards by users, according to the core protocol tracking indices.

Bridge Receiver: 0x18281dfC4d00905DA1aaA6731414EABa843c468A

Receives bridged governance messages from the Polygon FxChild contract and forwards them to the bridge timelock.

Bridge Timelock: 0xCC3E7c85Bb0EE4f09380e041fee95a0caeDD4a02

The governor of the Comet deployment, exclusively receiving input from Ethereum mainnet governance through the bridge receiver.

Initialization Proposal

To initialize the market, the deployment process is similar to the initialization of cUSDCv3 on Ethereum mainnet, the primary difference being the bridging of governance actions to Polygon, instead of taking place directly on the governance chain (Ethereum mainnet).

The proposal is currently prepared and tested using best guesses for final parameters and decisions from the community, which are intended to be discussed next week.

The initialization proposal will take the following actions:

  1. Set Comet configuration and deploy new Comet on Polygon. This sends the encoded setConfiguration and deployAndUpgradeTo calls across the bridge to the governance receiver on Polygon.
  2. Approve Polygon’s ERC20Predicate to take Timelock’s USDC, in order to seed the market reserves through the bridge.
  3. Deposit USDC from mainnet to the Polygon RootChainManager contract to bridge to Comet.
  4. Approve Polygon’s ERC20Predicate to take Timelock’s COMP, in order to seed the rewards contract through the bridge.
  5. Deposit COMP from mainnet to the Polygon RootChainManager contract to bridge to CometRewards.
  6. Set up the ENS subdomain v3-additional-grants.compound-community-licenses.eth, with the Timelock as the owner.
  7. Write the ENS TXT record v3-official-markets on v3-additional-grants.compound-community-licenses.eth containing the official markets JSON.

The deployment and proposal migrations have been built using the Comet scenario framework and deployed using the Comet deployment manager. The deployment was run through a GitHub action using seacrest and the scenario checks can be seen from the proposal branch CI checks.

14 Likes

Gauntlet Initial Asset Recommendations - Compound v3 Polygon USDC Comet

Summary

We provide two options to the community below. Option 1 is very conservative for the purpose of testing out Compound V3 mechanics. As such, the conservatism is less so derived from market risk (which is Gauntlet’s focus) but more so on the smart contract and other technical risks. Option 2 is less conservative and assumes that the community does not need to test Compound V3 mechanics on a new chain.

Option 1: Very Conservative (Test out Mechanics)

WETH WBTC WMATIC
Supply Cap 1800 ($3.02M) 80 ($1.97M) 1M ($1.41M)
Liquidation Factor 50% 45% 40%
Collateral Factor 45% 40% 35%
Liquidation Bonus 5% 5% 7%

Storefront price factor: 60%
IR Curve: Same as Ethereum USDC comet

Option 2: Conservative (Assume mechanics are working, then gradually increase aggressiveness of parameters)

WETH WBTC WMATIC
Supply Cap 11k ($18.5M) 400 ($9.9M) 10M ($14.1M)
Liquidation Factor 82.5% 75% 70%
Collateral Factor 77.5% 70% 65%
Liquidation Bonus 5% 5% 7%

Storefront price factor: 60%
IR Curve: Same as Ethereum USDC comet

The supply caps are set as a function of on-chain liquidity and can be increased after the initial launch. The proposed LFs for the initial listing are set conservatively while still being capital efficient enough for usability.

By approving this proposal, you agree that any services provided by Gauntlet shall be governed by the terms of service available at gauntlet.network/tos.

4 Likes

Thanks @pauljlei and Gauntlet team for preparing these recommendations! We’ve updated the parameters according to Option 2 in the proposal pull request. We were going to make this proposal today, but thought better of it given the late in the day timing and what would be Saturday execution on Polygon. This will also allow time for the community to review the parameter options, and final proposal details before making it.

6 Likes

To update this thread, the proposal was made yesterday and will be in review for another 18 hours until voting begins!

4 Likes

As the cUSDCv3 Polygon market continues to grow steadily, Compound Labs intends to propose refreshing the supply of COMP available for rewards on Polygon. The initial proposal transferred a relatively conservative amount of COMP, as was deemed prudent for the first multi-chain market instance and proposal. The draft proposal can be found on this pull request, and aims to renew the supply for an additional year at the current speeds (approximately).

4 Likes

I previously recommended deploying a native USDC comet on Base, I am now recommending the same for Polygon as Circle now support native USDC on Polygon.

I would however state that we should allow some time to pass for the supply of native USDC to grow, as it pales in comparison to that of bridged USDC, before such a comet is introduced.

In the meantime, it may be prevalent to rename the market for bridged USDC on Polygon to show that it is for bridged USDC, as it currently doesn’t.

2 Likes