Crypto-backed 스테이블코인: DAI와 USDS
도입
USDC 같은 법정화폐 담보형 스테이블코인은 issuer가 은행 예금, 단기 국채, 상환 절차를 운영한다. DAI/USDS 같은 crypto-backed 모델은 다른 방식으로 안정성을 만든다. 사용자가 담보를 vault에 넣고, 그 담보 가치보다 적은 stablecoin debt를 생성한다. 페그는 issuer의 1:1 상환 약속 하나가 아니라 초과담보, oracle, liquidation, debt ceiling, fee, governance parameter가 함께 지탱한다.
개발자가 이 모델을 볼 때 ERC-20 transfer부터 보면 늦다. 결제 토큰으로 DAI/USDS를 받을 수 있는지 판단하려면 담보 유형, oracle freshness, liquidation backlog, governance parameter change, DAI/USDS converter route를 같이 봐야 한다. 즉 "이 토큰이 전송되는가"보다 "이 시스템이 어떤 상태에서 페그를 잃을 수 있는가"가 먼저다.
2026-05-14 기준 Sky Protocol 공식 문서에서는 Vat이 core vault/accounting state를 추적하고, collateral liquidation은 부족담보 vault의 collateral과 debt를 protocol로 이전한 뒤 auction으로 debt를 회수하는 구조로 설명한다. USDS 문서는 DAI와 USDS의 1:1 converter route도 설명한다. 이 강의는 그 구조를 결제 서비스의 risk dashboard와 allowlist 판단으로 번역한다.
학습 목표
- 과담보, 청산, 오라클, 거버넌스가 페그를 유지하는 방식을 설명한다.
- 법정화폐 담보형과 crypto-backed 모델의 리스크 차이를 비교한다.
- Vault accounting, oracle, liquidation, governance parameter를 모니터링 항목으로 바꾼다.
개념 설명
과담보, 청산, 오라클, 거버넌스가 페그를 유지하는 방식을 설명한다.
이벤트와 내부 원장이 대조되는가
Vault 기반 발행 모델 설명하기
담보 기반 모델의 핵심 파라미터를 설명한다.
1. Crypto-backed 모델은 vault debt로 발행된다
법정화폐 담보형에서 발행의 중심은 issuer mint다. Crypto-backed 모델에서 발행의 중심은 vault debt다. 사용자는 ETH, WBTC, RWA, USDC 같은 담보를 넣고, 프로토콜이 허용하는 비율 안에서 stablecoin debt를 생성한다.
| 구성 | 의미 | 깨지는 방식 |
|---|---|---|
| Vault | 사용자가 담보를 예치하고 debt를 생성하는 계정 | 담보 가치 하락, vault owner 실수 |
| Collateral type | ETH, WBTC, RWA, USDC 등 담보 종류 | 담보별 유동성/리스크 차이 |
| Debt | 발행된 DAI/USDS 부채 | 부채 한도 초과, bad debt |
| Oracle | 담보 가격 입력 | 지연, 조작, stale price |
| Liquidation | 부족 담보 vault를 정리하는 절차 | auction 실패, keeper 부재 |
| Governance | collateral ratio, debt ceiling, fee 조정 | 잘못된 parameter, governance capture |
Sky의 Vat 문서는 core Vault, Dai, collateral state가 Vat에 보관되고, Ilk가 collateral type을 나타내며, Urn이 특정 vault의 collateral과 normalized debt를 갖는다고 설명한다. 이 구조에서 중요한 값은 단순 token balance가 아니라 ink, art, rate, spot, line, dust 같은 accounting parameter다.
2. USDC형과 DAI/USDS형은 깨지는 위치가 다르다
| 항목 | 법정화폐 담보형 | Crypto-backed |
|---|---|---|
| 발행 원천 | issuer mint | vault debt 생성 |
| 준비자산 | 은행 예금, 단기 국채 등 offchain 자산 | onchain collateral과 일부 RWA |
| 가격 안정성 | 상환 약속, 시장 신뢰, 유동성 | 초과담보, liquidation, PSM, fee |
| 개발자 리스크 | freeze, redeem, issuer API, chain별 token address | oracle, collateral ratio, liquidation, debt ceiling |
| 투명성 | attestations와 issuer disclosure | onchain state와 governance parameter |
이 비교는 어느 모델이 더 낫다는 표가 아니다. 결제 시스템에서 어떤 모니터링과 사용자 안내가 필요한지 다르다는 뜻이다. USDC는 issuer status, reserve disclosure, chain별 native token address를 봐야 한다. DAI/USDS는 oracle, liquidation queue, governance parameter, converter route, peg/liquidity를 봐야 한다.
3. Sky/Maker에서 먼저 볼 모듈
Solidity 개발자가 직접 확인할 항목:
- collateral type별 debt ceiling
- liquidation ratio와 liquidation penalty
- oracle security module delay
- auction price curve와 reset 조건
- emergency shutdown 또는 pause 계열 절차
- USDS/DAI token route와 migration 정책
| 모듈/개념 | 강의에서 확인할 질문 |
|---|---|
Vat | vault, collateral, debt accounting invariant가 어디에 있는가? |
Ilk | collateral type별 debt ceiling, debt floor, price margin이 무엇인가? |
Urn | 특정 vault의 담보와 debt가 어떻게 표현되는가? |
| Oracle/OSM | 가격이 얼마나 늦거나 조작될 수 있는가? |
Dog/Clipper | 부족담보 vault가 어떻게 liquidation/auction으로 넘어가는가? |
| DAI/USDS converter | DAI와 USDS가 1:1로 전환되는 route를 제품이 어떻게 인식하는가? |
| Governance | collateral onboarding, parameter change, authorized module 추가가 어떤 리스크를 만드는가? |
4. 청산은 가격 하락 하나로 끝나지 않는다
| 실패 | 설명 | 테스트/모니터링 |
|---|---|---|
| Oracle stale | 가격이 오래되어 실제 담보 가치와 다름 | price age, heartbeat, deviation check |
| Keeper shortage | liquidation을 실행할 참여자가 부족 | auction backlog, gas spike monitoring |
| Liquidity gap | 담보를 팔아도 충분한 stablecoin을 회수 못함 | DEX depth, slippage simulation |
| Governance parameter mistake | collateral ratio/debt ceiling이 과도하게 완화 | parameter change review |
| Stablecoin liquidity run | market에서 DAI/USDS를 팔려는 수요가 급증 | peg deviation, PSM balance |
Sky의 liquidation 문서는 부족담보 vault의 collateral과 debt가 protocol로 이동하고, auction이 시작되어 debt를 회수하려는 구조를 설명한다. 여기서 실패는 여러 단계에서 생긴다. Oracle이 늦으면 안전한 vault가 unfairly liquidated될 수 있고, keeper가 부족하면 auction backlog가 쌓일 수 있으며, price curve parameter가 잘못되면 collateral이 너무 싸거나 비싸게 팔릴 수 있다.
5. 결제 서비스의 dashboard signal로 바꾼다
결제 서비스가 DAI/USDS를 받는다면 아래 신호를 allowlist와 dashboard에 넣어야 한다.
| signal | 왜 보는가 |
|---|---|
| DAI/USDS market peg deviation | 결제 받은 금액의 실제 교환 가능 가치가 달라질 수 있다 |
| DAI/USDS converter route status | DAI와 USDS 중 어떤 토큰을 받을지, 전환 경로가 열려 있는지 판단 |
| oracle freshness | 담보 가치 판단이 stale price에 의존하는지 확인 |
| liquidation backlog | 시스템이 bad debt로 밀리는지 조기 감지 |
| governance parameter change | debt ceiling, liquidation ratio, fee 변경이 리스크를 바꾼다 |
| collateral concentration | 특정 collateral type에 리스크가 몰려 있는지 본다 |
| PSM/converter liquidity | peg 방어와 exit route의 깊이를 확인 |
코드로 확인하기
위 설계 결정을 코드에서 확인한다. 상태, 서명, 원장 이동, 실패 처리가 어디에 놓이는지 따라 읽으면 앞의 모델이 실제 구현 경계로 내려온다.
컨트랙트Maker Vat 핵심 데이터 모델 — Ilk + Urn
DAI/USDS는 issuer mint가 아니라 vault 부채로 발행된다.
Vat가 collateral type(Ilk)과 개별 vault(Urn)의 잔액·부채를 추적한다. checkout 통합 코드는 이 구조에 직접 접근하지 않지만, 모니터링은 이 데이터를 읽는다.
// 개념 모델 — 실제 Maker 코드는 RAD/WAD 단위와 fixed-point 연산을 사용한다interface IVat { struct Ilk { uint256 Art; // 총 부채 (DAI) uint256 rate; // 누적 stability fee uint256 spot; // 청산 가격 임계값 uint256 line; // debt ceiling uint256 dust; // 최소 부채 } struct Urn { uint256 ink; // 담보 잔액 uint256 art; // 부채 잔액 } function ilks(bytes32 ilk) external view returns (Ilk memory); function urns(bytes32 ilk, address user) external view returns (Urn memory); function dai(address user) external view returns (uint256); // RAD 단위 function sin(address user) external view returns (uint256); // 시스템 bad debt}인덱서DAI/USDS 결제용 health 모니터링 — viem 기반
결제 receiver가 받은 DAI를 그대로 보유한다면 시스템 health 가 결제 안전성에 영향을 준다. 매분 빠른 신호 3개를 수집.
import { createPublicClient, http, parseAbi } from "viem";import { mainnet } from "viem/chains";const client = createPublicClient({ chain: mainnet, transport: http() });const vatAbi = parseAbi([ "function ilks(bytes32) view returns (uint256 Art, uint256 rate, uint256 spot, uint256 line, uint256 dust)", "function sin(address) view returns (uint256)"]);const VAT = "0x35D1b3F3D7966A1DFe207aa4514C12a259A0492B";const VOW = "0xA950524441892A31ebddF91d3cEEFa04Bf454466";export async function snapshotMakerHealth() { const ethA = await client.readContract({ address: VAT, abi: vatAbi, functionName: "ilks", args: ["0x4554482d41000000000000000000000000000000000000000000000000000000"] // "ETH-A" }); const sin = await client.readContract({ address: VAT, abi: vatAbi, functionName: "sin", args: [VOW] }); return { ethA: { Art: ethA[0], rate: ethA[1], spot: ethA[2], line: ethA[3] }, systemBadDebt: sin, measuredAt: new Date().toISOString() };}백엔드결제 가드 — DAI/USDS 수령 시 system health 검증
checkout 결제 직후가 아니라, merchant에게 정산할 때 한 번 더 system health를 확인한다. 임계값을 넘으면 settlement 를 holds로 표시.
import { snapshotMakerHealth } from "./maker-health";const BAD_DEBT_BLOCK_THRESHOLD = 50_000_000_000n * 10n ** 45n; // 50M DAI in RADconst PEG_DEVIATION_BLOCK_BPS = 50; // 0.5%export async function shouldSettleDai(amount: bigint, currentPegBps: number) { const health = await snapshotMakerHealth(); if (health.systemBadDebt > BAD_DEBT_BLOCK_THRESHOLD) { return { decision: "hold", reason: `Maker system bad debt above threshold: ${health.systemBadDebt}`, escalateTo: "treasury-oncall" }; } if (Math.abs(currentPegBps) > PEG_DEVIATION_BLOCK_BPS) { return { decision: "hold", reason: `DAI peg deviation > ${PEG_DEVIATION_BLOCK_BPS} bps`, escalateTo: "risk-oncall" }; } return { decision: "settle" };}강의 포인트
| 관점 | 강의 중 확인할 질문 | 학습 후 남길 증거 |
|---|---|---|
| 발행 모델 | stablecoin은 issuer mint인가, vault debt인가? | USDC형과 DAI/USDS형 비교표 |
| accounting | Vat, Ilk, Urn이 무엇을 추적하는가? | 핵심 parameter 목록 |
| liquidation | 담보 가격 하락이 어떤 단계로 bad debt 위험이 되는가? | 청산 상태도 |
| oracle | 가격 원천과 stale price를 어떻게 감시하는가? | price age, heartbeat, deviation 기준 |
| 결제 운영 | DAI/USDS를 받을 때 어떤 dashboard signal이 필요한가? | peg, converter, liquidation, governance signal 목록 |
실무 예시
백엔드[INDEXER] checkout 서비스가 USDC와 DAI/USDS를 모두 받으려 한다고 가정한다. USDC는 issuer disclosure와 native token address allowlist가 중요하다. DAI/USDS는 결제 직후에는 ERC-20 transfer가 정상이어도, 시스템 risk가 빠르게 변할 수 있다.
| 의사결정 | USDC형에서 볼 것 | DAI/USDS형에서 볼 것 |
|---|---|---|
| token allowlist | official contract address, native/bridged 여부 | DAI, USDS, converter route, chain support |
| risk dashboard | reserve disclosure, issuer status | peg deviation, oracle freshness, liquidation backlog |
| route disable | issuer/redemption issue | auction failure, governance emergency, converter issue |
| user copy | "issuer-backed digital dollar" | "overcollateralized protocol-backed stablecoin" |
| support flow | redemption/freeze/issuer issue | peg deviation, liquidity, converter route issue |
이 표는 결제 운영에서 중요하다. 사용자는 둘 다 "달러 스테이블코인"으로 보지만, 운영자가 봐야 하는 장애 신호는 다르다. DAI/USDS를 받는다면 token transfer 성공만으로 route health를 판단하면 안 된다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 바로잡는 방법 |
|---|---|---|
| DAI/USDS도 USDC처럼 issuer mint 모델이라고 본다 | mint 권한과 vault debt 생성 구조를 혼동한다 | vault, collateral, debt model을 먼저 그린다 |
| overcollateralized면 항상 안전하다고 본다 | oracle stale, liquidation backlog, liquidity gap이 누적된다 | collateral ratio뿐 아니라 liquidation health를 본다 |
| 청산은 자동이므로 운영 리스크가 없다고 생각한다 | keeper shortage나 auction parameter 문제로 bad debt가 생긴다 | auction backlog와 governance parameter를 모니터링한다 |
| governance parameter는 개발자가 볼 필요 없다고 생각한다 | debt ceiling, liquidation ratio 변경이 결제 리스크를 바꾼다 | parameter change review를 dashboard signal로 둔다 |
| DAI와 USDS converter route를 고정 사실로 본다 | token route 정책 변경이나 chain 지원 차이를 놓친다 | 공식 token route 문서와 마지막 확인일을 기록한다 |
실습 과제
- 컨트랙트Vault 기반 발행 모델 설명하기: Vault, collateral type, normalized debt, oracle price, liquidation ratio, debt ceiling이 DAI/USDS 발행과 페그 유지에 어떻게 연결되는지 설명한다.
- 컨트랙트[OPS] 청산 실패 상태도 작성하기: 담보 가격 30% 하락, oracle stale, keeper shortage, auction backlog를 포함해 vault가 안전 상태에서 bad debt로 가는 상태도를 작성한다.
- 인덱서[OPS] DAI/USDS 결제 dashboard signal 만들기: 결제 서비스가 DAI/USDS를 받을 때 peg deviation, PSM/converter route, oracle freshness, liquidation backlog, governance parameter change를 모니터링 항목으로 정의한다.
완료 기준
- 담보 기반 모델의 핵심 파라미터를 설명한다.
- 청산 실패 시나리오를 작성했다.
- 거버넌스 리스크 질문을 남겼다.
- DAI/USDS를 결제 토큰으로 받을 때 필요한 dashboard signal을 정의했다.
근거 자료
- Crypto Backed 스테이블코인 DAI USDS: 01-스테이블코인/08-Crypto-Backed-스테이블코인-DAI-USDS.md
- Sky Protocol: Vat Core Accounting: https://developers.sky.money/protocol/core/vat/
- Sky Protocol: Collateral Liquidation: https://developers.sky.money/protocol/vaults/collateral-liquidation/
- Sky Protocol: USDS: https://developers.sky.money/protocol/tokens/usds/
- Sky Protocol: Protocol Token Routes: https://developers.sky.money/quick-start/protocol-token-routes/