Circle FX Corridor (USDC→EURC)
Cross-border FX settlement via USDC→EURC swap on Arc, bridged to Ethereum via CCTP.
CTR (USD 10,000+)TRAVEL-RULE (USD 3,000+)ENHANCED-DUE-DILIGENCE (USD 50,000+)
Step 1 · Smart Wallet (Arc)Policy-Enforced
The corporate treasury workstation at a correspondent bank — the operator sees balances, selects a beneficiary, and queues a wire instruction before any value moves.
Self-custody smart account on Circle's Arc network, a permissioned EVM chain where every address maps to a known entity. L4 Account and L5 Application are lit — both above the enforcement line, policy-enforced. The Path begins in permissioned territory, which matters: Arc's validator set is Circle-operated, so the regime tag is 'permissioned' and the compliance surface is narrower than a public-chain origin. The wallet holds USDC (the source asset); the FX conversion to EURC happens downstream. Builder: the wallet is a Coinbase Smart Wallet with session keys scoped to the transfer amount and destination chain. The Arc RPC endpoint is permissioned — your agent needs a Circle developer API key to submit transactions. Compliance officer: entity resolution is straightforward on Arc because the address → entity mapping is maintained by Circle. GENIUS §6 AML/BSA obligations attach at path entry: the originator is identified before any value instruction fires. For EU-bound corridors, MiCA Article 68 (originator information) requirements are also satisfied at this step.
Step 2 · Sanctions OracleCode-Enforced
The sanctions-screening leg in a SWIFT gpi or Fedwire payment — no money moves, but the payment halts until the list check returns clear.
A pure compliance stop. The Chainalysis OFAC sanctions oracle (contract at 0x40C57cBd68CF45e08ec05528dF71e5261e6dc4d0 on Arc) fires at L3 Execution and the Path halts until it returns pass/fail. The lit layer sits exactly on the enforcement line — the gate lives at the boundary between policy and code. On a permissioned chain like Arc, the oracle has access to richer metadata than on public chains: the address → entity mapping lets it screen against the full OFAC SDN, SSI, and non-SDN lists with entity-level granularity, not just address-level. Builder: the oracle call is atomic with the next transaction — your agent does not need to call it separately. The Arc channel factory batches the screening check with the swap instruction in a single multicall. Compliance officer: GENIUS §6(a)(1) requires 'screening against lists maintained by OFAC' before value transfer. This checkpoint satisfies that requirement. For EU-bound corridors, the oracle also screens against the EU consolidated sanctions list (Council Regulation 269/2014). Honesty marker: the oracle screens the originator address only at this step — the beneficiary (merchant vault on Ethereum) is screened at settlement, not here. If the beneficiary is added to a sanctions list between screening and settlement (~10-15 minutes), the transfer would complete.
Step 3 · USDC → EURC SwapCode-Enforced
An FX line inside a correspondent-banking leg — asset semantics change at an execution venue before the payment continues. Like a treasury desk converting USD to EUR in the nostro account before wiring to the beneficiary's vostro.
USDC swaps to EURC on Circle's Arc DEX — a permissioned AMM pool (Uniswap V3 / Curve StableSwap class) with Circle-whitelisted liquidity providers. The swap lights L4 Account (balance updates) and L3 Execution (swap logic) simultaneously — the bracket straddles the enforcement line, showing the step lives half in policy and half in code. The FX rate is determined by pool state at execution time; there is no off-chain RFQ or order book. Builder: call swapExactInput on the Arc DEX router with USDC as tokenIn and EURC as tokenOut. Slippage tolerance is critical for large wholesale amounts — set it tight (5-10 bps) since Arc pool depth is limited compared to Ethereum mainnet Curve pools. Compliance officer: best-execution obligations attach here. MiFID II Article 27 (best execution) does not formally apply to stablecoin FX, but institutional clients expect it. The absence of competing venues on Arc means best-execution is definitionally satisfied (single venue) — but this also means no price discovery competition, which a compliance program should disclose. GENIUS §3 (payment stablecoin definition) treats both USDC and EURC as payment stablecoins; the swap does not change the regulatory character of the asset. Honesty marker: the Arc DEX pool depth is not publicly auditable in the way Ethereum mainnet Curve pools are. Large wholesale swaps (>$1M equivalent) may experience meaningful slippage.
Step 4 · CCTP Burn (Arc)Code-Enforced
The debit leg of a nostro/vostro correspondent hop — value leaves the source ledger and a burn receipt is produced for the destination to honor. The nostro balance decreases; the vostro is not yet credited.
Native EURC is burned on Arc via Circle's Cross-Chain Transfer Protocol (CCTP V2). The bracket spans the bottom three layers — L3 Execution, L2 Consensus, L1 Network — every one at or below the enforcement line. The destination chain has not yet seen the value; the EURC exists in a liminal state between burn and mint, backed only by Circle's attestation service. Builder: call depositForBurn(amount, destinationDomain, mintRecipient, burnToken) on the CCTP TokenMessenger contract on Arc. The destinationDomain for Ethereum mainnet is 0. Store the returned nonce — you need it to claim the mint on Ethereum. Compliance officer: the regime crossing happens here. Value originates on a permissioned chain (Arc, regime: 'permissioned') and will land on a public chain (Ethereum, regime: 'blockchain-native'). This is the compliance-critical boundary: the originator was fully identified on Arc, but the destination address on Ethereum may not have the same entity-resolution certainty. GENIUS §8 (extraterritorial provisions) is relevant if the corridor crosses a US/non-US boundary — the EURC denomination suggests a EUR-denominated beneficiary, potentially in an EU jurisdiction. Circle's attestation service is the single point of trust in this bridge: if the attestation service is unavailable, the mint cannot complete and the EURC is frozen mid-transit.
Step 5 · CCTP Mint (Ethereum)Code-EnforcedBlockchain-Native
The credit leg of the correspondent hop — value is reconstituted on the destination ledger against the burn attestation. The vostro balance increases; the correspondent relationship is squared.
Against Circle's off-chain attestation, native EURC is minted on Ethereum mainnet. The attestation is a signed message from Circle's attestation service confirming the burn on Arc — it is the cryptographic proof that value was destroyed on the source chain. Same three-layer silhouette as Step 4 (L1, L2, L3 lit) but on a different rail with a different regime: blockchain-native Ethereum, where the validator set is permissionless and the compliance surface is wider. Builder: call receiveMessage(message, attestation) on the CCTP MessageTransmitter contract on Ethereum. The attestation is fetched from Circle's attestation API (iris-api.circle.com) using the nonce from Step 4. Latency is dominated by Arc finality (~1 min) plus attestation service processing (~2-5 min) plus Ethereum block confirmation (~12s). Compliance officer: the minted EURC on Ethereum is now subject to Ethereum's regulatory environment. If the merchant vault (Step 6) is operated by an EU-licensed entity, MiCA Title III (asset-referenced tokens) and Title IV (e-money tokens) apply to the EURC. GENIUS §4 reserve-backing requirements apply: Circle must maintain 1:1 reserves in EUR or EUR-denominated short-term government securities for every EURC token, including those in transit via CCTP. The attestation creates an auditable link between the Arc burn and the Ethereum mint — examiners can trace the full corridor from source to destination.
Step 6 · Merchant Vault (Ethereum)Policy-EnforcedBlockchain-Native
The beneficiary's credit-to-account event — funds rest in the merchant's custody and the payment lifecycle is complete. Like the final credit advice on a correspondent wire.
EURC rests at a merchant vault on Ethereum — an institutional custody solution (Fireblocks, Anchorage, or Copper class) with multi-sig governance and insurance coverage. Same silhouette as Step 1 — L4 Account and L5 Application lit, above the enforcement line — but on a different chain and in a different regime (blockchain-native vs. permissioned). The Path ends in policy-enforced territory on the destination rail. Builder: the mint recipient address from Step 4 should be the merchant's vault contract, not an EOA. Institutional vaults typically use a proxy pattern with role-based access control — confirm the vault can receive ERC-20 tokens directly. Compliance officer: recordkeeping obligations crystallize here. GENIUS §4(c) (books and records) requires the issuer (Circle) to maintain records of this transfer. The merchant's institution applies its own jurisdiction's reporting obligations: in the EU, MiCA Article 76 (record-keeping by CASPs) applies; in the US, BSA §5313 (CTR filing for transactions >$10,000) applies if the merchant is a US MSB. Travel Rule data transmitted in the originator jurisdiction must be retained by the receiving institution for 5 years (BSA) or 5 years (MiCA Article 69). Honesty marker: the end-to-end corridor (Arc USDC → Arc EURC → Ethereum EURC) involves two asset conversions and a chain hop. Total latency is ~10-20 minutes — faster than SWIFT gpi (hours to days) but slower than same-chain transfers (~2s). The compliance advantage is the fully auditable trail from originator wallet to beneficiary vault, with every intermediate step recorded on-chain or in Circle's attestation log.
Resolved 6 steps across 2 chain(s). 3 threshold(s) triggered. Frameworks: Bank Secrecy Act, GENIUS Act, OFAC Sanctions Program, FATF Recommendation 16 (Travel Rule), Common Reporting Standard / FATCA.
CCTP ↔ x402 Bridge Map
Structural map of Circle CCTP V2 cross-chain settlement — burn on Arc, attestation relay, mint on Ethereum — with regime crossing from permissioned to blockchain-native.
Sanctions Oracle (Arc)
The pre-swap OFAC screening gate on Arc — entity-level sanctions screening with address→entity metadata available on the permissioned chain.