/ Deep Dive2026年4月22日17

XRPL Vault機関の聖杯が、許可制 DeFi として起動した日

Ethereum DeFi は 2020 年に世界を変えたが、機関はそこに入れなかった——身元不明な対向当事者、規制外資産の混入、監査不可能なアドレス、流動性の断片化、ネイティブ FX 不在。この 5 つの壁を、XRPL Vault(MPT · Credentials · Permissioned Domains · Permissioned DEXes)が 1 枚ずつ潰した。Aave / Maker / Morpho との比較、Ripple Prime × RLUSD × Vault の三位一体、そして BNY Mellon 級の機関が最初に使う理由を、図解 5 点で分解する。

XRPL Vault — 機関の聖杯が、許可制 DeFi として起動した日
/ XRPL Vault · Permissioned DeFi Stack
§ 00

なぜ機関は DeFi を『使えなかった』のか

2020 年の「DeFi Summer」以降、Ethereum 上で数千億ドルの流動性が動いた。 だが、その波にほとんど乗れなかったプレイヤーがいる——世界最大の資金源である機関投資家だ。

BNY Mellon の $52 兆、State Street の $44 兆、Vanguard の $10 兆、 Fidelity の $5 兆——彼らが DeFi に入れない理由は、 技術への理解不足ではない。構造的に使えないからだ。

具体的には、次の5 つの壁がある。

/ Fig. A · 5 つの壁 × Vault の解消
01
Wall · 壁
身元不明な対向当事者
Ethereum プールで資金を出し合う相手が匿名。AML / KYC 監査が通らない。
Vault · 解消身元が構造的に保証
Credentials(XLS-70)
発行体・監査人・規制当局が発行した KYC / 適格投資家クレデンシャルを、オンチェーンで保有者に紐付け。
02
Wall · 壁
規制外資産の混入
unregistered securities や tainted token がプールに混入するリスク。一度混入すると法的に洗えない。
Vault · 解消資産プールの純度保証
MPT(XLS-33)の発行体制御
Multi-Purpose Token は発行体が転送ルールを保持。許可された受領者のみが受け取れる設計。
03
Wall · 壁
監査不可能なアドレス
SAS 70 · SOC 2 · SAB 121——外部監査人がオンチェーンアドレスに署名できない。
Vault · 解消監査境界が明示
Permissioned Domains(XLS-80)
許可されたアドレス群が仮想グループを形成。監査範囲が明示的に区切られ、監査人が署名できる。
04
Wall · 壁
流動性の断片化
同じ USDC が Ethereum / Arbitrum / Base / Solana ... 10 チェーンに散らばる。決済確実性が担保できない。
Vault · 解消単一帳簿で全決済
単一チェーン + ネイティブ DEX
XRPL は L2 を持たない。MPT と既存 IOU と XRP がすべて同じ元帳上で決済。バリア不要。
05
Wall · 壁
ネイティブ FX の不在
Aave / Compound / Morpho は USD ベース。EUR · JPY · 貴金属を直接扱えない。機関の為替ヘッジができない。
Vault · 解消FX が構造に内蔵
Permissioned DEXes(XLS-81)+ XRP
XRPL 生まれの Auto-Bridging が、任意のトークン間の FX を XRP 経由で解決。機関向けプールはこれを許可制で運用。
STRUCTURAL TAKEAWAY
5 つの壁はどれも、Ethereum 側の技術的欠陥ではない。「オープンパブリックを前提に設計された DeFi」を「規制下の金融」に載せ直すには、前提そのものを置き換える必要があった——それが Vault。 同じアーキテクチャを Ethereum で実装しようとすると、 ERC-3643(T-REX)や ERC-1400 の拡張で部分的に可能だが、単一帳簿で DEX まで内蔵した設計は XRPL 固有。
XLS-33 (MPT) · XLS-70 (Credentials) · XLS-80 (Permissioned Domains) · XLS-81 (Permissioned DEXes) · 2024-2026

この 5 つの壁は、どれも「オープンパブリックを前提とした DeFi 設計」の 必然的な帰結だった。規制下の金融は、オープンパブリックの正反対の前提で動いている—— 誰が対向当事者か、誰が資産を持っているか、誰に監査責任があるかを 常に明示しなければ、そもそも取引が許されない。

