SettleLab
전체 코스
LESSON 05RWA Tokenization

RWA 실무 체크리스트

심화35분근거 2

학습 결과

  • RWA 도입 체크리스트를 due diligence 문서로 만든다.
  • 스테이블코인 준비자산과 RWA 볼트를 비교한다.

선행 조건

  • 준비자산, NAV, 상환 운영

완료 기준

  • 핵심 체크 항목 12개를 작성했다.
  • 외부 지표 출처를 기록했다.
  • 캡스톤 비교 항목을 정했다.

RWA 실무 체크리스트

도입

RWA 도입 검토는 "이 토큰이 인기 있는가"가 아니라 "이 토큰을 제품, 준비자산, 담보, 결제 흐름에 넣어도 운영 가능한가"를 판단하는 일이다. ERC-4626 share, ERC-7540 request, ERC-3643 identity, NAV/redemption ledger를 모두 본 뒤에야 Go/No-Go 결론을 낼 수 있다.

이 레슨은 체크리스트를 due diligence packet으로 바꾸는 강의다. 단순 체크박스가 아니라 항목마다 evidence, owner, freshness, blocker 여부를 기록한다.

학습 목표

  • RWA 도입 체크리스트를 due diligence 문서로 만든다.
  • 스테이블코인 준비자산과 RWA 볼트를 비교한다.

개념 설명

판단 트리가로 스크롤 · 크게 보기 지원
RWA 실무 체크리스트 판단 트리이 시각화는 RWA vault와 redemption 운영에서 진행, 보류, 재설계 결정을 가르는 질문이 무엇인지를 보여주며, 'RWA 실무 체크리스트'에서 남겨야 할 설계 증거를 좁힌다.
시작 질문

RWA 실무 체크리스트를 제품 설계에 넣어도 되는가?

진행

share와 asset 권리가 분리되는가

RWA 실무 체크리스트 이해 점검
보류

비동기 상환 상태가 보이는가

가정과 실패 상태를 보강한다.
차단

permission rule이 기록되는가

캡스톤 risk register에 차단 사유를 남긴다.
크게 보기
시작 질문

RWA 실무 체크리스트를 제품 설계에 넣어도 되는가?

진행

share와 asset 권리가 분리되는가

RWA 실무 체크리스트 이해 점검
보류

비동기 상환 상태가 보이는가

가정과 실패 상태를 보강한다.
차단

permission rule이 기록되는가

캡스톤 risk register에 차단 사유를 남긴다.

Due diligence packet은 네 영역으로 구성한다.

표 자료가로 스크롤 · 크게 보기 지원
영역핵심 질문최소 증거
Vaultunderlying asset, share/asset, totalAssets, preview, rounding이 명확한가ERC-4626 function review, conversion tests
Asyncdeposit/redeem이 즉시 처리되는지 request 기반인지 구분했는가request lifecycle, stuck request runbook
Permissioned tokenholder eligibility와 claim lifecycle이 설계됐는가identity registry, compliance rule, revocation policy
ReserveNAV, liquidity, redemption, disclosure를 분리했는가NAV source, liquidity bucket, redemption queue
크게 보기
영역핵심 질문최소 증거
Vaultunderlying asset, share/asset, totalAssets, preview, rounding이 명확한가ERC-4626 function review, conversion tests
Asyncdeposit/redeem이 즉시 처리되는지 request 기반인지 구분했는가request lifecycle, stuck request runbook
Permissioned tokenholder eligibility와 claim lifecycle이 설계됐는가identity registry, compliance rule, revocation policy
ReserveNAV, liquidity, redemption, disclosure를 분리했는가NAV source, liquidity bucket, redemption queue

각 항목은 아래 형식으로 작성한다.

CODE SURFACEtext
Check:Evidence:Owner:Freshness:Blocker if missing:Capstone link:

외부 대시보드 지표를 사용할 때는 숫자를 고정하지 않는다. DefiLlama RWA나 RWA.xyz 같은 dashboard는 issuer, asset group, access model, market size 같은 비교 지표를 제공하지만 수치는 계속 변한다. 수치를 인용한다면 접근일, URL, 갱신 주기, 사용 목적을 함께 남긴다.

