발행, 소각, 준비자산, 상환

도입

mint와 burn은 컨트랙트 함수 이름이지만, 스테이블코인 제품에서는 그 앞뒤에 더 긴 업무 흐름이 있다. 발행은 고객의 fiat 입금, issuer의 reserve 증가, 내부 승인, onchain mint, 사용자 지갑 입금이 연결된 과정이다. 상환은 그 반대처럼 보이지만 실제로는 burn 확정, 내부 원장 차감, treasury 승인, fiat payout, 사용자 알림이 따로 움직인다.

이 강의에서 가장 중요한 구분은 "컨트랙트 권한이 있다"와 "준비자산이 충분하다"가 같은 말이 아니라는 점이다. Minter 권한은 토큰을 발행할 수 있게 해주지만 reserve를 증명하지 않는다. Burn event는 상환 절차의 한 단계지만 fiat payout이 완료됐다는 뜻은 아니다.

따라서 개발자는 발행/상환을 상태머신으로 다뤄야 한다. 어떤 상태가 onchain event로 증명되는지, 어떤 상태가 issuer 내부 원장이나 은행 rail에 의존하는지, 어디서 사용자가 기다려야 하는지, 어느 지점에서 운영자가 수동 개입해야 하는지를 나눠야 한다.

학습 목표

• 준비자산 기반 스테이블코인의 생명주기를 설명한다.
• 상환 지연과 준비자산 불일치가 제품 리스크로 전이되는 과정을 파악한다.
• mint/burn 권한과 reserve accounting을 서로 다른 검증 대상으로 분리한다.

개념 설명

1. 발행과 상환은 서로 다른 원장을 지난다

발행과 상환은 단순히 mint와 burn을 반대로 놓은 흐름이 아니다. 발행은 fiat 또는 treasury asset이 들어온 뒤 token liability가 늘어나는 과정이고, 상환은 token liability를 줄인 뒤 fiat payout이 나가는 과정이다. 둘 다 onchain state, issuer ledger, bank/treasury rail, customer support 상태를 함께 본다.

위 흐름에서 onchain mint와 onchain burn만 확정성이 높다. Fiat 입금 확인, reserve ledger 증가, payout 실행은 offchain 시스템에 의존한다. 그러므로 checkout 제품이나 treasury dashboard는 onchain event만 보지 말고 issuer 상태와 내부 원장 상태를 함께 저장해야 한다.

2. 준비자산은 onchain invariant가 아니다

Circle 공식 문서는 USDC가 highly liquid cash와 cash-equivalent assets로 backing되고 1:1 redeem 가능하다고 설명하며, Transparency 페이지에서 reserve 관련 자료와 monthly attestation reports를 공개한다. 이 내용은 2026-05-14 기준으로 확인했다. 여기서 중요한 점은 reserve disclosure가 컨트랙트 내부 상태가 아니라 issuer 운영 및 외부 보고 레이어라는 것이다.

개발자가 할 일은 reserve를 직접 증명하는 척하는 것이 아니다. 출처, 보고 주기, 적용 범위, 마지막 확인일을 제품 정책과 dashboard에 남기는 것이다. Reserve 정보가 늦게 갱신되거나 issuer가 redemption 상태를 바꾸면 checkout, withdrawal, treasury movement에 어떤 제한을 걸지 정해야 한다.

3. 발행자 권한은 필요한 동시에 위험하다

권한 표의 목적은 "권한이 많으니 나쁘다"가 아니다. 발행자형 스테이블코인은 운영상 mint, burn, freeze, pause가 필요할 수 있다. 문제는 각 권한의 책임과 감시가 분리되지 않을 때 생긴다. Minter와 Burner가 같아도 되는지, Freezer가 payment product의 pending 상태에 어떤 영향을 주는지, Upgrader가 사용자 잔고 규칙을 바꿀 수 있는지, Admin을 잃었을 때 복구 경로가 있는지 확인해야 한다.

4. 컨트랙트 설계와 운영 설계를 함께 둔다

• mint와 burn 권한은 분리한다.
• role 변경은 event로 남기고 dashboard에서 감시한다.
• 마지막 admin을 제거할 수 없게 한다.
• pause와 freeze를 구분한다. pause는 전체 시스템, freeze는 주소 단위다.
• reserve accounting은 onchain totalSupply와 같지 않다. reserve는 offchain asset이므로 별도 ledger와 reporting이 필요하다.
• redemption queue, payout 지연, manual review 상태를 내부 원장에 둔다.
• burn이 성공했지만 fiat payout이 실패한 경우를 별도 상태로 표현한다.

5. 상환 리스크는 사용자 UX로 전이된다

상환은 사용자가 token을 fiat로 바꾸는 과정이다. 여기서 깨질 수 있는 지점은 많고, 각각 사용자에게 보여줘야 하는 상태가 다르다.

6. 테스트와 runbook으로 바꾼다

테스트는 컨트랙트 단위와 운영 상태 단위로 나눠야 한다.

코드로 확인하기

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

컨트랙트mint / burn 함수와 supply invariant

mint와 burn은 단순한 supply 변경이 아니라 issuer의 운영 결정이 컨트랙트 호출로 내려온 결과다. role + pause + event를 한꺼번에 묶는다.

