개요 & 아키텍처
대부분 구현 완료, 배포/QA 남음
이 페이지는 v3.0 아키텍처를 설명한다. 컨트랙트, DB 스키마, 백엔드 Lambda, 양쪽 프론트엔드까지 대부분 구현돼 있고 남은 일은 배포와 QA다(마이그레이션 현황 참조). v2.x 아키텍처(AS_POOL/FUND_POOL 바이너리 모델)는 폐기됐다.
Aset은 기관급 RWA 토큰화 플랫폼이다. 투자자가 실물자산(인보이스 파이낸싱, 임금 선지급, 사모 크레딧)을 기초로 하는 풀에 스테이블코인을 예치하고, LP 토큰을 통해 수익을 받는다.
비수탁 아키텍처
투자자 자금은 전부 Pool 스마트 컨트랙트를 통해 흐른다. Aset은 컨트랙트의 operator 역할을 가진 중개자로 동작할 뿐, 투자자 자금을 직접 보관하지 않는다. 따라서 MiCA 기준 VASP 라이선스가 필요 없다(15만 유로 자본금 요건 회피). Ondo, Centrifuge, Maple 모두 같은 모델을 쓰는 업계 표준이다.
v3.0 모델: 설정으로 정의되는 풀
v2.x에서 풀은 AS_POOL(Aset 운영)과 FUND_POOL(FM 운영) 두 가지 타입뿐이었다. 운영 방식이 서로 다른 파트너(Joob, LINE BK, 앞으로 들어올 오리지네이터)를 온보딩하면서, 고정 타입 대신 차원 기반 설정으로 옮겼다. 이제 각 풀은 약 24개의 독립적인 설정값으로 정의된다.
핵심 원칙:
- 비수탁: Aset은 자금을 보관하지 않고, 컨트랙트 코드만 자금을 움직일 수 있다
- LP는 항상 Aset이 발행: LP 토큰 컨트랙트 하나가 모든 풀의 투자자 포지션에 대한 단일 기준이다(파트너에게는 API로 통지)
- Reserve와 Tranche는 별개: Reserve(유동성 버퍼)와 Junior 트랜치(손실 흡수)는 목적이 다르다. reserve는 손실 계층이 아니다. 단독 풀의 first-loss는 매니저 equity 버퍼이고, 그룹으로 묶인 풀은 Junior가 맡는다(R8)
전체 차원 목록은 풀 모델 참조.
v3.0 주요 변경점: v2.x에서 무엇이 바뀌었나
v3.0 설계 결정 요약
10개 결정 전문은 결정 → v3.0 Decisions에 있다. 아래는 요약이다.
| # | 변경 | 이유 | 상세 |
|---|---|---|---|
| v3-01 | pool_type 바이너리를 약 24개 직교 차원으로 대체 | Joob/LINE BK 온보딩에서 바이너리가 너무 뻣뻣하다는 게 드러남 | 풀 모델 |
| v3-02 | LP는 항상 플랫폼 발행(FUND_ISSUED 폐기) | 모든 풀의 포지션에 대한 단일 기준을 확보 | 핵심 개념 |
| v3-03 | PlatformReceiptNFT 제거, 입금이 atomic으로 처리됨 | LP 자체가 입금 증빙이므로 D+7 환불 창이 필요 없음 | 스마트 컨트랙트 |
| v3-04 | 상환: FM_ACCEPTED 대신 PENDING_RESERVE | 파트너의 행동은 워크플로 단계가 아니라 상태임 | 상태 머신 |
| v3-05 | 2단계 정지: is_paused(soft) + is_emergency_frozen(hard) | soft pause는 입금만 막고, freeze는 전부 멈춤 | 풀 모델 → 운영 |
| v3-06 | 긴급 청산(60+30일 타임락) | 응답 없는 파트너에 대한 회수 경로. 온체인에서 회수 가능한 것은 Pool 컨트랙트가 들고 있는 몫뿐(보통 reserve 약 10%) | 풀 모델 → Wind-Down |
| v3-07 | collateral_type enum을 collateral_description 텍스트 + collateral_ratio로 대체 | 실제 담보 구조는 3개 버킷에 안 들어감 | 핵심 개념 |
| v3-08 | nav_data_source 차원 | v3-15로 대체됨. 처리 경로를 하나로 통일하면서 이 차원은 제거 | [아래 v3-15] |
| v3-09 | tranche_structure 차원 | v3-14로 대체됨. 트랜치는 풀 하나에 LP 둘이 아니라, 연결된 SINGLE 풀들로 표현 | [아래 v3-14] |
| v3-10 | 풀별 KYC: kyc_level_required + jurisdiction_whitelist | 풀마다 KYC/KYB 요건이 다름(기관 전용, 지역 제한 등) | KYC & 신원 |
| v3-11 | PlatformEscrow를 PlatformPool로 흡수(5개에서 4개 컨트랙트로) | 10/90 분리를 인라인화. 입금이 atomic이라 관심사 분리로 얻는 게 없었음 | 스마트 컨트랙트 |
| v3-12 | wind-down을 NAV 메커니즘으로 통합하고 IMPAIRED 상태 추가 | 수식은 동등하고, Maple식 중간 상태를 두면 terminal wind-down까지 가지 않고도 입금을 멈출 수 있음 | 상태 머신, Writedown & NAV |
| v3-13 | Joob DPD API 기반 NAV writedown 자동화(OJK 스케줄) | Joob이 이미 대출별 DPD를 제공함. OJK의 5/15/50/100% 스케줄을 대출별로 적용해 NAV로 집계 | Writedown & NAV, Joob 풀 설정 |
| v3-14 | 연결된 SINGLE 풀로 트랜치 구현(v3-09 대체). tranche_group_id + tranche_role 컬럼을 쓰고 워터폴은 Aset Lambda가 적용 | 풀 하나에 LP 둘 패턴은 컨트랙트만 복잡해지고 강제력은 안 늘어남(v3-15에서 어차피 Aset Lambda가 NAV를 통제). 두 풀 패턴이 더 단순하고 3단(Senior/Mezz/Junior)도 지원 | 풀 모델 → Tranche Group |
| v3-15 | PARTNER_REPORTED 폐기(v3-08 대체). NAV는 항상 Aset이 처리 | 트랜치 워터폴(v3-14)과 상각 스케줄(v3-13)을 강제하려면 필요. 그냥 미러링만 하면 두 보장이 깨짐 | Writedown & NAV |
| v3-16 | reserve 소진을 updateNAV(newNav, reserveConsumed) 안으로 통합해 atomic 처리 | Lambda 호출 1회, 레이스 없음, 별도 consumeReserveForLoss()보다 감사 추적이 깔끔함. 단, "손실 흡수" 쪽 절반은 R8에서 폐기됐다. reserve는 상환 유동성이고 reserveConsumed는 이제 항상 0이다. atomic 처리 근거와 ABI는 그대로 유효 | 스마트 컨트랙트, Writedown & NAV |
| v3-17 | 크로스-VASP KYC: 파트너가 SumSub를 쓰면 SumSub Reusable KYC, 아니면 재방문 유저 플로우로 빠른 재KYC | Tokocrypto급 세컨더리 마켓 제휴는 규제 준수를 유지하면서도 온보딩 마찰이 낮아야 함 | KYC & 신원 |
| v3-18 | 온체인 설정은 최소한으로 두되 KYC 컴플라이언스는 온체인에서 강제 | 허가형 플랫폼이라 투자자는 Aset을 운영 주체로 신뢰한다. 규제상 물러설 수 없는 KYC 레벨과 관할만 온체인에 두고 나머지 설정은 DB에 | 스마트 컨트랙트 |
Phase 2.5: 통합 홀더 검증(5-State 모델)
v3.0 위에 얹는 5-State 홀더 모델(A: 검증된 투자자, B: 검증됐으나 이력 없음, C: 미검증 홀더, D: 신원만 확인, E: 미등록)은 읽기 전용, 실제 투자, 세컨더리 마켓 시나리오를 하나의 상태 머신으로 통합한다. 투자자는 SBT 민팅, RPS 전송, 플랫폼 입금을 통해 상태 사이를 이동한다. → 홀더 검증
v3.0에서 함께 통일된 것
- 수익 모델: 모든 풀이 claim 기반 수동 트리거(
yield_trigger = MANUAL)를 쓴다. 자동 분배는 제거됐다 - 에스크로: 항상
SMART_CONTRACT(레거시MULTI_SIG/NO_ESCROW제거) - 풀별 reserve:
reserve_bps(기본 1000 bps = 10%). Junior 트랜치와는 다른 개념이다 - 리스크 투명성:
risk_tier를 없애고 데이터 항목(collateral_*,apy_disclosure,tranche_structure등)으로 대체
기술 스택
| 레이어 | 스택 | 상세 |
|---|---|---|
| 프론트엔드 | Vite + React + TypeScript | React Router · Tailwind 4 · RainbowKit · shadcn/ui |
| 백엔드 | AWS CDK + Lambda (Node.js) | API Gateway v2 · CloudFront · Supabase JS |
| 스마트 컨트랙트 | Foundry + Solidity | OpenZeppelin · 컨트랙트 4개(PlatformReceiptNFT와 PlatformEscrow 제거) · 멀티체인 |
| 데이터베이스 | Supabase (PostgreSQL + RLS) | 호스팅형 · Row-level security · supabase-js |
| 체인 | Ethereum + Base + Kaia | SIWE 인증 · wagmi + viem |
| 인증(투자자) | SIWE (Sign-In with Ethereum) | jose로 JWT 발급 · RainbowKit · 30분 타임아웃 |
| 인증(어드민) | Google OAuth + 멀티시그 | admin_users.email은 Google에서 · 중요한 어드민 작업은 멀티시그 지갑 |
체인 배포
v3.0은 서로 다른 네트워크를 쓰는 파트너를 지원하려고 멀티체인 배포를 쓴다.
| 환경 | 체인 | 비고 |
|---|---|---|
| Dev | Base Sepolia, Ethereum Sepolia | 개발·스테이징용 테스트넷 |
| Prod | Ethereum Mainnet(Joob 파트너), Base Mainnet(기본값), Kaia(기존 Joob 보유분) | 풀별 chain_id 설정 |
각 풀은 자기 chain_id 차원이 지정한 체인에 배포된다. 스테이블코인 주소는 체인별로 STABLECOIN_ADDRESSES[chainId][symbol]에서 해석한다.
스마트 컨트랙트 레지스트리 (v3.0)
활성 컨트랙트 4개다. v2.x의 6개에서 Receipt NFT가 v3-03으로, Escrow가 v3-11로 빠졌다.
| 컨트랙트 | 표준 | 역할 |
|---|---|---|
| PlatformPool | AccessControl + ReentrancyGuard | 핵심 컨트랙트. 입금, reserve 관리, LP 민팅, 수익 분배, 상환, NAV 갱신, wind-down을 담당한다. 모든 풀이 같은 플로우를 쓰고 설정만 다르다. |
| PlatformLPToken | ERC-20 + AccessControl | LP 토큰. 세컨더리 전송은 허가 없이 가능하며 pause만 게이트로 작동한다(검증은 전송이 아니라 입금·상환 시점에 강제. v3-58). 수익 자동 정산 포함. 풀당 항상 1개다(v3-14에서 트랜치 상품은 각자 LP를 가진 여러 풀을 연결하는 방식이지, 풀 하나에 LP 둘이 아니다). |
| PlatformPoolFactory | Factory + Registry | 팩토리와 온체인 레지스트리를 겸한다. createPool(config)이 Pool과 LPToken을 배포한다. poolCounter 하나로 관리하고, 배포 시점에 차원 값을 검증한다. |
| PlatformKYCSoulbound | 전송 불가 ERC-721 | SumSub 기반 온체인 KYC/KYB 상태. 풀별이 아니라 전역 컨트랙트다. INDIVIDUAL/INSTITUTION 레벨, 미국인 여부 확인, 만료, 취소를 지원한다. |
| — | v3.0에서 제거(v3-11). PlatformPool로 흡수됐다. USDC는 Pool이 직접 보관하고, 10/90 reserve 분리는 atomic 입금 안에 인라인됐다. | |
| — | v3.0에서 제거. LP 토큰 자체가 입금 증빙이다. |
함수 목록, 역할, 아키텍처 다이어그램은 스마트 컨트랙트 참조.
마이그레이션 현황
v3.0 설계는 끝났고 구현도 대부분 됐다. 남은 일은 스펙이 아니라 배포와 QA다.
| 구성요소 | 상태 |
|---|---|
| 스펙(문서 사이트) | 최신(2026-08-06 확인) |
| DB 스키마(신규 차원 컬럼) | 구현 완료. 마이그레이션 0126까지 dev에 적용됐고 prod 배포는 대기 중. 개수와 마이그레이션별 상세는 11-db-schema |
| 스마트 컨트랙트(PlatformReceiptNFT 제거, 신규 함수) | 구현 완료. 이 스펙과 일치 |
| 백엔드 Lambda(차원 기반 분기) | 구현 완료. 핸들러 약 128개 / 라우트 129개 / 스케줄러 15개 |
| 프론트엔드(풀 생성 UI가 차원을 사용) | 구현 완료. 투자자 앱과 어드민 앱 모두(어드민 생성 폼 입력 일부는 아직 API 전용, QA 대기) |
알려진 미완: DPD에서 OJK NAV writedown으로 이어지는 자동화(v3-13). Writedown & NAV와 Joob 풀 설정 참조.
구현 진행 상황은 Phase 1.5 계획(내부 문서)에서 추적한다.