機関が DeFi に入れなかったのは、DeFi が劣っていたからではない。 DeFi がオープンであることが、 機関にとっての決定的な欠陥だったから。

この壁を、XRPL は 2024 〜 2026 年にかけて、1 枚ずつ崩し始めた。 それが XRPL Vault—— 正確には XLS-33(MPT)· XLS-70(Credentials)· XLS-80(Permissioned Domains)· XLS-81(Permissioned DEXes)を組み合わせた「許可制 DeFi 統合パッケージ」の総称だ。

§ 01

XRPL Vault とは何か — 2024 〜 2026 のタイムライン

Vault は単一の機能ではなく、4 つの XLS 規格が積み上がった総合体。 時系列で整理すると、この 24 ヶ月で XRPL が「機関向け OS」に 設計変更されたことが見えてくる。

XLS 規格 · 時系列
  • 2024 Q1 — XLS-33d (Multi-Purpose Tokens): 発行体制御と豊富なメタデータを持つ新トークン形態の提案
  • 2024 Q2 — XLS-70d (Credentials): オンチェーン ID / 資格管理の仕様
  • 2024 Q4 — XLS-80d (Permissioned Domains): 許可されたアドレス群の仮想グループ化
  • 2025 Q1 — XLS-81d (Permissioned DEXes): Domain 内でのみ約定する DEX 仕様
  • 2025 Q2 〜 Q4 — mainnet amendment 段階活性化: 各機能がテストネット → メインネットへ順次 merge
  • 2026 Q1 — 統合運用開始: Ripple Prime が RLUSD 担保の Permissioned Pool を公表

ポイントは、これらの機能がバラバラに動くのではなく、 1 つのスタックとして積まれていることだ。 Ethereum 側では同じような試みが、ERC-3643(T-REX)· ERC-1400 · Verite · Polygon ID 等に分散しており、 統合には複数プロトコルの組み合わせと追加監査が必要だった。 XRPL は最初からレイヤー 1 に内蔵で設計した。

§ 02

MPT — Vault の核心は、新しい「トークン」

Vault 構造の核心は、XLS-33 で導入されたMulti-Purpose Token(MPT)だ。 XRPL には従来から 2 つのトークン形態しかなかった—— ネイティブの XRP、および Trustline 経由の IOU(Issued Currency)

/ Fig. B · Token 3 形態 · MPT が Vault の核心
XRP
Native Asset
IOU
Issued Currency / Trustline
MPT
Multi-Purpose Token · XLS-33
発行主体
なし(プロトコル発行)任意の発行体(信頼線を張った相手のみ保有可)任意 + Credentials 条件を組み込める
メタデータ
最小(ネットワーク手数料 · 流動性のみ)通貨コード 3 文字 + 発行者アドレス豊富なスキーマ(発行条件 · 満期 · 利払い · 償還ルール等)
発行上限
1,000 億固定(burn のみ減少)実質無限(発行体の Trust Lines で管理)発行時に MaximumAmount を設定可(固定・無限のどちらも可)
転送制御
なし(常に自由転送)Freeze / NoRipple 等の限定的制御のみ発行体がルールを保持。Credentials 保有者のみへの限定転送が可能
KYC/AML 統合
なしなし(TrustLine の有無のみ)Credentials ネイティブ統合(KYC Level · 適格投資家 · 地域制限)
典型的な用途
手数料 · ブリッジ · 担保既存ステーブル · FX · IOU 債権RWA · 機関債 · トークン化株式 · 許可制プール
< Vault の核心 >
WHY MPT CHANGES EVERYTHING
従来の XRPL IOU は発行後にルールを変えられない。 一方で Ethereum の ERC-20 は自由すぎて機関が扱えない。 MPT は「発行体が必要な制御だけを保持しつつ、オンチェーンの自由度も残す」中間解。規制準拠のトークン化 RWA がネイティブに乗る最初のフォーマット。

MPT の何が革命的か——3 点に絞ると:

  1. 発行体がルールを保持: 転送条件・受領者制限・償還条件をトークンレベルで定義。 発行後も一定範囲で変更可能。
  2. Credentials 連携: 「このクレデンシャル保有者のみ受領可」という条件が オンチェーンで強制される。オフチェーンのホワイトリスト管理が不要。
  3. 豊富なメタデータ: 満期 · 利払い · 議決権 · 償還手順を発行時に固定。 監査人が契約書を待たずに仕様を読み取れる。