01contract IssuableStablecoin is AccessControl, Pausable {02    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");03    bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");0405    event Mint(address indexed to, uint256 amount, bytes32 issuerRefId);06    event Burn(address indexed from, uint256 amount, bytes32 redemptionRefId);0708    /// @param issuerRefId issuer 내부 ledger 의 입금/승인 식별자 — onchain ↔ offchain 매칭 키09    function mint(address to, uint256 amount, bytes32 issuerRefId)10        external11        onlyRole(MINTER_ROLE)12        whenNotPaused13    {14        if (to == address(0)) revert();15        if (amount == 0) revert();16        _mint(to, amount);17        emit Mint(to, amount, issuerRefId);18    }1920    /// @param redemptionRefId support ticket 또는 redemption batch ID21    function burn(address from, uint256 amount, bytes32 redemptionRefId)22        external23        onlyRole(BURNER_ROLE)24    {25        // burn 은 pause 중에도 허용 — redemption 흐름이 사용자 보호 차원에서 열려 있어야 한다26        _burn(from, amount);27        emit Burn(from, amount, redemptionRefId);28    }29}

인덱서burn event ↔ redemption ledger 매칭 (TypeScript)

burn event 한 줄로 redemption 처리가 끝났다고 보면 안 된다. fiat payout 까지 완료된 후에만 사용자에게 "완료" 로 안내한다.

01type RedemptionStatus =02  | "requested"03  | "compliance_review"04  | "burn_submitted"05  | "burn_confirmed"06  | "payout_pending"07  | "payout_succeeded"08  | "payout_failed";0910async function reconcileBurnEvent(event: { from: `0x${string}`; amount: bigint; redemptionRefId: `0x${string}` }) {11  const row = await prisma.redemption.findUnique({ where: { refId: event.redemptionRefId } });12  if (!row) {13    await alerts.fire({ severity: "critical", reason: "burn without redemption row", event });14    return;15  }16  if (row.amount !== event.amount) {17    await alerts.fire({ severity: "critical", reason: "burn amount mismatch", row, event });18    return;19  }2021  await prisma.redemption.update({22    where: { id: row.id },23    data: { status: "burn_confirmed", burnTxHash: event.transactionHash }24  });25  // 이후 fiat payout job 이 별도로 payout_pending → payout_succeeded 로 옮긴다26}

백엔드Reserve attestation 외부 호출 + cache + freshness 가드

Circle Transparency 같은 외부 attestation 은 onchain invariant 가 아니다. cache + freshness 체크로 다뤄야 stale 표시를 사용자에게 정확히 줄 수 있다.

01type ReserveAttestation = {02  issuer: string;03  reserveUsd: number;04  circulatingUsd: number;05  attestedAt: string; // ISO06  reportUrl: string;07};0809const FRESHNESS_HOURS = 30 * 24; // 30 days1011export async function getReserveAttestation(issuer: "circle" | "paypal" | "tether"): Promise<{12  data: ReserveAttestation;13  freshness: "fresh" | "stale" | "missing";14}> {15  const cached = await redis.get(`reserve:${issuer}`);16  let data: ReserveAttestation;1718  if (cached) {19    data = JSON.parse(cached);20  } else {21    data = await fetchAttestation(issuer); // 발행자별 endpoint22    await redis.set(`reserve:${issuer}`, JSON.stringify(data), "EX", 3600);23  }2425  const ageHours = (Date.now() - Date.parse(data.attestedAt)) / 3_600_000;26  const freshness = ageHours > FRESHNESS_HOURS ? "stale" : "fresh";27  return { data, freshness };28}

강의 포인트

실무 예시

백엔드[INDEXER] [OPS] 사용자가 10,000 USDC를 fiat로 상환하려고 한다. 사용자는 지갑에서 burn 트랜잭션을 보냈고, explorer에서는 성공으로 보인다. 그런데 fiat payout이 은행 rail 문제로 지연된다. 이때 제품이 "상환 완료"라고 표시하면 안 된다.

이 상태표는 결제 상태머신 레슨과 바로 연결된다. 사용자 화면, 내부 원장, onchain event, support 상태가 모두 같은 단어를 쓰면 장애 때 원인을 찾기 어렵다. 각 상태가 어떤 시스템의 증거로 바뀌는지 분리해야 한다.

흔한 오해와 실패 시나리오

실습 과제

1. 백엔드[INDEXER] 발행/상환 원장 차이 설명하기: fiat 입금, reserve 증가, mint 승인, onchain mint, burn, reserve 감소, fiat payout이 각각 어느 원장과 이벤트에 남는지 표로 정리한다.
2. 운영상환 장애 runbook 작성하기: burn은 성공했지만 fiat payout이 지연되는 상황을 가정하고 사용자 표시 상태, 운영자 확인 항목, dashboard alert, 수동 복구 기준을 작성한다.
3. 컨트랙트권한과 reserve 검증 분리하기: Minter, Burner, Freezer, Pauser, Upgrader, Admin 권한을 표로 정리하고, 각 권한이 reserve accounting을 직접 증명하지 못하는 이유를 설명한다.

완료 기준

1. 발행과 상환의 원장 차이를 설명한다.
2. 준비자산 출처와 갱신 주기를 남겼다.
3. 상환 장애 runbook 초안을 만들었다.
4. mint, burn, reserve, fiat payout 상태를 분리한 상태머신을 작성했다.

근거 자료

• 발행 소각 준비자산 상환: 01-스테이블코인/02-발행-소각-준비자산-상환.md
• Circle Transparency: https://www.circle.com/transparency
• Circle: What is USDC?: https://developers.circle.com/stablecoins/what-is-usdc
• OpenZeppelin Contracts: Access Control: https://docs.openzeppelin.com/contracts/5.x/access-control