Initialize Compound III (USDC on Polygon PoS)

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


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.


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

At launch, we propose accepting:

  • WETH
  • WBTC
  • 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:

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.


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.


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.


: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.


Really excited for this.

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

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.

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.