Summary
USDC on Arc serves as the network’s native gas token and is deployed as an upgradable FiatTokenProxy contract. It can be bridged to Arc via both Circle Mint and CCTP. CCTP cross-chain messaging relies on a 2-of-2 attestation threshold controlled entirely by Circle.
The key findings include that access control across all contracts, including both assets and bridge contracts in scope, relies on EOAs managed under Circle’s enterprise-grade key management program, which they claim maintains SOC 2 Type 2 attestation and follows NIST frameworks across the infrastructure. Further, no timelocks gate sensitive contract upgrades, consistent with Circle’s operational model for USDC on other networks.
1. Asset Fundamental Characteristics
Circle’s USDC on Arc is deployed as an upgradable ERC20 FiatTokenProxy contract that uses the FiatTokenV2_2 implementation contract. USDC is natively minted on Arc, with Circle Mint enabling minting and bridging via CCTP. Redemptions through Circle Mint are accessible only to qualified persons/businesses. The token’s design is consistent with other chains where USDC is listed on Aave.
USDC is also the gas asset on Arc. The token is therefore located at the fixed predeploy address, where the ERC20 interface is served over the native balance rather than over a standalone token ledger. Its implementation is a superset of the implementation shared by EURC and cirBTC, carrying three additional functions that service the native-balance accounting. As of September 17, 2026, the total supply on Arc is 647.75M USDC.
1.1 Bridge Risk
USDC can be bridged to and from Arc via CCTP which is a burn-and-mint protocol. Rather than locking a token on a home chain and minting a wrapped representation elsewhere, it burns the native token on the source chain and mints an equal amount of the same native token on the destination chain, so every unit remains canonical, and there is no escrow contract holding bridged collateral. The contracts are open source in Circle’s evm-cctp-contracts repository.
The mechanism runs across three contract roles per chain. The TokenMessenger exposes depositForBurn, which pulls the user’s tokens and calls the TokenMinter to burn them, while the TokenController, which it inherits, enforces a per-message burn limit and holds the registry that pairs each local token with its counterpart token on each remote domain, assuming a 1:1 fungible exchange. The MessageTransmitter then emits the cross-chain message. On the destination chain, the relationship is reversed: a caller submits the message and Circle’s signed attestation to the destination MessageTransmitter, which verifies the attestation before the TokenMessenger instructs the destination TokenMinter to mint the equivalent amount of the native token to the recipient. The TokenMinter accepts only mint and burn calls from the registered local TokenMessenger, keeping issuance bounded to the protocol path.
Source:Circle Docs
The trust anchor for CCTP is Iris, Circle’s off-chain Attestation Service, rather than an independent validator or an oracle network. After a burn, Circle’s attesters observe the source-chain event and produce a signature that the destination MessageTransmitter checks against an on-chain attester set using an m-of-n threshold.
Attester Threshold
The attester set threshold is 2/2, with both keys controlled by Circle. Therefore the security consequence for CCTP is that cross-chain integrity would rest on the same single-issuer trust model as the token itself. A compromise of Circle’s attester keys could authorize a mint on a destination chain that is not backed by a real burn. We recommend increasing the number of enabled attesters to at least three participants as outlined in our Risk Framework, and introducing independent third-party attesters at the verification layer.
Rate Limits
The TokenMinterV2 contract enforces a burn limit of 10,000,000 USDC per CCTP message.
2. Market Risk
Unlike typical volatile collateral assets, USDC exhibits a distinct market risk profile driven by its role as the dominant dollar-pegged stablecoin, functioning practically as primary liquidity itself. Beyond its deep global liquidity footprint across centralized exchanges (CEXs) and secondary markets, its risk environment on Arc is unique due to its foundational integration. On Arc, USDC serves as the native gas asset to cover all transaction fees, eliminating volatile fee exposure while establishing a continuous, non-discretionary baseline demand. Furthermore, USDC acts as the primary base currency against which all major token pools are paired on Arc DEXs, making it the central engine for on-chain price discovery, trade routing, and collateral valuation.
3. Technological Risk
3.1 Smart Contract Risk
USDC inherits the smart contract risk profile of Circle’s FiatTokenV2_2 architecture. This codebase is battle-tested, having secured USDC and EURC tokens that are widely used across many chains. The source is open and maintained by Circle in the circlefin/stablecoin-evm repository.
When Circle introduced the v2.2 upgrade, the changeset underwent an independent audit by Halborn, a third-party blockchain security firm. However, we could not locate any of these audits publicly.
3.2 Bug Bounty Program
Circle has had a Bug Bounty Program live on HackerOne since May 2024, with the top bounty set at $5,000 for a critical-severity finding, which is relatively low given the TVL of USDC. The contracts in the scope can be found here.
3.3 Price Feed Risk
Aave on Arc uses a Capped USDC/USD feed with an upward cap of 1.04. The underlying price feed is Chainlink’s USDC/USD SVR feed, which is classified as Low Market Risk.
3.4 Dependency Risk
USDC concentrates several dependencies in a single issuer and a small set of external systems. The most significant is Circle itself. Circle controls minting and burning, operates the Circle Mint distribution platform through which redemptions are processed, and cross-chain support through CCTP. Circle also holds every privileged contract role, including the Proxy Admin, which can upgrade the implementation. Therefore, a failure or compromise at Circle affects reserve, redemption, and contract control.
4. Access Control Risk
Circle uses role-based access control (RBAC) structure for USDC contracts on Arc which is configured as follows, with all the controlling wallets managed under Circle’s enterprise-grade key management program, using a combination of hot and cold wallet infrastructure.
| Controlling Wallet | Role | Functionality |
|---|---|---|
| EOA 1 | owner |
Re-assign any role except for admin. |
| EOA 2 | admin |
Manage proxy-level functionalities. |
| EOA 3 | pauser |
Pause the contracts, preventing all transfers, minting, and burning. |
| EOA 4 | blacklister |
Prevent transfers to/from an address and prevent it from minting/burning. |
| EOA 5, owner of the masterMinter contract | masterMinter |
Add/remove minters and increase their minting allowance. |
| 29 minters configured, with the following having non-zero allowance: Minter1: 545,876,537.91 USDC, TokenMinterV2: 162,729,346.90 USDC, Minter2: 39,063,457.33 USDC, and Minter3: 9,486.01 USDC | minters |
Create/destroy tokens. |
| Unassigned | rescuer |
Transfer any ERC-20 token locked in the contract. |
Disclaimer
This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.
The information provided should not be construed as legal, financial, tax, or professional advice.