02 · 핵심 개념
이전 장에서는 Project RWA의 목적과 연동 수준을 설명했습니다. 이 장에서는 하나의 자산과 한 명의 투자자를 기준으로 이후 프로세스에서 사용하는 핵심 객체를 설명합니다.
2.1 Token: 자산 지분
각 RWA 자산에는 독립된 ERC-3643 Token이 있습니다. 일반적인 ERC-20 인터페이스를 지원합니다.
name / symbol / decimals
totalSupply / balanceOf
transfer / approve / transferFrom
Transfer / Approval
투자자 자격 검사, 컴플라이언스 규칙 검사, pause와 freeze, Agent의 mint·burn·강제 이전, 분실 지갑 복구 기능도 추가합니다. 잔액이 충분하더라도 전송이 항상 성공하는 것은 아닙니다.
금액은 온체인 정수로 저장됩니다.
온체인 amount = 표시 수량 × 10^decimals
PRWA의 decimals는 6이므로 1 PRWA = 1,000,000입니다. 다른 자산 연동 시 반드시 decimals()를 동적으로 호출하십시오.
2.2 지갑: 서명과 자산 보유
투자자 지갑은 트랜잭션 서명, gas 지불, Token 보유, ONCHAINID 제어에 사용하는 EOA 주소입니다.
지갑 자체에는 KYC 결론이 저장되지 않습니다. 보유 자격은 지갑과 연결된 ONCHAINID 및 대상 자산의 IdentityRegistry로 판단합니다.
2.3 ONCHAINID: 투자자의 온체인 신원
ONCHAINID는 스마트 컨트랙트 주소이며 일반 지갑이 아닙니다.
| 항목 | 지갑 | ONCHAINID |
|---|---|---|
| 유형 | EOA | 스마트 컨트랙트 |
| 주요 용도 | 서명, gas 지불, Token 보유 | 신원 키와 Claim 관리 |
| KYC 평문 직접 저장 | 저장하지 않음 | 저장하지 않아야 함 |
| 생성 진입점 | 지갑 도구 | ONCHAINID Gateway |
일반적으로 투자자는 ONCHAINID Gateway.deployIdentityForWallet(wallet)을 호출합니다. IdFactory.getIdentity(wallet)로 연결된 신원의 존재 여부를 확인할 수 있습니다.
2.4 Claim: 기관이 서명한 자격 결론
Claim은 자격 발급 기관이 해당 신원이 조건을 충족한다고 확인했음을 나타냅니다.
| 필드 | 의미 |
|---|---|
topic | KYC 승인 같은 자격 유형 |
scheme | 서명 방식 |
issuer | ClaimIssuer 컨트랙트 |
signature | 자격 기관이 생성한 서명 |
data | 서명 대상 자격 데이터 |
uri | 선택적 오프체인 참조 |
형성 과정은 두 단계입니다.
- 자격 기관이 오프체인에서 심사하고 서명을 생성합니다.
- 투자자가 서명과 Claim 필드를 본인의 ONCHAINID에 기록합니다.
서명은 기관이 생성하며 온체인 addClaim 트랜잭션은 일반적으로 투자자가 실행하고 gas를 지불합니다. 이름, 신분증 번호, 주소, 이미지 같은 평문 자료를 Claim에 넣지 마십시오.
2.5 ClaimIssuer: 자격 발급 기관
ClaimIssuer는 자산이 승인하는 자격 기관을 나타내며 오프체인 KYC/AML 심사, Claim 서명, 필요 시 자격 취소, 서명 키 보호를 담당합니다.
일반 애플리케이션이 생성한 서명은 자동으로 승인되지 않습니다. 대상 자산은 TrustedIssuersRegistry에 ClaimIssuer를 등록하고 대상 Topic 발급 권한을 부여해야 합니다.
2.6 IdentityRegistry: 자산별 자격 진입점
Claim을 ONCHAINID에 기록한 후 투자자를 대상 자산의 IdentityRegistry에 등록해야 합니다.
contains(wallet): 지갑 등록 레코드 존재 여부.isVerified(wallet): 대상 자산의 현재 요건을 모두 충족하는지 여부.
등록 상태만으로 유효한 자격이 보장되지는 않습니다. 외부 애플리케이션은 isVerified를 최종 판단으로 사용하십시오.
2.7 자격이 자산에 연결되는 이유
하나의 ONCHAINID는 여러 자산에서 사용할 수 있습니다. Claim 재사용 가능 여부는 같은 Topic과 ClaimIssuer를 승인하는지에 따라 결정되며 registerIdentity는 자산별 Registry에서 실행합니다. 자격 조회 전에 Token.identityRegistry()로 올바른 Registry를 찾으십시오. 자산 A의 자격 승인은 자산 B의 승인을 의미하지 않습니다.
2.8 ModularCompliance: 거래 규칙
IdentityRegistry는 지갑의 보유 가능 여부를, ModularCompliance는 거래 실행 가능 여부를 판단합니다. 모듈은 국가·지역 허용 목록, 주소별 보유 한도, 총공급 한도, 락업 기간, 투자자 유형, 전송 한도 등을 표현할 수 있습니다.
대상 자산의 온체인 설정과 공개 문서를 사용하고 다른 자산의 규칙을 근거로 추정하지 마십시오.
2.9 전송의 전체 검사
부분 freeze의 경우:
사용 가능 잔액 = balanceOf(wallet) - getFrozenTokens(wallet)
2.10 Suite: 자산 하나의 컨트랙트 집합
| 컨트랙트 | 역할 |
|---|---|
Token | 자산 지분 및 보유자 작업 |
IdentityRegistry | 지갑의 보유 자격 판단 |
IdentityRegistryStorage | 지갑, 신원, 국가 코드 매핑 저장 |
ClaimTopicsRegistry | 필수 자격 Topics 저장 |
TrustedIssuersRegistry | 승인된 ClaimIssuers 저장 |
ModularCompliance | 거래 규칙 조합 |
외부 애플리케이션은 주로 Token과 IdentityRegistry를 사용합니다.
2.11 프록시 주소
공개 주소표의 프록시 주소를 저장하고 구현 컨트랙트를 비즈니스 주소로 사용하지 마십시오.
2.12 ERC-3643 규약 및 용어
| 항목 | 설명 |
|---|---|
| T-REX | ERC-3643 참조 구현 체계. 한 자산의 관련 컨트랙트 집합이 Suite |
| Topic | 프로토콜은 1 = KYC를 고정하지 않음. 각 프로젝트가 이름, 값, 버전 공개 |
| 국가 코드 | uint16, 일반적으로 ISO 3166-1 numeric 사용. 중국 156, 싱가포르 702 |
| IR / IRS | IdentityRegistry / IdentityRegistryStorage |
| CTR / TIR | ClaimTopicsRegistry / TrustedIssuersRegistry |
| MC | ModularCompliance |
| IA | Implementation Authority. 프록시가 사용하는 구현 버전 진입점 |
체인에는 자격 결론, 주소 매핑, 자산 잔액, 규칙 파라미터를 저장합니다. 이름, 신분증 번호, 사진 같은 KYC 평문은 저장하지 않습니다.
2.13 다음 장
다음 장에서는 각 객체를 전체 시스템에 배치하고 플랫폼 공유 컨트랙트, 자산별 컨트랙트, 각 역할의 책임을 설명합니다.