Copy English

Why

The 2022 lesson, stated structurally: a wrapped token is a liability issued by its bridge. Lock-and-wrap made every bridge an unlicensed mint — the wrap contract would print against a lockbox it believed in, so one signature compromise on the lockbox printed unbacked supply into every connected chain. The three designs in this card are the industry converging on the only durable fix: the token's issuer — not the transport — owns mint and burn, and the transport merely carries messages. What remains open, and what actually differentiates them, is where the residual trust pools.

Three shapes of the same delegation. xERC20 (ERC-7281) keeps multiple bridges but caps each one's mint rate on-chain — trust is diversified and bounded by code, and the interesting knob becomes the limit's refill curve. CCTP collapses the question: Circle burns and mints itself, so bridge risk becomes issuer risk — clean, and honest about USDC's nature, since Circle could already freeze you. NTT is a framework, not a policy: hub-and-spoke or burn-and-mint, chosen per deployment — which means reading an NTT token's risk requires reading its configuration, not its brand. None of the three eliminates the infinite-mint party; they choose it. the-bridge-is-inside-the-token said the bridge's trust ships inside the asset — this card is the catalogue of what shapes that trust can take, and the first fork in any settlement-asset design.

How it works

The three designs

The loss-cap arithmetic (xERC20-style limits)

A generous refill rate with slow detection is an unlimited mint with extra steps.

Questions before choosing, in order

1. Whose compromise mints infinitely — and is that party's failure already priced into holding the token?
2. What is r × T for each connected bridge, using honest detection latency (nights, weekends)?
3. Who can raise the limits, and through what process — the limit's governance is part of the limit?
4. For NTT: which mode is this deployment actually in, verified on-chain, not from docs?

← All Dev Notes · Workspace Index · Top ↑

Copy 한국어

xERC20 · CCTP · NTT — "누가 mint 를 쥐는가"의 세 가지 답

락업-래핑 브릿지들은 실패 모드 하나를 공유했습니다: 브릿지가 뚫리면 무한 발행 — 2022년 브릿지 참사들의 공통 구조. xERC20·CCTP·NTT 는 같은 교정 — 발행사가 mint 권한을 회수한다 — 의 세 변주입니다: xERC20 은 한도를 코드로(브릿지별 rate limit), CCTP 는 권한을 단일 주체로(Circle 의 burn-and-mint 독점), NTT 는 선택을 배포자에게. 차이는 기술이 아니라 신뢰 위임의 모양입니다.

정직한 질문은 하나입니다: 누가 뚫리면 무한 발행인가? 설계별로 그 답을 적고, "한도"를 실제 손실 상한으로 만드는 단 하나의 파라미터 — rate limit 의 회복 속도 — 를 측정합니다. 빨리 다시 차는 브릿지별 한도는 한도라 보기 어렵습니다: 빼고, 기다리고, 또 뺍니다. 초당 회복 토큰 수를 발행사의 감지·정지 지연과 겹쳐 그리십시오 — 손실 상한은 명목 숫자가 아니라 한도 × (감지까지의 시간 ÷ 리필 주기)입니다. Verex 토큰·정산 자산이라면 레일을 고르기 전에 howItWorks 의 표를 후보 체인마다 돌려 보십시오.

왜

2022년의 교훈을 구조적으로 말하면: 래핑 토큰은 브릿지가 발행한 부채입니다. 락업-래핑은 모든 브릿지를 무허가 조폐국으로 만들었습니다 — 랩 컨트랙트는 자기가 믿는 금고를 근거로 찍어 냈으므로, 금고의 서명 하나가 뚫리면 연결된 모든 체인에 무담보 공급이 인쇄됐습니다. 이 카드의 세 설계는 업계가 유일하게 오래가는 수정으로 수렴한 것입니다: 운송이 아니라 토큰의 발행사가 mint·burn 을 소유하고, 운송은 메시지만 나릅니다. 열려 있는 것 — 그리고 셋을 실제로 가르는 것 — 은 잔여 신뢰가 어디에 고이는가입니다.

같은 위임의 세 모양. xERC20(ERC-7281)은 브릿지 여럿을 유지하되 각각의 mint 속도를 온체인에서 상한합니다 — 신뢰가 분산되고 코드로 유계가 되며, 흥미로운 손잡이는 한도의 리필 곡선이 됩니다. CCTP 는 질문을 접어 버립니다: Circle 이 직접 태우고 찍으므로 브릿지 리스크가 발행사 리스크가 됩니다 — 깔끔하고, USDC 의 본성에 정직합니다. Circle 은 원래도 당신을 동결할 수 있었으니까. NTT 는 정책이 아니라 프레임워크입니다: hub-and-spoke 냐 burn-and-mint 냐를 배포마다 고릅니다 — NTT 토큰의 리스크를 읽으려면 브랜드가 아니라 설정을 읽어야 한다는 뜻입니다. 셋 중 어느 것도 무한 발행의 주체를 없애지 않습니다 — 고를 뿐입니다. the-bridge-is-inside-the-token 이 브릿지의 신뢰가 자산 안에 실려 온다고 했다면, 이 카드는 그 신뢰가 취할 수 있는 모양의 목록이고 — 정산 자산 설계의 첫 갈림길입니다.

동작 방식

세 설계

손실 상한 산수 (xERC20 형 한도)

후한 리필에 느린 감지는 절차만 늘어난 무한 발행입니다.

고르기 전에 물을 것, 순서대로

1. 누가 뚫리면 무한 발행인가 — 그 주체의 실패는 이 토큰 보유에 이미 가격이 매겨져 있는가?
2. 연결된 브릿지마다 r × T 는 얼마인가 — 감지 지연은 정직하게(밤, 주말 포함)?
3. 한도는 누가 어떤 절차로 올릴 수 있는가 — 한도의 거버넌스도 한도의 일부다.
4. NTT 라면: 이 배포는 실제로 어느 모드인가 — 문서 말고 온체인에서 확인.

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