CCTP V1 종료 전 V2 전환, USDC 전송 서비스가 확인할 항목

CCTP V1을 쓰는 USDC 전송 서비스는 2026년 10월 31일 전에 V2 계약과 API로 전환해야 합니다. 10월 31일부터 V1의 신규 소각 한도가 줄고, 12월 1일에는 V1 계약이 중지될 예정입니다. 지갑 화면에 ‘USDC 전송’이 계속 보여도 내부 경로가 V1이면 어느 순간 새 전송이 멈출 수 있으므로, 사용자는 전송 전 지원 네트워크와 서비스 공지를 확인하고 개발자는 계약 주소·함수·API·수수료 처리를 함께 점검해야 해요.

핵심 요약
CCTP V1 종료는 USDC 잔액이 사라진다는 뜻이 아닙니다. 다만 V1을 통해 새로 시작하는 체인 간 전송은 단계적으로 제한됩니다. 서비스 운영자는 V2의 새 계약과 /v2/ API를 적용하고, 일반 이용자는 소액 전송·도착 체인·네이티브 USDC 여부를 확인한 뒤 큰 금액을 보내는 편이 안전합니다.

CCTP V1에서 V2로 옮길 때는 화면 이름보다 실제 계약 주소와 API 경로를 함께 바꿔야 합니다.

CCTP V1 종료 일정에서 먼저 기억할 두 날짜

Circle이 2026년 8월 27일 공개한 일정은 두 단계입니다. 10월 31일부터 CCTP V1의 burn limit, 즉 원본 체인에서 새 USDC 전송을 시작할 수 있는 한도가 줄어듭니다. 한 달 동안 성능과 처리 가능량을 낮춰 사용량을 0으로 유도한 뒤 12월 1일 V1 계약을 중지합니다. 이때까지 V1을 호출하는 앱은 체인 간 USDC 전송을 더 시작하지 못할 수 있어요.

이는 가격 전망이나 시장 이벤트가 아니라 서비스 작동 조건의 변경입니다. 전송 버튼이 있는지, USDC 잔액이 보이는지만 확인해서는 부족합니다. 앱이 호출하는 TokenMessenger 계약이 V1인지 V2인지, attestation을 받는 서버가 /v1/ 경로인지 /v2/ 경로인지까지 확인해야 합니다. Circle은 V2 전환을 권고가 아닌 필수로 표현했습니다. 다만 이 발표는 서비스 제공사인 Circle의 운영 공지이므로 실제 사용 중인 지갑·거래소·브리지의 별도 전환 일정도 함께 봐야 해요.

USDC 잔액과 진행 중 전송은 어떻게 되는가

V1 종료가 곧 지갑 속 USDC 소멸을 뜻하지는 않습니다. CCTP는 원본 체인의 네이티브 USDC를 소각하고 목적지 체인에서 같은 양을 발행하는 전송 기반 시설입니다. 지갑의 개인키나 거래소 계정 자체를 보관하는 서비스가 아니며, V1 계약을 멈춘다고 이미 보유한 네이티브 USDC의 소유권이 바뀌는 구조도 아닙니다.

Circle의 마이그레이션 문서는 단계적 종료 중에도 이미 발급된 attestation에 해당하는 환급·발행 처리가 가능하도록, 대기 중인 금액보다 큰 minter allowance를 유지하겠다고 설명합니다. 신규 burn 한도가 줄어드는 것과 이미 시작된 전송의 목적지 발행 가능성은 구분해야 해요. 전송 상태가 오래 pending이라면 같은 요청을 다시 보내지 말고 원본 체인 거래 해시, source domain, Circle attestation 상태, 목적지 체인의 mint 거래를 순서대로 조회하는 편이 안전합니다.

V2는 이름만 바뀐 업그레이드가 아니다

CCTP V2는 현재 문서에서 다시 ‘CCTP’라고 불리지만, 기존 V1과 하위 호환되지 않습니다. 새 계약은 TokenMessengerV2, MessageTransmitterV2, TokenMinterV2처럼 별도 이름과 주소를 사용합니다. V1 주소를 그대로 둔 채 SDK 버전만 올리면 전환이 끝났다고 볼 수 없어요.

계약 함수의 입력값이 달라집니다

V2의 depositForBurn()에는 목적지에서 메시지를 받을 수 있는 호출자를 지정하는 destinationCaller, 허용할 최대 수수료인 maxFee, 전송 속도와 최종성 수준을 가르는 minFinalityThreshold가 추가됩니다. 빠른 전송은 1000, 표준 전송은 2000이라는 finality threshold를 사용합니다. V1의 depositForBurnWithCaller()와 replaceDepositForBurn()는 같은 형태로 남아 있지 않으므로, 해당 기능에 의존한 예외 처리도 다시 설계해야 합니다.