IOU は発行後のルール変更ができない。 ERC-20 はルールを入れる余地がない。 MPT は、その中間解—— 規制準拠のトークン化 RWA がネイティブで乗る最初のフォーマット。

MPT が実装されたことで、XRPL 上で米国債のトークン化 · 機関債の発行 · 議決権制限株 · 許可制ステーブルを、外部コントラクトなしに直接扱えるようになった。 ここが、すべての Vault 機能の土台になる。

§ 03

5 層スタック — 身元・資産・範囲・取引場・運用

Vault の全体像は、5 つの層が 下から順に積み上がった構造として理解するのが一番早い。

/ Fig. C · 許可制 DeFi の 5 層スタック
L4
Vault (Permissioned Pool)Aggregated Feature
機関資金の運用プール
例:Ripple Prime が運用する RLUSD 担保プール
= 機関向けプライベートマーケット
L3
Permissioned DEXXLS-81
許可された参加者間でのみ約定する DEX
例:Domain ID 付きのオーダーのみマッチング
= 会員制取引所(機関相対)
L2
Permissioned DomainXLS-80
許可条件を満たすアドレスの集合
例:「KYC L2 + 適格投資家」クレデンシャルを両方持つアドレスの仮想グループ
= コンプライアンス認定リスト
L1
MPT · Multi-Purpose TokenXLS-33
発行体制御が効く資産
例:トークン化国債 · 制限付き議決権株
= 発行規約を守る Security Token
L0
CredentialsXLS-70
オンチェーンに紐づく身元・資格
例:KYC Level 2 · 適格投資家 · 地域制限 · 認定参加者
= デジタル証明書(発行体が署名)
READ BOTTOM-UP
L0 Credentials身元を、L1 MPT資産を、L2 Domain参加範囲を、L3 Permissioned DEX取引場を、L4 Vault運用を定義する。
Ethereum では L0〜L4 を別々のプロトコル(Verite · ERC-3643 · Aave 等)で組み合わせる必要があった。 XRPL は1 つの元帳に全部内蔵されている。

各層の役割を、機関投資家の視点で読むと:

  • L0 · Credentials: 「自分が誰か」を証明する。KYC プロバイダ · 規制当局 · 発行体が署名する「オンチェーン証明書」。
  • L1 · MPT: 「何の資産を扱うか」を定義する。 債券・株式・ステーブル・RWA すべて。
  • L2 · Permissioned Domain: 「誰と一緒に運用するか」を決める。 「適格投資家 × 米国居住 × KYC L2」といった多条件の交差点。
  • L3 · Permissioned DEX: 「どこで取引するか」。 Domain 内でのみ約定するオーダーブック。流動性は共有されるが、 対向当事者は許可された範囲に限定。
  • L4 · Vault: 「どう運用するか」。 L0〜L3 の制約を満たした機関プールで、 RWA 利回り · FX · 貸出を統合運用。
Ethereum 側で同等のことをやると

ERC-3643 + ERC-1400 + Verite + Aave Arc + Chainlink Proof-of-Reserves の5 プロトコルの組み合わせが必要。監査証跡がプロトコル横断で 分散するため、SOC 2 / SAS 70 の署名範囲を定義することそのものが難しい。

XRPL は同じ機能を1 つの元帳の中に畳んだため、 監査人は「XRPL 上のこの Domain ID」で署名範囲を特定できる。 これが制度側から見たときの決定的な差になる。

§ 04

機関資金のフロー — Prime から Vault まで

ここまでの 5 層が組み合わさって、実際に機関の資金が Vault に入っていくフローは次のようになる。

/ Fig. D · 機関資金が Vault に入るフロー
① 口座開設② ステーブル変換③ 身元認証④ 入庫許可⑤ 運用機関投資家BNY Mellon · State Street · 年金基金 · 保険Ripple PrimeNSCC 0443 · 担保管理RLUSD 取得Big4 監査済み · NY 認可Credentials 受領KYC L2 · 適格投資家 · 地域制限Vault 入庫Permissioned Pool · Domain 内運用・分配RWA 利回り · FX · DEX 約定FLOW · LEFT TO RIGHT · TOP TO BOTTOM
WHY THIS FLOW WORKS
機関の資金は伝統金融 → ステーブル → 許可制プールの順に進む。各ステップで発行体 · 監査人 · コンプラが署名する通過許可がオンチェーンに残り、事後監査で完全に追跡できる。 Ethereum ではこの「通過許可の連鎖」が DAO 経由で分散しており、誰に説明責任を問えるのかが曖昧だった。 Vault はそこを 1 本のフローに畳んだ。

