Summary
WETH on Arc is deployed as a CrossChainToken implementation different from other Circle-issued assets, as it is not natively minted on Arc and is instead a bridged representation backed by WETH escrowed on Ethereum. Its owner and pauser slots remain unclaimed, so no party can modify its privileged roles, and the token cannot be paused through its own pause function. However, the Cross Chain Token Service (CCTS) retains ownership assignment authority and can resolve the unclaimed state at any time.
Additionally, the WETH token and its TokenManager contracts, do not pin their own implementation and instead resolves it through the CCTS singleton at call time. This means the CCTS owner ultimately controls the code executed by the TokenManager and WETH. WETH also has no native blacklist and instead inherits the blacklist functionality of Arc USDC.
Other findings include that access control across all contracts, including both the asset 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 and EURC on other networks.
1. Asset Fundamental Characteristics
WETH is wrapped ETH from the Ethereum Mainnet made available on Arc through Circle’s CCTPx protocol. It is deployed as an upgradeable CrossChainToken contract which is a purpose-built ERC20 built on OpenZeppelin upgradeable primitives rather than a FiatTokenV2_2 deployment, so it does not inherit the role structure of the Circle-issued stablecoins. Unlike USDC, EURC, and cirBTC, which are natively minted on Arc, WETH is a bridged representation rather than a native asset.
The underlying WETH stays on Ethereum, locked in the TokenManager contract, currently holding 85.1759 WETH, and an equivalent amount of WETH is minted on Arc, so each WETH on Arc is backed by WETH escrowed on Ethereum. WETH is therefore not a Circle-issued reserve asset but a lock-and-mint bridged claim on Ethereum WETH, and its risk profile is driven primarily by the CCTPx bridge rather than by an issuer reserve.
1.1 Bridge Risk
Circle’s new bridging protocol, CCTPx, is a permissionless extension that allows third-party assets to be bridged over CCTP. CCTP itself is a burn-and-mint protocol scoped to Circle’s own native tokens, such as USDC, while CCTPx layers a lock-and-mint model on top of CCTP’s cross-chain messaging so that an asset Circle does not issue, in this case wETH, can be represented on a destination chain. For wETH, Circle creates a lock-and-mint connection between Ethereum and Arc. The underlying wETH on Ethereum is custodied in a lock/unlock Token Manager contract deployed by the CCTPx protocol, and on Arc, the protocol deploys both a new ERC20 contract and an accompanying mint/burn Token Manager, with the Arc supply managed through mint and burn commands to keep parity with the amount escrowed in the Ethereum Token Manager.
The protocol has three critical components:
- The Cross Chain Token Service (CCTS) is a singleton contract deployed on each chain that coordinates the bridge creation process and cross-chain transfers, and it integrates into the pre-existing CCTP smart contracts for cross-chain messaging.
- The Token Manager is the contract that defines and controls the bridging mechanism for a single token bridge connection, either lock/unlock or mint/burn, on the chain where it is deployed.
- The Cross Chain Token is the ERC20 contract deployed as part of bridge creation when a token is issued to a new chain, and Circle states it is based on a modified version of Circle’s audited FiatTokenV1 contract, with modifications to support cross-chain transfer functionality.
Transfers use a lock-and-mint model in both directions. From Ethereum to Arc, wETH is approved and locked in the Ethereum Token Manager as bridge collateral, while the Ethereum CCTS sends a cross-chain message that instructs the Arc Token Manager to mint an equivalent amount of WETH for the recipient. From Arc to Ethereum, WETH is approved and burned by the Arc Token Manager, and the Arc CCTS sends a message instructing the Ethereum Token Manager to unlock and release the corresponding escrowed wETH to the recipient.
Attester Threshold
Because CCTS routes its messages through the existing CCTP contracts, the authenticity of a cross-chain transfer message inherits CCTP’s attestation model, which on Ethereum is the 2-of-2 Circle-operated attester set.
Rate Limits
Cross-chain transfers are bounded by a rate limit that controls the net flow of wETH to and from each deployed chain (Arc <> Ethereum) over a rolling 6-hour window. The TokenManager on Arc and the TokenManager on Ethereum are configured symmetrically, at 2,500 WETH per six-hour window in each direction, alongside a per-transfer ceiling of 500 WETH.
2. Market Risk
2.1 Liquidity
Users can swap 100 WETH for $233K USDC within a price impact of 5.5%.
Source: WETH/USDC Swap Liquidity on Arc, KyberSwap, September 17, 2026
2.1.1 Liquidity Venue Concentration
On-chain liquidity for WETH on Arc is available on multiple venues the most liquidity being Aerodrome WETH/USDC ($479K in TVL), Aerodrome WETH/cirBTC ($465K in TVL), and Uniswap V4 WETH/USDC pools ($47K in TVL).
Source: WETH DEX liquidity pools on Arc, GeckoTerminal, September 17, 2026
2.1.2 DEX LP Concentration
WETH LP concentration on Arc is moderately low with the LP breakdown for the top two pools is as follows:
- Aerodrome WETH/USDC: 42.38% of the pool’s liquidity is supplied by an EOA 1.
- Aerodrome WETH/cirBTC: The top supplier is another EOA 2 with a 23.08% share of the pool’s liquidity.
2.2 Volatility
As the Arc chain went live only two days ago, limited volatility data is available for WETH’s secondary market price. Therefore, no meaningful conclusions regarding its price stability can yet be drawn.
2.3 Exchanges
WETH issued by Circle only trades on Arc DEXs currently and is not listed on any centralized exchange.
3. Technological Risk
3.1 Smart Contract Risk
The bridge contracts were audited by third-party auditors. However, the reports were not publicly available at the time of review, preventing independent verification of the findings.
The following contracts power CCTPx bridge on the Arc chain:
- CrossChainTokenService: Upgradeable, ERC-1967 proxy. Singleton that creates bridges, routes cross-chain messages, and acts as both the upgrade authority and the ownership assigner for every CCTPx contract on Arc. Controlled by an EOA A.
- CCTP MessageTransmitterV2: Upgradeable, ERC-1967 proxy. The underlying CCTP contract that verifies attester signatures on inbound messages and emits outbound ones. Controlled by an EOA B.
- FeeService: Upgradeable, ERC-1967 proxy. Quotes and collects the cross-chain transfer fee. Controlled by an EOA C.
- DeploymentDelegate: Immutable. Deploys new bridges and tokens on behalf of the service. No owner role.
- TransferDelegate: Immutable. Executes the mint, burn, lock, and unlock legs of a transfer. No owner role.
- FiatTokenDenylistAdapter: Immutable. Service-wide denylist source. A view-only adapter that forwards
isDenylisted to the Arc USDC contract’s isBlacklisted. No owner role, so the effective control sits with the USDC blacklister.
The WETH token and its TokenManager contracts are beacon proxies that resolve their implementation through the Cross Chain Token Service singleton at call time as the local override is unset. Whoever controls the CCTS on a given chain can therefore change the code of every CCTPx TokenManager and CCTPx-issued token on that chain in a single action.
3.2 Access Control
The Arc-side WETH contract is the CCTPx CrossChainToken rather than a FiatTokenProxy deployment, and it exposes a narrower role set than the three Circle-issued assets above: it has an owner, a pauser, a minter set, and a denylistProvider as shown below:
| Controlling Wallet |
Role |
Functionality |
| Unclaimed, assignable by the Cross Chain Token Service |
owner |
Add/remove minters, set the pauser and the denylistProvider, upgrade to a custom implementation. |
| Unclaimed |
pauser |
Pause the contract, preventing all transfers, minting, and burning. |
| One minter is configured: the TokenManager |
minters |
Create/destroy tokens. Unlike the FiatToken assets, the contract holds no per-minter allowance, so the minter is bounded by the TokenManager’s own bridge limits rather than by a token-level ceiling. |
| FiatTokenDenylistAdapter, delegating to the USDC blacklist, controlled by EOA 4 of the USDC table |
denylistProvider |
Block transfers to/from an address. |
Minting is not allowance-capped at the token level, and both the owner and pauser slots are currently unclaimed as they return to an ASSIGNABLE_OWNER sentinel. CCTPx uses it to mark a contract whose ownership has not yet been claimed. The practical consequence is that no party can currently call the token’s owner-gated or pauser-gated functions. The Cross Chain Token Service remains able to change the shared implementation the token proxies to, as described under Smart Contract Risk above. The CCTS is also registered as the token’s ownershipAssigner and can assign an owner at any time through assignOwnership, after which the nominee claims the role via acceptAssignedOwnership.
The TokenManager and CCTS contracts use a three-role structure of owner, pauser, and operator. The owner can upgrade the contract and manage the other two roles, the operator sets the rate limit, the maximum transfer amount, and the rate limit window, and the pauser halts and resumes the contract. They have the following role assignments:
No multisig or timelock sits on any of these contracts, including the CCTS, which is the upgrade authority for all of them and the assigner of ownership for those that are unclaimed. Across the CCTPx deployment on both chains, all privileged assigned addresses are different. No wallet holds two roles, no wallet appears on both the Arc and the Ethereum side, and none of these matches any of the controlling wallets, masterMinter owners, or funded minters on the USDC, EURC, or cirBTC contracts.
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.
MEDIUM 
GOOD 
N/A 