attestation 조회 흐름도 바뀝니다

V1에서는 거래 영수증에서 MessageSent 이벤트를 찾아 메시지 바이트를 추출하고 해시를 만든 뒤 /v1/attestations/{messageHash}를 조회했습니다. V2는 /v2/messages/{sourceDomainId}?transactionHash={hash} 요청으로 메시지, attestation, 해석된 필드를 함께 받을 수 있습니다. 서버가 V1 응답 구조를 전제로 파싱하거나 상태값을 기다리고 있다면 주소만 교체해도 오류가 날 수 있어요.

Fast와 Standard 전송은 비용과 확정 기준이 다르다

V2의 Fast Transfer는 블록체인이 완전히 최종 확정되기 전 Circle의 fast allowance를 이용해 더 빨리 attestation을 받는 방식입니다. 속도가 필요한 대신 원본 체인과 경로에 따라 수수료가 붙습니다. Standard Transfer는 최종화된 상태를 기다리며 Circle 문서상 기본 프로토콜 수수료는 0이지만, 일부 새 TokenMessengerV2 배포에는 표준 전송 최소 수수료 스위치가 존재할 수 있습니다.

따라서 화면에 ‘빠른 전송’과 ‘일반 전송’이 보이면 도착 예상 시간만 비교해서는 안 됩니다. 실제 받을 USDC, 원본 체인의 가스비, Fast 수수료, 목적지에서 이어지는 후속 거래비를 함께 봐야 해요. Circle은 Fast 수수료가 바뀔 수 있으므로 값을 코드에 고정하지 말고 GET /v2/burn/USDC/fees 계열 API에서 정기적으로 가져오라고 안내합니다. maxFee가 현재 수수료보다 낮으면 원본 체인 거래가 되돌아가거나 Standard로 처리될 수 있으므로 사용자 화면의 실패 문구도 구분할 필요가 있습니다.

개발자가 종료 전에 확인할 전환 순서

1. 실제 V1 의존성을 목록으로 만드세요

프런트엔드 저장소만 검색하지 말고 백엔드 relayer, 서버리스 함수, 환경 변수, 배포 스크립트, 모니터링 규칙, 체인별 계약 주소 표까지 확인합니다. TokenMessenger, MessageTransmitter, /v1/attestations, replaceDepositForBurn를 검색하면 남은 V1 경로를 찾는 데 도움이 됩니다. 서드파티 SDK를 쓴다면 패키지 이름보다 최종적으로 호출되는 계약 주소와 API URL을 기록하세요.

2. 체인별 지원 기능을 같은 것으로 가정하지 마세요

2026년 9월 1일 Circle 지원표에는 Standard, Fast, upfront fee, Forwarding Service 지원 여부가 체인마다 다르게 표시됩니다. 모든 목적지 체인은 같아 보여도 원본 체인에서 Fast를 쓸 수 있는지는 다릅니다. Stellar는 주소 인코딩과 USDC 정밀도가 달라 inbound 전송에 CctpForwarder 사용을 안내하고, Noble과 Sui는 당시 지원표에서 V1 전용으로 따로 분류돼 있습니다. 배포 전에는 사용하려는 출발·도착 조합을 공식 지원표에서 다시 확인해야 합니다.

3. 테스트넷에서 성공과 실패를 모두 재현하세요

정상 전송 한 번만 통과시키면 부족합니다. 잘못된 domain ID, 부족한 maxFee, Fast allowance 부족, attestation 지연, 목적지 호출 실패, 중복 재시도 상황을 각각 확인하세요. 원본 체인에서 burn이 발생한 뒤에는 사용자가 같은 금액을 다시 보내지 않도록 거래 해시를 저장하고, 목적지 mint 완료 전까지 하나의 전송 상태로 추적해야 합니다.

4. 운영 전환은 관찰 가능하게 진행하세요

V2 트래픽을 단계적으로 늘리면서 source domain별 burn 성공률, attestation 지연, 목적지 mint 성공률, 실제 수수료와 견적 차이를 봅니다. 실패 시 V1로 무조건 되돌리는 기능은 10월 31일 이후 신뢰할 수 있는 복구책이 아닙니다. 신규 전송을 잠시 막고 이미 시작된 건을 끝까지 추적하는 운영 스위치를 마련하는 편이 낫습니다.

