Anchorpoint / HSBC
Role: ISSUER。原文ではissuerがstablecoinを作成し、各coinがreal moneyまたはsafe assetsでbackedされると約束する主体として説明されています。
Source-preserving summary
RWA Flow - SCB / Libeara
DPM clientがcustodian経由でHKD stablecoinを受け取り、AxialがAHKDをUSDCへswapし、LibearaのRWA platformからRWAを取得して顧客custodian account / walletへ反映する図解フローの日本語要約です。
SCB
Anchorpoint
AHKD
USDC
Libeara
出典ノート
Source PDF: rwa/RWA Flow - SCB 2 June.pdf
Extracted text: docs/extracted_text/rwa_RWA_Flow_-_SCB_2_June.pdf.txt
このページは抽出テキストに含まれる図解の順序・登場人物・処理を保った要約です。外部Web情報は使っていません。
図の全体像
原文図は、左側にstablecoin発行・custodyの役割、中央にDigiClassが担うWeb3 / infrastructure領域、右側にRWA platformと顧客custodian account / walletを置いています。図中には「ALL WEB3 AND INFRASTRUCTURE BY DIGICLASS」と明記され、AxialがUSER - Orchestratorとしてstablecoin取得、swap、RWA購入、顧客口座反映を実行する流れになっています。
解説: ここでの「orchestrator」は、資産を自ら発行する主体というより、銀行、issuer、custodian、stablecoin、RWA provider、顧客口座をつなぐ実行・照合・指示レイヤーとして読むのが自然です。
Name / Role / Action or Description
SCB Bank / HSBC Bank
Role: CUSTODIAN。原文では、stablecoinを裏付けるreal moneyまたはassetsを安全に保管する主体として説明されています。
Axial
Role: USER - Orchestrator。AHKDのrequest、receipt、USDCへのswap、RWAへのswap、customer custodian accountへの配置を担う流れです。
Libeara
Role: Interface Libeara RWA Platform。AxialがUSDCをRWAにswapする際のRWA供給元として図示されています。
Bank Customer / DPM Client
伝統的なDPM clientとして開始し、最終的にはcustodian account / walletにassetを保有する顧客として描かれます。
Step 1: DPM client instruction
最初の処理は「Instruction - DPM (Traditional) Client Custodian pay into HKD Stablecoin Custodian」です。つまり、bank customer / DPM client側からcustodianに対して、HKD stablecoin custodianへfiatを支払う指示が出る構成です。
この段階では、顧客はまだ伝統的なDPM clientとして扱われ、on-chain assetへの変換は後続のissuer / custodian / orchestrator処理に委ねられます。
Step 2: Request stablecoin / Pay fiat
Step 2では、stablecoinのrequestとfiat paymentが発生します。Issuerはstablecoinを作成し、各coinがreal moneyまたはsafe assetsに裏付けられていると約束します。Custodianは、その裏付けとなるreal moneyまたはassetsを安全に保管します。
解説: この図ではissuerとcustodianの役割が分かれています。issuerはtokenを発行し、custodianは裏付け資産を保管します。DigiClass / Axial側はその前提の上でWeb3実行フローを組み立てる位置づけです。
Step 3: Delivery HKD Stablecoin
Step 3では、HKD stablecoinがdeliveryされます。AxialはAHKDをrequestし、AHKDをreceiveします。その後、AHKDをUSDCへswapし、USDCを保有した状態になります。
このstablecoin受領後の一連の処理は、図中で「ALL WEB3 AND INFRASTRUCTURE BY DIGICLASS」の範囲に置かれています。DigiClassの実装範囲として、request、receipt、swap、RWA acquisition、custodian account reflectionまでの操作・状態管理・照合が含まれる読み方になります。
RWA取得と顧客口座への反映
- Requests AHKD
AxialがHKD stablecoinであるAHKDを要求する。 - Receives AHKD
AxialがAHKDを受領する。 - Swaps AHKD to USDC
AHKDをUSDCへswapし、RWA購入に使うstablecoinへ変換する。 - Swaps for RWA
USDCを使ってRWAにswapする。 - Supplied RWA by Libeara
RWAはLibeara RWA Platformから供給される。 - Places into customer Custodian acct
取得したRWAをcustomer custodian accountに配置する。 - Holds Asset in Custodian acct/WALLET
Bank customer / DPM clientは最終的にcustodian accountまたはwalletでassetを保有する。
判断点・設計上の意味
FiatからAHKDへの境界
顧客指示、fiat payment、issuer mint、custodian reserveの対応関係を照合する必要があります。
AHKDからUSDCへのswap
為替・流動性・slippage・取引先・実行時刻・手数料をどう記録するかが設計論点です。
USDCからLibeara RWAへのswap
RWA platform上のsubscription / purchase条件、投資家適格性、取引単位、settlement statusを確認する必要があります。
Custodian account / wallet反映
顧客の法的保有、DPM報告、残高照合、statement、redemption時の戻し経路を設計する必要があります。
未解決の前提・確認質問
図からは、AHKDの正確なissuer、custodian、mint/burn条件、USDC swap venue、Libeara側の商品名・法的権利、顧客walletとcustodian accountのどちらが正式な記録か、RWA取得後のvaluation / redemption / income distributionの処理が未確定です。実装前に個別契約・API・操作権限・照合ルールで確認する必要があります。