From 415a4c79e9360fb6352eb90826349a6baf76f7ef Mon Sep 17 00:00:00 2001 From: Aloysius Chan Date: Mon, 20 May 2024 13:47:27 -0700 Subject: [PATCH] Update bridged USDC standard --- doc/bridged_USDC_standard.md | 75 +++++++++++++++++++----------------- 1 file changed, 39 insertions(+), 36 deletions(-) diff --git a/doc/bridged_USDC_standard.md b/doc/bridged_USDC_standard.md index 46f1de959..b51fc3623 100644 --- a/doc/bridged_USDC_standard.md +++ b/doc/bridged_USDC_standard.md @@ -93,29 +93,24 @@ the token proxy. 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](https://arbiscan.io/token/0xaf88d065e77c8cc2239327c5edb3a432268e5831), - [Base](https://basescan.org/token/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913), - [OP Mainnet](https://optimistic.etherscan.io/token/0x0b2c639c533813f4aa9d7837caf62653d097ff85), - or - [Polygon PoS](https://polygonscan.com/token/0x3c499c542cef5e3811e1192ce70d8cc03d5c3359). - Note that you must supply different constructor and initializer parameters - where needed. - - For EURC, please reference the bytecode from the - [Ethereum](https://etherscan.io/token/0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c) - implementation -- Build the - [FiatToken contracts](https://github.com/circlefin/stablecoin-evm#contracts) - from source. In this case, the compiler - [metadata](https://docs.soliditylang.org/en/latest/metadata.html) must be - published or made available to support full contract verification. Various - suggested compiler settings that Circle uses can be found - [here](https://github.com/circlefin/stablecoin-evm/blob/35d66ae39f7038e30f04f87635f8bca6f8e38b04/truffle-config.js#L34-L45), - which will allow the third-party team to reach the same bytecode if followed - consistently. +the third-party team should: + +1. Build the [FiatToken contracts](../README.md#contracts) from source. Various + suggested compiler settings that Circle uses can be found + [here](../foundry.toml), which will allow the third-party team to reach the + same bytecode if followed consistently. +2. Deploy the locally compiled FiatToken contracts. An overview of the + deployment process can be found [here](./deployment.md). +3. Extract the compiler metadata used to generate the deployed contract's + bytecode and make it available to Circle to support the contract verification + process. The + [compiler metadata](https://docs.soliditylang.org/en/v0.6.12/metadata.html#contract-metadata) + is an autogenerated JSON file that can typically be found in the build + directory on the local machine. + +Circle’s repository is equipped with build tools and scripts that streamline the +process above. The third-party team may refer to the steps listed +[here](../README.md#deployment) to run the deployment. ### Token Naming @@ -185,7 +180,7 @@ may want to explore the Controller and `MinterController` [contracts](https://github.com/circlefin/stablecoin-evm/tree/35d66ae39f7038e30f04f87635f8bca6f8e38b04/contracts/minting), which come together to form the `MasterMinter` pattern. -**Transferring the roles to Circle** +#### Transferring the roles to Circle There are several USDC roles that will be transferred to a Circle-owned address at the time of the upgrade. Specifically these are: @@ -204,15 +199,15 @@ It is up to the third-party team as to how they will secure and manage these roles as part of their original bridged USDC deployment and its ongoing use before a potential upgrade. For instance, the roles could be assigned to a secure multi-sig, or assigned to a smart contract (like the bridge), which can -simplify the role transfer process. +simplify the role transfer process. Some teams have opted to assign the +ProxyAdmin role to a secure EOA / multi-sig wallet and assign the USDC roles to +the bridge contract itself. -Some teams have opted to assign the ProxyAdmin role to a secure EOA / multi-sig -wallet and assign the USDC roles to the bridge contract itself. - -If they are assigned to a smart contract, the contract must expose a function -that Circle can call through a smart contract interaction to perform the role -transfer at upgrade time. Automating this interaction can reduce manual errors -and can enable atomic before and after checks that facilitate a smooth transfer. +If the roles are assigned to a smart contract, the contract must expose a +function that Circle can call through a smart contract interaction to perform +the role transfer at upgrade time. Automating this interaction can reduce manual +errors and can enable atomic before and after checks that facilitate a smooth +transfer. This function must have the following signature: @@ -220,10 +215,18 @@ This function must have the following signature: function transferUSDCRoles(address owner) external; ``` -The function implementation details are left up to the partner, but it must: 1) -only be callable by a Circle-owned address and 2) transfer the Implementation -Owner role and the ProxyAdmin role to the function caller (if both are assigned -to the bridge). +The function implementation details are left up to the partner, but it must: + +1. Be only callable by an address that Circle specifies closer to the time of + the upgrade. +2. Transfer the Implementation Owner role to the address specified in the + `owner` parameter. +3. Transfer the ProxyAdmin role to the function caller (if it is assigned to the + bridge). + +If the ProxyAdmin role is not assigned to the bridge contract, the partner +should transfer the role to an address that Circle specifies closer to the time +of the upgrade. Additionally, the partner is expected to remove all configured minters prior to (or concurrently with) transferring the roles to Circle.