코드로 확인하기

RWA 체크리스트는 문서로 끝나면 운영력이 생기지 않는다. launch 전에는 정책 항목을 기계가 읽을 수 있는 형태로 만들고, 누락된 조건을 배포 gate에서 막아야 한다.

운영launch gate 체크리스트

CODE SURFACEyaml
vault_launch_gate:  nav:    fresh_within_hours: 36    auditor_signature_required: true  redemption:    queue_enabled: true    unpaid_liability_dashboard: true  compliance:    identity_registry_connected: true    freeze_runbook_reviewed: true  operations:    custodian_report_schedule: daily    incident_owner: rwa-ops-lead

YAML은 보고서가 아니라 배포 전 검수 기준이다. 각 항목은 dashboard, contract config, 운영 담당자 중 하나의 증거로 연결되어야 한다.

백엔드gate 실패 항목 수집

CODE SURFACEtypescript
type LaunchGate = {  navFresh: boolean;  auditorSignature: boolean;  redemptionQueue: boolean;  identityRegistry: boolean;  freezeRunbook: boolean;};function findLaunchBlockers(gate: LaunchGate) {  return Object.entries(gate)    .filter(([, passed]) => !passed)    .map(([name]) => name);}const blockers = findLaunchBlockers({  navFresh: true,  auditorSignature: true,  redemptionQueue: false,  identityRegistry: true,  freezeRunbook: false});

이런 검사는 체크리스트를 "읽었다"에서 "통과했다"로 바꾼다. capstone에서는 blocker가 0개가 되기 전까지 launch-ready로 표시하지 않는다.

강의 포인트

표 자료가로 스크롤 · 크게 보기 지원
관점확인할 질문증거로 남길 것
asset typetokenized treasury, MMF, private credit, commodity 중 무엇인가asset classification
issuer/custodian누가 발행하고 누가 보관하는가issuer/custodian evidence
valuationNAV 산정 방식과 update authority가 명확한가valuation policy
redemption즉시, request 기반, gate, manual review 중 무엇인가redemption policy
eligibility누가 보유/이전할 수 있는가eligibility matrix
dashboard source외부 지표를 언제 확인했고 어디에 쓰는가source freshness log
크게 보기
관점확인할 질문증거로 남길 것
asset typetokenized treasury, MMF, private credit, commodity 중 무엇인가asset classification
issuer/custodian누가 발행하고 누가 보관하는가issuer/custodian evidence
valuationNAV 산정 방식과 update authority가 명확한가valuation policy
redemption즉시, request 기반, gate, manual review 중 무엇인가redemption policy
eligibility누가 보유/이전할 수 있는가eligibility matrix
dashboard source외부 지표를 언제 확인했고 어디에 쓰는가source freshness log

실무 예시

stablecoin checkout capstone에 "tokenized treasury reserve"를 추가하려 한다고 가정한다. 아래처럼 Go/No-Go를 판단한다.

표 자료가로 스크롤 · 크게 보기 지원
항목Go 기준No-Go 조건
Assetunderlying이 단기 국채 또는 현금성 자산으로 명확하고 source가 있다asset composition이 불명확함
Vaultshare/asset conversion과 rounding test가 있다preview와 execution 차이를 설명하지 못함
Redemptionqueue, cutoff, claimable state, stuck request 처리 기준이 있다즉시 상환 가능처럼 표시하지만 실제는 비동기
Permissionissuer와 product contract가 eligible holder가 될 수 있다compliance restriction 때문에 liquidation route가 없음
ReserveNAV timestamp, liquidity bucket, disclosure source가 있다NAV만 있고 liquidity 지표가 없음
Operationsdashboard alert와 owner가 지정되어 있다stale NAV나 delayed redemption alert가 없음
크게 보기
항목Go 기준No-Go 조건
Assetunderlying이 단기 국채 또는 현금성 자산으로 명확하고 source가 있다asset composition이 불명확함
Vaultshare/asset conversion과 rounding test가 있다preview와 execution 차이를 설명하지 못함
Redemptionqueue, cutoff, claimable state, stuck request 처리 기준이 있다즉시 상환 가능처럼 표시하지만 실제는 비동기
Permissionissuer와 product contract가 eligible holder가 될 수 있다compliance restriction 때문에 liquidation route가 없음
ReserveNAV timestamp, liquidity bucket, disclosure source가 있다NAV만 있고 liquidity 지표가 없음
Operationsdashboard alert와 owner가 지정되어 있다stale NAV나 delayed redemption alert가 없음

