CCTP와 USDC 크로스체인 결제

도입

CCTP를 bridge 목록의 하나로만 보면 중요한 차이를 놓친다. Circle의 CCTP는 source chain에서 USDC를 burn하고 destination chain에서 native USDC를 mint하는 방식이다. 일반 lock-and-mint bridge처럼 wrapped token을 발행하거나 liquidity pool에서 선지급하는 모델과 다르다.

제품 관점에서 핵심은 "한 번의 전송"처럼 보이는 사용자 경험이 실제로는 burn, finality, attestation, destination mint, fee/allowance 확인, 재시도 상태로 나뉜다는 점이다. 결제 시스템은 이 중간 상태를 숨기지 말고 사용자가 이해할 수 있는 언어로 표현해야 한다.

이 강의는 CCTP의 burn/mint 모델을 상태머신으로 만들고, Fast Transfer와 Standard Transfer를 제품 정책으로 나누는 법을 다룬다. 2026-05-14 기준 Circle 문서에서는 CCTP V2가 Fast Transfer, Hooks, 개선된 API를 포함하며, CCTP V1은 2026년 7월부터 10개월에 걸쳐 phase-out될 예정이라고 안내한다. 새 설계는 V2 문서를 기준으로 둔다.

여기서는 USDC 결제 제품 안에서 CCTP 상태를 어떻게 보여줄지에 집중한다. 브릿지와의 신뢰 모델 비교는 CCTP와 브릿지 신뢰 모델, 구현 연습은 CCTP 시뮬레이터 랩에서 이어진다.

학습 목표

• CCTP의 burn/mint와 브릿지 락업 모델을 구분한다.
• 메시지 attestation 지연을 결제 UX에 반영한다.
• Fast Transfer와 Standard Transfer의 finality, fee, allowance 차이를 제품 정책으로 분리한다.

개념 설명

1. CCTP는 native USDC burn-and-mint 흐름이다

Circle 문서는 CCTP를 native USDC를 여러 블록체인 사이에서 이동시키는 permissionless onchain utility로 설명한다. 사용자는 source chain에서 USDC를 burn하고, Circle Attestation Service가 burn message를 확인해 서명한 뒤, destination chain에서 그 attestation을 제출해 USDC를 mint한다.

이 흐름에서 "USDC가 이동했다"는 말은 정확히는 source에서 burn되고 destination에서 새로 mint됐다는 뜻이다. 이 차이 때문에 destination asset은 wrapped token이 아니라 native USDC가 된다. 대신 Circle attestation, supported domain, destination contract, finality 정책을 제품 설계에 넣어야 한다.

2. CCTP와 bridge의 신뢰 경계가 다르다

이 표를 제품 문구로 바꾸면 bridge와 CCTP를 같은 문장으로 설명하면 안 된다. CCTP는 liquidity pool 부족을 걱정하는 모델이 아니라 attestation, finality, destination mint 상태를 관리하는 모델이다. 반대로 lock-and-mint bridge는 wrapped asset과 custody risk를 설명해야 한다.

3. Fast Transfer와 Standard Transfer를 정책으로 나눈다

CCTP V2에서는 속도와 finality 기준을 설계자가 선택해야 한다. Circle 문서 기준으로 Fast Transfer는 source chain burn이 hard finality에 도달하기 전에 더 빠르게 attestation을 받을 수 있지만 Fast Transfer allowance와 fee가 걸린다. Standard Transfer는 더 느리지만 hard finality 기반으로 간다.

Fast Transfer allowance가 부족하면 기다리거나 Standard Transfer로 전환해야 한다. 따라서 checkout 제품은 "cross-chain 전송 중" 하나가 아니라 AllowanceInsufficient, AttestationPending, MintSubmitted 같은 상태를 가져야 한다.

4. 제품 상태는 source와 destination을 모두 저장한다

상태마다 저장할 데이터도 다르다. Source tx hash, source domain ID, destination domain ID, burn message hash, attestation response, destination tx hash, fee, allowance snapshot, finality threshold를 분리해서 저장해야 한다.