일반 이용자는 전송 버튼을 누르기 전에 무엇을 볼까

직접 코드를 운영하지 않더라도 CCTP를 사용하는 지갑이나 브리지는 영향을 받을 수 있습니다. 먼저 서비스 공지에서 CCTP V2 전환 완료 여부와 지원 체인을 확인하세요. 화면에 CCTP 버전이 없으면 고객지원 문서에서 10월 31일 이후 전송 정책을 찾고, 설명이 없으면 큰 금액 전송을 미루는 선택도 가능합니다.

둘째, 보내는 자산이 네이티브 USDC인지 브리지로 발행된 USDC.e 같은 다른 토큰인지 확인합니다. 이름과 심벌이 비슷해도 계약 주소가 다르면 CCTP가 처리하는 자산이 아닐 수 있습니다. 셋째, 목적지 주소와 네트워크를 다시 보고 소액으로 먼저 보내세요. CCTP는 비수탁형 기반 시설이고 잘못된 주소로 보낸 자산을 Circle이 되돌려 주지 않는다고 명시합니다.

마지막으로 전송 중 화면이 멈추면 재클릭보다 거래 해시 보관이 우선입니다. 원본 탐색기에서 burn 성공 여부를 확인하고 서비스의 CCTP 상태 페이지나 지원센터에 거래 해시를 전달하세요. 개인키·복구 문구는 어떤 지원 요청에도 입력하지 않습니다. 거래 해시는 공개 정보지만 복구 문구는 자산 전체를 통제하는 비밀이에요.

종료 날짜가 다가올수록 피해야 할 오해

첫째, 12월 1일이 되면 모든 USDC가 동결된다는 해석은 맞지 않습니다. 제한 대상은 V1 계약을 통한 새 체인 간 전송 경로입니다. 둘째, V2가 더 빠르다는 이유로 모든 전송에 Fast를 고정할 필요도 없습니다. 금액과 긴급성, 수수료, 출발 체인의 Fast 지원 여부를 보고 Standard와 나눠야 해요.

셋째, 스마트계약 감사가 전송의 모든 위험을 없애지는 않습니다. Circle 문서도 잘못된 주소, 제3자 자산, 앱의 hook 실행, relayer와 브리지 취약성은 별도 위험으로 둡니다. 특히 hook은 목적지에서 실행할 데이터를 전달하지만 실제 실행과 실패 복구는 통합 서비스가 책임집니다. ‘CCTP V2 사용’이라는 문구만으로 후속 DeFi 예치나 교환까지 Circle이 보증한다고 이해하면 안 됩니다.

자주 묻는 질문

CCTP V1 종료 전에 USDC를 다른 체인으로 모두 옮겨야 하나요?

그럴 필요는 없습니다. 보유 USDC 자체보다 이용 중인 앱의 체인 간 전송 경로가 V2로 바뀌었는지를 확인하는 일이 핵심입니다. 특정 서비스가 전환 계획을 공개하지 않았다면 10월 31일 전에 다른 검증된 경로를 준비하세요.

V1에서 시작한 전송이 12월 1일을 넘기면 사라지나요?

Circle은 대기 중 attestation을 처리할 수 있도록 충분한 발행 한도를 유지하겠다고 밝혔습니다. 다만 오래 지연된 건은 거래 해시와 attestation 상태를 확인하고, 같은 burn을 다시 만들지 말고 서비스 지원 절차로 추적해야 합니다.

Fast Transfer가 항상 더 좋은 선택인가요?

아닙니다. Fast는 속도를 얻는 대신 경로별 수수료와 allowance 조건이 있습니다. 긴급하지 않다면 최종화를 기다리는 Standard가 비용과 위험 설명 면에서 더 알맞을 수 있으므로, 앱은 두 방식의 예상 시간과 실제 수령액을 함께 보여줘야 합니다.

공식 출처

• Circle, CCTP V1 종료 일정 공지 — 2026년 8월 27일
• Circle 개발자 문서, V1에서 V2로 전환하는 전체 가이드 — 2026년 9월 1일 확인
• Circle 개발자 문서, 지원 블록체인과 domain ID — 2026년 9월 1일 확인
• Circle 개발자 문서, Fast·Standard 전송 수수료 — 2026년 9월 1일 확인

해외 공식자료와 국내 공지·보도를 교차 확인해 정리했으며 자료 조사와 초안 구성에 자동화 도구의 도움을 받았습니다.

본 글은 정보 제공 목적이며 투자 권유가 아닙니다. 암호화폐는 원금 손실 위험이 매우 큽니다.