흔한 오해와 실패 시나리오

표 자료가로 스크롤 · 크게 보기 지원
오해실제로 확인할 것
RWA market cap이 크면 제품에 넣어도 된다고 본다.market cap보다 holder eligibility, redemption, liquidity, custody가 먼저다.
체크리스트를 채우면 due diligence가 끝났다고 본다.각 항목에는 evidence와 freshness가 있어야 한다.
외부 dashboard 숫자를 고정 사실처럼 쓴다.dashboard 수치는 확인일과 갱신 주기를 함께 기록해야 한다.
permissioned token을 reserve로 넣으면 안전해진다고 본다.liquidation과 secondary market 접근성이 제한될 수 있다.
NAV와 redemption policy를 법무 문서로만 둔다.제품 UI, dashboard, incident runbook에 반영되어야 한다.
크게 보기
오해실제로 확인할 것
RWA market cap이 크면 제품에 넣어도 된다고 본다.market cap보다 holder eligibility, redemption, liquidity, custody가 먼저다.
체크리스트를 채우면 due diligence가 끝났다고 본다.각 항목에는 evidence와 freshness가 있어야 한다.
외부 dashboard 숫자를 고정 사실처럼 쓴다.dashboard 수치는 확인일과 갱신 주기를 함께 기록해야 한다.
permissioned token을 reserve로 넣으면 안전해진다고 본다.liquidation과 secondary market 접근성이 제한될 수 있다.
NAV와 redemption policy를 법무 문서로만 둔다.제품 UI, dashboard, incident runbook에 반영되어야 한다.

실습 과제

  1. RWA 실무 체크리스트 이해 점검: asset type, issuer, custodian, valuation, redemption, eligibility, dashboard source를 포함해 12개 체크 항목을 작성한다.
  2. Due diligence packet 작성: 각 체크 항목에 evidence, owner, freshness, blocker if missing, capstone link를 채운다.
  3. 외부 지표 출처 기록: DefiLlama RWA 또는 RWA.xyz를 볼 때 어떤 지표를 쓰고 숫자를 언제 확인했는지 source log를 만든다.
  4. 캡스톤 비교 항목 정리: stablecoin reserve, ERC-4626 vault, ERC-7540 async vault, ERC-3643 permissioned token을 capstone risk register에 어떻게 연결할지 정한다.

완료 기준

  1. 핵심 체크 항목 12개를 작성했다.
  2. 외부 지표 출처를 기록했다.
  3. 캡스톤 비교 항목을 정했다.

근거 자료

  • RWA 실무 체크리스트: 04-RWA-토큰화/05-RWA-실무-체크리스트.md
  • RWA 대시보드 DefiLlama RWAxyz: 90-출처/원문-노트/RWA-대시보드-DefiLlama-RWAxyz.md
Final checkpoint

읽기를 마쳤다면 여기서 기록한다

아래 버튼은 읽기 진도를 저장한다. 체크리스트, 과제, 랩 산출물은 위 Workbook에서 따로 관리한다.

  • 핵심 체크 항목 12개를 작성했다.
  • 외부 지표 출처를 기록했다.
  • 캡스톤 비교 항목을 정했다.

학습 자료 근거

RWA 실무 체크리스트
이 LMS 레슨의 개념, 예시, 과제 구성을 잡는 데 사용한 근거 문서.
내부 참고 문서
RWA 대시보드 DefiLlama RWAxyz
대시보드 지표와 외부 수치 사용 시 주의점을 구성하는 데 사용.
내부 참고 문서