5. 개발 체크리스트

• source/destination domain ID를 정확히 매핑한다.
• source와 destination의 token messenger/message transmitter 주소를 확인한다.
• 같은 burn message가 double mint되지 않도록 message hash를 저장한다.
• attestation API 장애를 제품 상태로 표현한다.
• fast transfer를 쓰는 경우 fee, finality, liquidity tradeoff를 문서화한다.
• CCTP와 일반 bridge를 혼동하지 않도록 UI copy를 분리한다.
• CCTP V1 legacy와 V2 contract/API 차이를 설계 메모에 남긴다.
• 지원 체인과 domain 목록은 Circle 공식 문서 기준으로 확인하고 마지막 확인일을 저장한다.
• hooks를 사용할 때 destination execution 실패와 USDC mint 성공을 분리한다.

코드로 확인하기

위 설계 결정을 코드에서 확인한다. 상태, 서명, 원장 이동, 실패 처리가 어디에 놓이는지 따라 읽으면 앞의 모델이 실제 구현 경계로 내려온다.

컨트랙트CCTP TokenMessenger 인터페이스 — depositForBurn 호출

사용자(또는 결제 서버)가 source chain의 TokenMessenger.depositForBurn을 호출해 USDC를 소각하고, destination domain·recipient를 메시지에 박는다. message hash는 attestation의 키가 된다.

