Lock-and-mint 브리지는 source escrow의 정식 잔액이 destination wrapped token 공급 이상인지 확인합니다. 반대 방향은 wrapped burn과 원본 release를 같은 message에 연결합니다. Burn-and-mint 방식은 chain별 공급 증감이 상쇄되는지 보고, liquidity bridge는 wrapped totalSupply가 아니라 각 pool의 부채·재고 규칙을 따라야 합니다. Pending message, fee-on-transfer, reorg와 여러 bridge contract를 분리하지 않으면 일시적 차이나 중복을 결손으로 오판할 수 있습니다.
브리지 유형부터 식별합니다
Lock-and-mint는 원본 token을 source contract에 잠그고 destination representation을 mint합니다. Burn-and-release는 돌아올 때 wrapped를 burn하고 escrow 원본을 풉니다. CCTP처럼 source에서 native token을 burn하고 destination에서 native token을 mint하는 방식은 escrow 잔액식이 없습니다.
Circle 문서는 bridged USDC를 다른 chain의 USDC가 bridge contract에 잠긴 데 대응해 third party가 만든 token으로 구분합니다. **같은 ticker와 decimals만으로 동일한 상환 경로를 가정하지 않습니다**. Contract와 bridge route를 자산 식별자에 포함합니다.
브리지 공급 대사는 두 체인의 totalSupply 비교가 아니라 한 메시지가 만든 잠금·발행·소각·해제를 연결하는 일입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 브리지 유형부터 식별합니다
Lock-and-mint는 원본 token을 source contract에 잠그고 destination representation을 mint합니다.
- 정식 상태의 담보식을 계산합니다
가정 Ethereum escrow 1,000만 원본, L2 wrapped supply 980만, outbound pending 30만, inbound burn pending 10만이라면 시점 조정 뒤 기대 차이는 0일 수 있습니다.
- 메시지 lifecycle을 원장으로 둡니다
Deposit initiated만 있고 destination finalize가 없으면 pending입니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
정식 상태의 담보식을 계산합니다
가정 Ethereum escrow 1,000만 원본, L2 wrapped supply 980만, outbound pending 30만, inbound burn pending 10만이라면 시점 조정 뒤 기대 차이는 0일 수 있습니다. 단순 20만 초과담보라고 끝내지 말고 message status를 반영합니다.
여러 destination이 같은 escrow를 공유하면 각 chain wrapped supply 합계를 분모로 씁니다. 별도 escrow라면 contract별로 대응시킵니다. **Escrow balance와 발행 공급의 기준 block finality를 맞춥니다**.
| 항목 | 수량 | 대사 처리 |
|---|---|---|
| Source escrow | 10.0M | 담보 stock |
| L2 active wrapped | 9.8M | 부채 stock |
| Outbound pending | 0.3M | mint 예정 |
| Inbound burn pending | 0.1M | release 예정 |
| 조정 차이 | 0 | 정상 가정 |
메시지 lifecycle을 원장으로 둡니다
Deposit initiated만 있고 destination finalize가 없으면 pending입니다. Timeout 뒤 retry 가능한지, 실패 message가 환불되는지 bridge 문서대로 상태를 나눕니다. 같은 nonce 재처리 방지와 destination event를 확인합니다.
CCTP attestation API는 source burn event의 message hash에 대한 서명 상태를 제공합니다. Attestation 완료와 destination mint transaction 성공을 별도 열로 둡니다. **서명을 받았다고 mint 완료로 기록하지 않습니다**.
- Source·destination chainId와 contract를 고정합니다.
- Deposit message ID와 lock·burn transaction을 저장합니다.
- Destination mint·release transaction과 연결합니다.
- 양쪽 canonical finality 뒤 stock을 다시 읽습니다.
- Pending·failed·refunded를 별도 bucket으로 남깁니다.
수수료형 token과 liquidity bridge를 분리합니다
Transfer fee token은 사용자가 100을 보냈어도 escrow에 98만 도착할 수 있습니다. Bridge가 입력값 100을 mint하면 부족이 생깁니다. 실제 balance delta를 쓰는지 지원 문서를 확인하고 지원되지 않으면 정상 공식에 억지로 넣지 않습니다.
Liquidity bridge는 destination pool에서 기존 token을 지급하고 rebalancer가 나중에 채울 수 있습니다. 이 경우 pool inventory, credit limit, unsettled transfer가 핵심이며 wrapped supply=escrow 식은 적용되지 않습니다.
차이를 재현 가능한 증거로 남깁니다
대사 snapshot에는 block hash, escrow balance, wrapped totalSupply, pending message 목록, fee와 decimals를 보관합니다. Upgrade로 contract가 바뀌면 migration 전후 잔액을 이어 주고 오래된 contract의 잔여량을 숨기지 않습니다.
차이가 생기면 finality 지연, indexer 누락, unsupported token, 잘못된 contract, 중복 mint 순서로 조사합니다. 결손이나 exploit 표현은 contract state와 message history를 확인한 뒤에만 씁니다.
자주 묻는 질문
Wrapped 공급이 escrow보다 잠시 많으면 바로 미담보인가요?
Finality와 pending burn·mint, 수수료와 공유 escrow를 조정한 뒤에도 차이가 남는지 확인해야 합니다.
모든 bridge는 원본을 잠그나요?
아닙니다. Burn-and-mint와 liquidity pool 방식은 다른 대사 공식을 사용합니다.
같은 USDC 이름이면 합산해도 되나요?
Issuer, contract와 redemption route가 다를 수 있어 native와 third-party bridged version을 분리해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
