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:
- Set Comet configuration and deploy new Comet on Polygon. This sends the encoded
setConfigurationanddeployAndUpgradeTocalls across the bridge to the governance receiver on Polygon. - Approve Polygon’s ERC20Predicate to take Timelock’s USDC, in order to seed the market reserves through the bridge.
- Deposit USDC from mainnet to the Polygon RootChainManager contract to bridge to Comet.
- Approve Polygon’s ERC20Predicate to take Timelock’s COMP, in order to seed the rewards contract through the bridge.
- Deposit COMP from mainnet to the Polygon RootChainManager contract to bridge to CometRewards.
- Set up the ENS subdomain
v3-additional-grants.compound-community-licenses.eth, with the Timelock as the owner. - Write the ENS TXT record
v3-official-marketsonv3-additional-grants.compound-community-licenses.ethcontaining 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.