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.