このフローの決定的な違いは、各ステップで発行体・監査人・コンプラが 署名する「通過許可」がオンチェーンに残ること。 事後監査で、誰が・いつ・何を承認したかを完全に再現できる。

Ethereum DeFi ではこの「通過許可の連鎖」が DAO 経由で分散しており、誰に説明責任を問えるのかが曖昧だった—— これが「DeFi は規制適合しない」と言われ続けた本当の理由。 Vault は、そこを 1 本のフローに畳んだ。

§ 05

Aave / Maker / Morpho / Ondo との正面比較

ここまで見てきた構造を、主要 DeFi プロトコルとの 7 軸比較で立体的に確認する。

/ Fig. E · Vault vs 主要 DeFi プロトコル
評価軸
XRPL Vault
XRPL
Launching
Aave v3
Ethereum + L2
$29B
MakerDAO
Ethereum
$8B
Morpho
Ethereum + Base
$6B
Ondo Finance
Ethereum + Solana
$2.3B
KYC / Credentials ネイティブ
プロトコル内にオンチェーン KYC
発行体の転送制御
Permissioned 転送が仕様レベルで可能か
監査境界の明示
SOC 2 / SAS 70 で署名できる範囲
ネイティブ FX
Bridge 不要の通貨間 Auto-Bridging
単一元帳決済
L2 や他チェーンへの分断なし
最終決済時間
XRPL 3–5 秒 / Ethereum 12 秒 + ファイナリティ待ち
規制の宛先
責任を問える発行体が存在するか
XLS-33/70/80/81 統合 · 許可制ネイティブAave Arc 実験中 / オープン原則分散 DAO · 規制の宛先不明Vault モード搭載・部分的許可制RWA 特化 / 単品トークン化
満たす部分的満たさない
FAIR COMPARISON
TVL ではまだ Aave / Maker に圧倒的に及ばない。 だが機関適合の 7 軸では Vault が5 軸で単独トップ。 Ondo はトークン化 RWA 特化で 3 軸完勝だが、ネイティブ FX · 単一元帳を持たない——機関が欲しいのは「一箇所で全部」なので、 そこを総取りできるのが Vault 側の戦略的優位。

TVL ではまだ Aave / Maker に圧倒的に及ばない——それは事実。 だが「機関適合」の観点では、Vault は7 軸のうち 5 軸で単独トップを取る。 特に重要なのが次の 2 点:

  • ネイティブ FX: Aave は USD ベース一択。EUR 建て機関や日本の生保が自国通貨で 運用する道がない。XRPL は Auto-Bridging で任意のペアが XRP 経由で瞬時に換算される。
  • 単一元帳: Ethereum + L2 への流動性分断は、決済確実性を要求する機関にとっては 受け入れがたいリスク。XRPL はそもそも L2 を持たず、 全決済が単一の帳簿で起きる。

Ondo Finance は RWA 特化で健闘しているが、 ネイティブ FX と単一元帳は持てない——機関が欲しいのは 「一箇所で全部」なので、そこで総取りできるのが Vault 側の戦略的優位になる。

§ 06

三位一体 — Vault × RLUSD × Ripple Prime

Vault 単体だけでは「許可制 DeFi のインフラ」でしかない。 それを実際に資金が流れる動脈にしているのは、 既に稼働している 2 つのピース——RLUSDRipple Primeだ。

3 つのピースが噛み合う構造
  • Ripple Prime(NSCC 0443): 伝統金融との接続点。米国株式清算機関の正式メンバーシップを 持つ唯一の暗号プライムブローカー。機関資金はまずここに入る。
  • RLUSD: Big4 監査 · NYDFS 認可 · KBRA BBB · Bluechip A の 4 条件を 揃えた唯一のステーブル。監査役会が通せる担保資産。
  • Vault: RLUSD を担保にした許可制プールで、RWA 利回り · FX · 貸出を統合運用する場。

