체인별 스테이블코인 공급은 ticker가 아니라 contract와 issuer, 상환 경로를 기준으로 나눠야 합니다. Native issuance는 issuer가 해당 chain에서 발행·소각하고 정해진 상환 체계에 연결하지만, third-party bridged token은 다른 chain의 원본이 bridge에 잠긴 데 대한 representation일 수 있습니다. 전 체인 합계에서는 native supply를 합산하되 lock된 원본과 wrapped 공급을 같은 경제 단위로 이중 계산하지 않고, CCTP burn-and-mint 이동은 transit 상태를 조정합니다.
Ticker 대신 발행자와 계약을 식별합니다
Wallet UI의 USDC 이름과 6 decimals는 진위를 보장하지 않습니다. ChainId, contract address, issuer 공식 지원 목록, proxy implementation과 mint authority를 기록합니다. Circle은 supported chain의 USDC와 bridged USDC를 구분하고 Circle Mint에 bridged USDC를 잘못 보내지 말라고 안내합니다.
Bridged USDC는 third party가 만들고 다른 chain의 USDC가 bridge contract에 잠긴 데 기반할 수 있으며 Circle이 직접 발행·상환하지 않는다고 설명됩니다. **표시 이름이 같아도 issuer redemption claim은 다를 수 있습니다**.
멀티체인 스테이블코인 공급의 기본 키는 ticker가 아니라 chain·contract·issuer·상환 경로의 조합입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- Ticker 대신 발행자와 계약을 식별합니다
Wallet UI의 USDC 이름과 6 decimals는 진위를 보장하지 않습니다.
- 체인별 세 개 bucket으로 나눕니다
가정 Ethereum native 100억, Base native 20억, L2 third-party bridged 5억이 있고 그 backing 5억이 Ethereum 100억 안의 bridge escrow라면 issuer-native 합계는 120억입니다.
- CCTP와 lock-mint를 다른 이동으로 봅니다
CCTP는 source native token을 burn하고 attested message를 거쳐 destination native token을 mint합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
체인별 세 개 bucket으로 나눕니다
가정 Ethereum native 100억, Base native 20억, L2 third-party bridged 5억이 있고 그 backing 5억이 Ethereum 100억 안의 bridge escrow라면 issuer-native 합계는 120억입니다. Economic accessible units도 120억으로 볼 수 있지만 화면상의 contract supply 합은 125억입니다.
Bridge representation을 생태계 활동 지표로 별도 보고할 수는 있습니다. 다만 전체 스테이블코인 공급이라고 부를 때는 escrow 원본을 빼거나 representation을 빼는 일관된 consolidation rule이 필요합니다. **Contract supply 합계를 곧 경제 공급 합계로 쓰지 않습니다**.
| 체인·형태 | Contract supply | 통합 처리 |
|---|---|---|
| Ethereum native | 10.0B | 포함 |
| 그중 bridge escrow | 0.5B | 원본에 이미 포함 |
| Base native | 2.0B | 포함 |
| L2 bridged | 0.5B | 표현 공급, 중복 제거 |
| Issuer-native total | 12.0B | 공식 발행 합계 |
CCTP와 lock-mint를 다른 이동으로 봅니다
CCTP는 source native token을 burn하고 attested message를 거쳐 destination native token을 mint합니다. Message가 transit이면 source burn은 완료됐지만 destination mint 전이라 chain별 합계가 잠시 줄 수 있습니다. Burn·attestation·mint 상태를 연결합니다.
Lock-mint는 source supply가 줄지 않고 escrow balance만 늘 수 있습니다. Destination token이 native인지 bridged인지 route마다 확인합니다. **Burn event와 escrow deposit을 같은 공급 감소로 처리하지 않습니다**.
- Issuer 공식 지원 chain과 contract 목록을 snapshot합니다.
- 각 contract의 mint authority와 redemption route를 기록합니다.
- Native·canonical bridged·third-party bridged로 분류합니다.
- Escrow와 wrapped supply를 message 단위로 대사합니다.
- Transit·migration·deprecated contract를 별도 표시합니다.
Migration은 시계열 단절을 만듭니다
Bridged-to-native upgrade가 contract address를 유지할 수도 있지만 issuer·reserve claim은 특정 시점부터 바뀝니다. Circle의 standard도 upgrade 가능성을 제공할 뿐 의무를 뜻하지 않습니다. 발표만으로 과거 bridged supply를 native로 소급 분류하지 않습니다.
새 native contract 출시와 기존 bridged contract 병존 시 holder migration, DEX pool과 exchange ticker를 추적합니다. Deprecated label이 있어도 잔액이 남으면 공급표에서 숨기지 않고 상환 가능성과 가격을 별도 표시합니다.
Dashboard에 품질 경계를 노출합니다
집계 시각, block hash, node finality, contract list version과 미분류 token을 공개합니다. Explorer token list나 symbol 검색으로 자동 합산하면 사칭 contract가 들어갈 수 있으므로 issuer list를 allowlist로 사용합니다.
체인 장애·bridge pause 때 representation price가 이탈해도 supply unit이 즉시 사라진 것은 아닙니다. 공급, backing, redemption availability와 market price를 별도 지표로 보고 결손 판단에는 reserve·contract 증거를 요구합니다.
자주 묻는 질문
모든 chain의 USDC totalSupply를 더하면 되나요?
Native contract끼리는 가능하지만 bridge escrow 원본과 representation을 동시에 더하면 중복될 수 있습니다.
Bridged USDC도 Circle이 달러로 직접 상환하나요?
형태에 따라 다르며 third-party bridged token은 먼저 원본 chain USDC로 unbridge해야 할 수 있습니다.
Bridged-to-native 발표 뒤 과거 데이터도 native인가요?
아닙니다. 실제 ownership·implementation·상환 전환이 완료된 block을 경계로 version을 나눠야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
