Off-chain System of Record
投資家、商品、subscription、payment、allocation、redemption、approval、audit eventを管理する中核台帳。
Architecture
エンジニアとして何を作るべきか
この案件の技術要件は、スマートコントラクトを書くことだけではありません。金融商品として状態を正しく保ち、承認・照合・監査・償還まで運用できるシステムが必要です。
基本アーキテクチャ
On-chain Token State
stablecoin transfer、permissioned token、RWA token、wallet activityなどのオンチェーン状態。
Workflow Engine
投資申込から償還までの状態遷移を管理。pending、approved、issued、settled、failedなどを扱う。
Reconciliation Engine
銀行、issuer、custodian、product provider、on-chain state、internal ledgerの差異を検出する。
中核データモデル
Investor
Wallet
Product
Subscription
Payment
Allocation
Holding
TokenTransaction
Distribution
Redemption
Approval
AuditEvent
APIドメイン
| API | 責務 | 注意点 |
|---|---|---|
| Investor API | KYC状態、ウォレット、適格性 | 個人情報とアクセス制御 |
| Product API | 商品条件、利回り、NAV、risk disclosure | 表示情報と承認済み情報の一致 |
| Subscription API | 申込、入金指示、承認状態 | idempotencyと状態遷移 |
| Settlement API | fiat/stablecoin決済、送金検知 | chain confirmations、銀行照合 |
| Issuance API | allocation、mint、beneficial interest反映 | 二者承認、audit trail |
| Redemption API | 償還申請、burn/lock、payout | 順序、失敗時の復旧 |
| Reporting API | 保有、履歴、分配、監査 | DPM・投資家・銀行で粒度が違う |
設計で避けるべき失敗
UIだけ先に作る
金融商品では、法的正本、承認、照合、償還、失敗時処理がないUIはすぐに詰まります。
on-chain残高を正本にする
法的にはcustodianやregistrar recordが正本になる場合があります。どの記録が正かを先に決める必要があります。
例外処理を軽視する
入金額違い、wallet誤り、chain遅延、mint失敗、償還失敗を最初から状態として持つべきです。
監査ログを後付けする
誰が承認し、何を変更し、どの根拠で実行したかを後から復元できる必要があります。