この 3 つが噛み合うことで、機関は1 つの API / 1 つの口座 / 1 つのコンプラ審査で、

  • · 伝統金融から暗号領域に資金を移し
  • · 監査済みステーブル(RLUSD)で保有し
  • · 許可制プール(Vault)で運用する

——が可能になる。Ethereum 側ではこの 3 層を Circle(USDC)+ Coinbase Prime + Aave Arc + 複数のカストディで組み合わせる必要があり、 監査責任の境界が曖昧だった。

Ripple Prime がを開け、 RLUSD がを提供し、 Vault が運用場を用意する。 機関向けの「最後の 1 マイル」が、2026 年 Q1 時点で XRPL 上に揃った
§ 07

聖杯である、だが罠もある — 正直な両論

Vault が「機関の聖杯」である理由はここまでで見てきた通り。 しかし、宣伝ではない記事として、残っている課題と罠を明示しておく。

Vault に残るリスク・制約
  • TVL の絶対値: Ethereum DeFi の $80B+ に対して、Vault は現時点で ローンチ段階。初期流動性の立ち上げに 12 〜 24 ヶ月はかかる。
  • EVM 非互換: Solidity で書かれた既存コントラクト資産(Uniswap v3 · GMX · Pendle 等)が直接動かない。XRPL EVM サイドチェーン 経由での接続になるが、Vault 本体とは切り離される。
  • Ripple 集中リスク: 仕様提案者(RippleX)・主要ユースケース提供者(Ripple Prime · RLUSD)· 業界ロビー主体(Ripple Labs)がすべて Ripple 系列に寄っている。 多様性の観点で弱点。
  • 規制の宛先は「部分的」: Permissioned Domain は技術的には完璧だが、 米国 SEC · EU MiCA · 日本 JFSA がそれぞれ別の枠で見る可能性がある。 多国籍機関にとっては審査の重複が残る。
  • オンチェーンではあるが、オンレール: オープン DeFi の「誰でも試せる」魅力はない。 それは設計上の trade-off だが、個人 DeFi ユーザーが これを「DeFi」と呼ぶかは議論が残る。

これらは「致命的ではない」が、「すぐに USDT/USDC 級の流動性になる」と 期待するのは幻想だ。 Vault は機関向け DeFi の標準規格になる可能性が高いが、 それは Ethereum を置き換える話ではなく——Ethereum が届かなかった層に新しく届く話だ。

§ 08

結論と、次に何を見るべきか

Vault の本質
  • Ethereum DeFi が機関で「使えなかった」5 つの壁を構造的に潰した最初のパッケージ
  • MPT + Credentials + Permissioned Domains + Permissioned DEXes を単一元帳に内蔵した設計は、主要チェーン唯一
  • Ripple Prime · RLUSD との三位一体で、 機関資金が伝統金融 → 暗号領域に流れる「最後の 1 マイル」を成立させた
  • TVL は Aave / Maker の 1% 未満からスタートする—— だが、機関が欲しいものを 5 年かけてつくってきた唯一のチェーンという優位は揺るがない

次に観察すべき指標は次の 3 つ:

  1. 最初の大口機関の Permissioned Pool 公表(BNY Mellon / State Street / MUFG クラス)
  2. MPT で発行される第一号 RWA(トークン化米国債 · 機関債 · REIT 持分 等)
  3. EU MiCA · 米 GENIUS Act 対応の明示(どの規制枠組みで Vault が「準拠」と認定されるか)

関連記事:
· Canton × XRPL Vault — 発行と流通の経済学 ↗
· RLUSD — 機関対応ステーブルコインの構造 ↗
· NSCC 0443 — 米国株式清算機関の正式メンバー ↗
· DTCC 特許 — $2 京の決済インフラが XRP を名指しした日 ↗
· Ripple Treasury — Fortune 500 の CFO ダッシュボード ↗

/ Sources
  • · XLS-33d · Multi-Purpose Tokens specification (RippleX GitHub)
  • · XLS-70d · Credentials specification
  • · XLS-80d · Permissioned Domains specification
  • · XLS-81d · Permissioned DEXes specification
  • · RippleX · amendment voting history 2024–2026
  • · Aave v3 / MakerDAO / Morpho / Ondo — TVL & architecture disclosures
  • · ERC-3643 (T-REX) / ERC-1400 — Ethereum comparable specifications
  • · Ripple · Prime / RLUSD / Custody product announcements