준비자산, NAV, 상환 운영
도입
RWA 기반 준비자산은 stablecoin의 1달러 UX 뒤에 있는 경제적 현실이다. 사용자는 stablecoin balance만 보지만, issuer는 cash, T-bill, MMF, tokenized vault share, fiat rail, redemption queue를 모두 관리해야 한다.
이 강의의 핵심은 세 가지 장부를 분리하는 것이다. Onchain token ledger는 supply와 balance를 보여준다. Reserve ledger는 어떤 자산이 어디에 보관되어 있고 얼마로 평가되는지 보여준다. Redemption ledger는 사용자의 fiat 상환 요청이 어떤 상태인지 보여준다. 셋 중 하나만 봐서는 상환 가능성을 판단할 수 없다.
학습 목표
- NAV 산정, 준비자산 보고, redemption 지연을 연결한다.
- RWA 상품의 운영 리스크를 대시보드 지표로 바꾼다.
개념 설명
핵심 가정 오류
share와 asset 권리가 분리되는가
운영 상태 누락
비동기 상환 상태가 보이는가
학습 산출물 미흡
준비자산, NAV, 상환 운영 이해 점검
| 장부 | 기록 대상 | 대표 필드 | 실패 시나리오 |
|---|---|---|---|
| Onchain token ledger | stablecoin totalSupply와 balances | chainId, token, holder, balance, supply | burn은 됐지만 fiat 지급이 지연됨 |
| Reserve ledger | cash, T-bill, MMF, tokenized asset 보유량 | custodian, asset type, quantity, NAV, timestamp | NAV는 충분하지만 즉시 현금화 불가 |
| Redemption ledger | 사용자의 상환 요청과 처리 상태 | requestId, user, amount, kycStatus, burnTx, fiatStatus | queue 지연, rejection, liquidity gate |
NAV는 reserve asset의 평가 가치다. 하지만 NAV가 높다는 사실만으로 오늘 상환할 현금이 충분하다는 뜻은 아니다.
| 개념 | 질문 | dashboard 지표 |
|---|---|---|
| NAV | 자산을 어떤 방법과 시점으로 평가했는가 | navValue, navTimestamp, valuationMethod |
| Liquidity | 오늘 또는 이번 settlement window에 현금화 가능한가 | cashBucket, sameDayLiquidity, maturityBucket |
| Redemption queue | 누가 얼마를 기다리고 있는가 | pendingAmount, averageWait, oldestRequestAge |
| Haircut/stress | stress 상황에서 얼마를 할인해야 하는가 | stressDiscount, liquidityGap |
| Evidence | 어떤 출처를 믿는가 | custodian report, issuer attestation, onchain proof |
Redemption 상태는 fiat와 onchain을 모두 포함한다.
코드로 확인하기
NAV와 redemption은 숫자 자체보다 "언제, 누가, 어떤 증거로 확정했는가"가 중요하다. 코드는 snapshot의 freshness와 redemption liability를 함께 검증해야 한다.
백엔드NAV snapshot 발행 전 검증
type NavInput = { asOf: Date; grossAssets: bigint; cashBalance: bigint; pendingRedemptions: bigint; auditorSignature: string;};function buildNavSnapshot(input: NavInput) { if (Date.now() - input.asOf.getTime() > 36 * 60 * 60 * 1000) { throw new Error("NAV snapshot is stale"); } const netAssets = input.grossAssets + input.cashBalance - input.pendingRedemptions; if (netAssets <= 0n) { throw new Error("NAV must stay positive"); } return { asOf: input.asOf.toISOString(), netAssets, auditorSignature: input.auditorSignature };}이 함수는 회계 입력을 그대로 믿지 않는다. 발행 시간이 너무 오래됐거나 redemption liability가 반영되지 않은 NAV는 share 가격을 왜곡한다.
운영redemption liability 대조 쿼리
select epoch, sum(requested_shares) as requested_shares, sum(quoted_assets) as quoted_assets, sum(claimed_assets) as claimed_assets, sum(quoted_assets) - sum(claimed_assets) as unpaid_liabilityfrom redemption_requestswhere status in ('quoted', 'claimable', 'claimed')group by epochorder by epoch desc;이 쿼리는 "환매 요청이 얼마 남았는가"를 dashboard에 올리기 위한 최소 단위다. vault가 충분한 reserve를 갖고 있는지는 token balance가 아니라 unpaid liability와 함께 봐야 한다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| NAV 시점 | NAV timestamp와 update authority가 명확한가 | NAV evidence record |
| 유동성 | cash, T-bill maturity, tokenized asset liquidity를 구분했는가 | liquidity bucket table |
| 상환 queue | 선착순, pro-rata, gate, manual review 정책이 있는가 | redemption queue model |
| 손실 정책 | NAV 하락 또는 haircut을 누가 부담하는가 | loss allocation memo |
| 대시보드 | supply, reserve, redemption, liquidity를 함께 보여주는가 | dashboard metric spec |
실무 예시
사용자가 100,000 stablecoin을 fiat로 상환 요청했다고 가정한다. token burn transaction은 완료됐지만 fiat rail이 지연될 수 있다. 이때 사용자에게는 "상환 완료"가 아니라 "onchain burn 완료, fiat 지급 대기"로 보여야 한다.
| 상태 | 사용자 문구 | 운영 확인 |
|---|---|---|
Requested | 상환 요청이 접수됐습니다 | requestId, amount |
KycReview | 자격 및 제재 검토 중입니다 | KYC/KYT result |
BurnPending | token burn을 준비 중입니다 | burn transaction planned |
Burned | onchain burn이 완료됐습니다 | burnTx, block |
FiatPending | fiat 지급을 처리 중입니다 | bank rail status |
Delayed | 유동성 또는 지급망 지연이 있습니다 | delay reason, owner |
Completed | fiat 지급이 완료됐습니다 | payout reference |
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| NAV가 충분하면 상환 가능성도 충분하다고 본다. | NAV와 same-day liquidity는 다른 지표다. |
| burn이 끝나면 redemption도 끝난다고 본다. | fiat rail과 bank settlement가 별도 상태로 남는다. |
| reserve asset을 하나의 숫자로만 본다. | cash, T-bill, MMF, tokenized asset, maturity bucket을 분리해야 한다. |
| queue 정책을 운영자가 임의로 처리하면 된다고 본다. | 선착순, pro-rata, gate, manual review 기준이 문서화되어야 한다. |
| stress discount를 dashboard 밖에 둔다. | liquidity stress는 stablecoin peg와 redemption confidence에 직접 영향을 준다. |
실습 과제
- 준비자산, NAV, 상환 운영 이해 점검: 세 장부의 필드와 source of truth를 각각 5개 이상 작성한다.
- redemption queue 모델 작성: Requested, KycReview, BurnPending, Burned, FiatPending, Delayed, Completed, Rejected 상태와 전환 조건을 설계한다.
- 대시보드 지표 설계: NAV timestamp, cash bucket, same-day liquidity, pending redemption, oldest request age, stress discount, reserve source freshness 등 10개 지표를 정의한다.
- loss allocation memo 작성: NAV 하락, liquidity haircut, delayed redemption이 발생할 때 issuer, holder, merchant 중 누가 어떤 위험을 부담하는지 적는다.
완료 기준
- NAV와 유동성 차이를 설명했다.
- redemption queue 모델을 만들었다.
- 대시보드 지표를 정의했다.
근거 자료
- 준비자산 NAV 상환: 04-RWA-토큰화/04-준비자산-NAV-상환.md