Native USDC support

Deployed proxy contracts

ARB Mainnet: https://arbiscan.io/address/0xaf88d065e77c8cc2239327c5edb3a432268e5831#code

OP Mainnet: https://optimistic.etherscan.io/token/0x0b2c639c533813f4aa9d7837caf62653d097ff85#code

Holesky (meant to be the 'native' - mock - USDC for Taiko's A6 testnet): https://holesky.etherscan.io/address/0x6436d7B483a35516F7cD19379a392Ce9bD0B2852#code

Taiko A6: https://blockscoutapi.katla.taiko.xyz/address/0xB6C1f33da0cd2679778C6B3aD5c421d4d4EE8E64/contracts#address-tabs

Proof of compliance: Deployed bytecode only differs in signature!

Deployed implementation contracts

ARB Mainnet: https://arbiscan.io/address/0x86E721b43d4ECFa71119Dd38c0f938A75Fdb57B3#code

OP Mainnet: https://optimistic.etherscan.io/address/0xdEd3b9a8DBeDC2F9CB725B55d0E686A81E6d06dC#code

Holesky (meant to be the 'native' - mock - USDC for Taiko's A6 testnet): https://holesky.etherscan.io/address/0xDB61fa2Da6E855a376AdB4f6754eF804bA7DD489#code

Taiko A6: https://blockscoutapi.katla.taiko.xyz/address/0xAc032D2aE041F132c94d0f660bC20051bBd77723/contracts#address-tabs

Proof of compliance: Deployed bytecode only differs in signature!

Deployment and verification

Deployment scipt:

forge script DeployUSDC --fork-url=https://rpc.katla.taiko.xyz/ -vvvv --broadcast

Verification scipt for token:

forge verify-contract CONTRACT_ADDRESS src/FiatToken/centre-tokens/contracts/v2/FiatTokenV2_2.sol:FiatTokenV2_2 --watch --verifier-url "https://blockscoutapi.katla.taiko.xyz/api?module=contract&action=verify" --verifier blockscout --chain-id 167008

Verification scipt for proxy (currently for proxy, blockscout having issues with automated verification, but manually, via the UI it works):

forge verify-contract PROXY_ADDRESS src/FiatTokenProxy/centre-tokens/contracts/v1/FiatTokenProxy.sol:FiatTokenProxy --watch --verifier-url "https://blockscoutapi.katla.taiko.xyz/api?module=contract&action=verify" --verifier blockscout --chain-id 167008 —-constructor-args “0xEa9cFC899E609F8d31b7111B716BB3C37Da0c198”

Bridged USDC Standard

For original document please click here.

Explanation why this separate repo is needed

According to the official documentation, it needs to be bytecode eqivalent, and compiler settings (solc, optimizations) are different see below:

Compiler settings

module.exports = {
  compilers: {
    solc: {
      version: "0.6.12",
      settings: {
        optimizer: {
          enabled: true,
          runs: 10000000,
        },
      },
    },
  },

Repo cloned from: https://vscode.blockscan.com/arbitrum-one/0xaf88d065e77c8cc2239327c5edb3a432268e5831

From original documentation:

Bridged USDC Standard is a specification and process for deploying a bridged form of USDC on EVM blockchains with optionality for Circle to seamlessly upgrade to native issuance in the future.¹

The result is a secure and standardized way for any EVM blockchain and rollup team to transfer ownership of a bridged USDC token contract to Circle to facilitate an upgrade to native USDC, if and when both parties deem appropriate.²

This document provides a high-level overview of the process. Note that this is also extensible to implementations of bridged EURC (Circle’s euro-backed stablecoin).

How it works

1. Third-party team follows the standard to deploy their bridge contracts, or retains the ability to upgrade their bridge contracts in the future to incorporate the required functionality. (See Bridge Contracts)
2. Third-party team follows the standard to deploy their bridged USDC token contract. (See Token Deployment)
3. If and when a joint decision is made by the third-party team and Circle to securely transfer ownership of the bridged USDC token contract to Circle and perform an upgrade to native USDC, the following will take place:
   • Third-party team will pause bridging activity and reconcile in-flight bridging activity to harmonize the total supply of native USDC locked on the origin chain with the total supply of bridged USDC on the destination chain.
   • Third-party team will securely re-assign the contract roles of the bridged USDC token contract to Circle.
   • Circle and the third-party team will jointly coordinate to burn the supply of native USDC locked in the bridge contract on the origin chain and upgrade the bridged USDC token contract on the destination chain to native USDC.
4. The native USDC token contract seamlessly retains the existing supply, holders, and app integrations of the original bridged USDC token contract.

Bridge Contracts

The third-party team’s bridge contracts must be upgradeable to add required, specific functionality at a later point in time to support the upgrade steps above, once Circle and the third-party team jointly decide to perform the upgrade.

Token Deployment

The third-party team’s bridged USDC token contract is expected to be identical to native USDC token contracts on other EVM blockchains. USDC uses a proxy pattern, so the standard applies to both the implementation contract code and the token proxy.

Token Contract Code

Using identical code facilitates trustless contract verification by Circle and supports a seamless integration with existing USDC services. To facilitate this, the third-party team may choose one of the following:

• Copy previously deployed bytecode from a recent, native USDC token contract deployment (both proxy and implementation) on an EVM blockchain, for example Arbitrum, Base, OP Mainnet, or Polygon PoS. Note that you must supply different constructor and initializer parameters where needed.
• Build the FiatToken contracts from source. In this case, the compiler metadata must be published or made available to support full contract verification. Various suggested compiler settings that Circle uses can be found here, which will allow the third-party team to reach the same bytecode if followed consistently.

Token Naming

Circle has recommended naming guidelines for the Token Name and Token Symbol attributes of a bridged USDC token contract that third-party teams are encouraged to follow. It is often the case that USDC is bridged from Ethereum to a new destination blockchain, and as such, the following is commonly used:

• Token Name: Bridged USDC (Third-Party Team)
• Token Symbol: USDC.e

Note that the text shown in parentheses above would be the third-party team’s company name.

IMPORTANT NOTE:

• Once deployed, the bridged USDC token contract must not be upgraded to a new or different implementation at any time, outside of subsequent FiatToken versions authored by Circle.
• FiatToken has a number of one-time use initialization functions (listed below) that are not permissioned, and therefore should be called during contract deployment.
  • Due to the proxy pattern used by FiatToken, after (or while) specifying the current implementation that the proxy points to, these initialization functions must be called to set the values correctly on the proxy's storage. If not, then any caller could invoke them in the future.
  • It is also recommended to call these functions directly on the implementation contract itself, separately from the proxy, to disallow any outside caller invoking them later. At the timing of writing, these initialization functions include:
    • initialize
    • initializeV2
    • initializeV2_1
    • initializeV2_2

There are a number of reference deployment scripts in the repository that demonstrate patterns for deploying USDC and configuring the implementation. For instance, there’s an upgrader pattern, where a smart contract sets the FiatToken implementation contract and calls the initialize functions within a single transaction.

Token Roles

FiatToken uses a minter pattern, where minters can be configured via a master minter role to mint up to an allowed amount. One way to adapt the minter pattern to a bridged USDC token contract is to configure the destination bridge as a solo minter.

The individual FiatToken roles (Owner, Pauser, Blacklister, MasterMinter) could also be assigned to the bridge, or some other upgradeable contract, as long as there's the ability to add a hook in the future to enable transferring the roles to Circle.

If you would like more flexibility with permissioned minter configurations, you may want to explore the Controller and MinterController contracts, which come together to form the MasterMinter pattern.

For more information

Please reach out on our Discord if you have questions that were not addressed in this document. We value feedback and suggestions from the community to improve our documentation.

---

1. Bridged USDC Standard grants Circle the option, but not the obligation, to obtain ownership of the token contract and upgrade to native USDC. Additionally, Bridged USDC Standard must be incorporated prior to deploying a bridged USDC token contract as it cannot be retroactively applied. The requirements provided are for informational purposes only and will apply should Circle choose to upgrade a particular form of bridged USDC to native USDC. These requirements do not constitute an offer to upgrade a particular form of bridged USDC. Circle’s decision to upgrade a particular form of bridged USDC to native USDC may be subject to additional terms and conditions. As noted in Section 8 of the USDC Terms of Use, bridged forms of USDC are subject to certain risks and are not issued by Circle.
2. The target blockchain will undergo Circle’s internal Blockchain Due Diligence Process. That process involves reviews for both compliance and risk factors, as well as coverage for legal and technology risks, prior to approval. The diligence focuses on crypto and blockchain nuances, and an assessment of the strategic, financial, operational, technology, legal, and regulatory risks that are present.