01interface ITokenMessenger {02    function depositForBurn(03        uint256 amount,04        uint32 destinationDomain,05        bytes32 mintRecipient,06        address burnToken07    ) external returns (uint64 nonce);0809    function depositForBurnWithCaller(10        uint256 amount,11        uint32 destinationDomain,12        bytes32 mintRecipient,13        address burnToken,14        bytes32 destinationCaller15    ) external returns (uint64 nonce);16}1718interface IMessageTransmitter {19    function receiveMessage(bytes calldata message, bytes calldata attestation) external returns (bool);20}2122contract CrossChainCheckout {23    ITokenMessenger public tokenMessenger;2425    function payToRemoteMerchant(26        uint256 amount,27        uint32 destinationDomain,28        bytes32 mintRecipient,  // 32바이트로 패딩된 destination merchant 주소29        address usdc30    ) external returns (uint64 nonce) {31        IERC20(usdc).transferFrom(msg.sender, address(this), amount);32        IERC20(usdc).approve(address(tokenMessenger), amount);33        nonce = tokenMessenger.depositForBurn(amount, destinationDomain, mintRecipient, usdc);34        // nonce 는 attestation 폴링과 destination mint 키로 저장한다35    }36}

백엔드Circle Attestation API 폴링 — exponential backoff

burn 직후 사용자 화면은 "처리 중"으로 두고 백엔드가 Circle API에서 attestation 을 받아온다. timeout은 길게(분 단위), backoff는 점진적으로.

01const ATTESTATION_URL = "https://iris-api.circle.com/v1/attestations";0203export async function pollAttestation(messageHash: `0x${string}`, opts: {04  maxAttempts?: number;05  initialDelayMs?: number;06} = {}): Promise<`0x${string}` | "timeout"> {07  const max = opts.maxAttempts ?? 60;08  let delay = opts.initialDelayMs ?? 2000;0910  for (let i = 0; i < max; i++) {11    const res = await fetch(`${ATTESTATION_URL}/${messageHash}`);12    if (res.ok) {13      const data = await res.json() as { status: "pending_confirmations" | "complete"; attestation: `0x${string}` };14      if (data.status === "complete") return data.attestation;15    }16    await new Promise((r) => setTimeout(r, delay));17    delay = Math.min(delay * 1.5, 30_000); // 최대 30초 간격18  }19  return "timeout";20}

백엔드Destination chain에서 receiveMessage 실행

attestation을 받은 후 destination chain의 MessageTransmitter에 message + attestation 을 제출. 결과는 USDC mint event로 확인한다.

01import { writeContract, waitForTransactionReceipt } from "@wagmi/core";0203export async function finalizeOnDestination(args: {04  destinationChainId: number;05  message: `0x${string}`;06  attestation: `0x${string}`;07}) {08  const txHash = await writeContract(config, {09    chainId: args.destinationChainId,10    address: MESSAGE_TRANSMITTER_ADDRESSES[args.destinationChainId],11    abi: messageTransmitterAbi,12    functionName: "receiveMessage",13    args: [args.message, args.attestation]14  });1516  const receipt = await waitForTransactionReceipt(config, { hash: txHash, chainId: args.destinationChainId });1718  // MintAndWithdraw event 가 있는지 확인 — 없으면 hooks 실패 가능성19  const mintLog = receipt.logs.find((log) => log.topics[0] === MINT_AND_WITHDRAW_TOPIC);20  if (!mintLog) {21    throw new Error("destination mint event not found — check hooks execution");22  }23  return { txHash, mintLog };24}

인덱서Cross-chain transfer 상태 추적 테이블

source burn / attestation / destination mint 가 다른 트랜잭션에서 일어나므로 하나의 행으로 통합 추적한다.

01// model CrossChainTransfer {02//   id                  String   @id @default(cuid())03//   userId              String04//   amount              BigInt05//   sourceChainId       Int06//   destinationChainId  Int07//   nonce               BigInt   // depositForBurn 반환값08//   messageHash         String   @unique09//   sourceTxHash        String10//   sourceBurnedAt      DateTime11//   attestation         String?  // Circle attestation hex12//   attestedAt          DateTime?13//   destinationTxHash   String?14//   destinationMintedAt DateTime?15//   status              String   // "burned" | "attested" | "minted" | "failed" | "timeout"16//17//   @@index([status, sourceBurnedAt])18// }

강의 포인트

실무 예시

백엔드[CLIENT] [OPS] 사용자가 Base에서 USDC를 결제했지만 merchant settlement는 Ethereum에서 받아야 한다고 가정한다. 제품은 Base에서 burn을 시작하고, attestation을 받은 뒤 Ethereum에서 mint한다. 사용자는 "전송 중"만 보면 답답하지만, 아래처럼 상태를 나누면 support가 가능하다.

이 예시는 checkout 상태머신과 연결된다. CCTP의 Minted가 되어야 merchant settlement로 넘어갈 수 있고, AttestationPending 상태에서는 사용자가 재결제를 누르지 않도록 해야 한다.

흔한 오해와 실패 시나리오

실습 과제

1. 백엔드[INDEXER] CCTP 상태와 증거 정리하기: source burn, finality, attestation, destination mint, fee, allowance 상태마다 저장할 tx hash, message hash, domain ID, API response를 정리한다.
2. 백엔드Fast/Standard Transfer 정책 작성하기: Fast Transfer와 Standard Transfer 중 어떤 상황에서 어느 방식을 쓸지 SLA, fee, allowance, finality, support message 기준으로 정책표를 만든다.
3. 운영CCTP V2 전환 메모 작성하기: 새 설계를 CCTP V2 기준으로 둔다는 전제, V1 legacy phase-out 확인일, 지원 체인/domain 재확인 절차를 설계 메모로 작성한다.

완료 기준

1. burn/mint 모델을 설명한다.
2. attestation 대기 UX를 설계했다.
3. 체인별 리스크 메모를 작성했다.
4. CCTP V1 legacy phase-out과 V2 기준 설계 메모를 남겼다.

근거 자료

• CCTP USDC 크로스체인: 01-스테이블코인/05-CCTP-USDC-크로스체인.md
• Circle CCTP Documentation: https://developers.circle.com/cctp
• Circle: Migrate from CCTP V1 to V2: https://developers.circle.com/cctp/migration-from-v1-to-v2
• Circle: Fast Transfer Allowance: https://developers.circle.com/cctp/concepts/fast-transfer-allowance
• Circle: CCTP Fees: https://developers.circle.com/cctp/concepts/fees