XRPL の動的 NFT、
曖昧に語らない

XRP Ledger では、本番運用に耐える動的 NFT のパターンが今日すでに 2 つ存在します。それぞれが異なる課題を解決し、異なる信頼モデルの上で動きます。どちらが何に適しているかを正しく理解することが、設計のすべてです。

XLS-20d · XLS-46d · メインネット稼働中 · 構築者の視点で

2 つのパターン

「動的 NFT」というマーケティング用語の背後には、実は本質的に異なる 2 つの仕組みがあります。両方とも XRPL 上で稼働しており、両方とも発行後にメタデータが変化します。違いは、誰を信頼するか、そして更新にいくらコストがかかるかにあります。

パターン 1

可変 URI + サーバー描画メタデータ

NFT は tfMutable フラグを立てて発行されます。オンチェーンに記録される URI は固定ですが、その URI が指し示す JSON はリクエストごとに発行者のサーバーで動的に再生成されます。

  • 低コスト — 更新ごとのトランザクション不要
  • 高速 — メタデータの更新は単なる HTTP 取得
  • 信頼モデル: 保有者は発行者のサーバーを信頼する
  • 適用先: 状態が頻繁に変化し、発行者のデータから導出可能で、オンチェーンの証明性が必要ないケース
パターン 2

NFTokenModify(XLS-46d)

発行者が NFTokenModify トランザクションに署名することで、NFT の URI そのものをオンチェーンで書き換えます。新しい URI は合意形成によって証明されます — 発行者の言葉ではなく、台帳の状態として。

  • 証明可能 — すべての URI 変更にトランザクションハッシュが付随
  • 検閲耐性 — 真実をコントロールする単一サーバーが存在しない
  • 信頼モデル: 保有者は台帳を信頼する
  • 適用先: 来歴・真贋証明が重要、規制対応で記録保存義務がある、発行者の協力なしに保有者が履歴を検証する必要があるケース
他チェーンの「動的 NFT」実装の多くは、実はパターン 1 を別の言葉で語っているだけです — メタデータ URI が可変な IPFS や発行者のサーバーを指している、というだけ。それを「オンチェーンで動的」とリテール顧客に売っています。XRPL は両パターンを別々に名付けて提供しているため、設計者が意図的に選択できます。

判断基準の早見表

観点パターン 1: 可変 URIパターン 2: NFTokenModify
更新ごとのコストほぼゼロ(HTTP リクエスト 1 回)XRPL トランザクション手数料 1 回
更新の遅延即時1 ledger close(約 3〜5 秒)
発行者ダウン時の継続性×(サーバーが消えればメタデータも消える)○(URI は台帳の状態として永続)
更新履歴サーバーが記録した範囲オンチェーンに永久保存、誰でも参照可能
発行者なしで保有者が状態を検証可能か×
発行者が過去の状態を取り消せるか○(メタデータを差し替え可能)×(履歴は永続)
適例: ライブゲーム統計、プロフィールカード、フィード反応過剰
適例: 来歴証明、規制下の記録保存、認証バッジリスクあり(監査証跡なし)

Kairo Vault における実装例

すべてメインネットで稼働中。ウォレットを接続すると、NFT スタジオ内の「Dynamic」サブタブから、保有中の可変フラグ付き NFT 一覧、変更履歴、発行者として書き換える操作にアクセスできます。

Living Portfolio Card

一度発行すれば、ウォレットの現在状態を常に反映し続けます。XRP 残高が閾値を越えるたびに保有ティアが進化します。

パターン 1 · taxon 1

Quantum-Proof Badge

アカウントの Harvest-Now-Decrypt-Later 耐性スコアが変化するたびに更新されます。マルチシグ化+マスター鍵無効化の達成で獲得。

パターン 1 · taxon 2

Tweet Mint

ツイートを Living NFT として記録。エンゲージメントティア(ブロンズ → シルバー → ゴールド → レジェンダリー)はいいねの蓄積に応じて変化します。

パターン 1 · 稼働中

酒蔵ボトル来歴 NFT

蔵元が署名する高級酒銘柄の来歴 NFT。熟成・貯蔵の各イベントが新しいオンチェーン記録として追加されます。

パターン 2 · 蔵元パイロット中

Kairo Vault スタックの実装ノート

サーバーメタデータ・エンドポイント(パターン 1)

/api/nft/card/:address/api/nft/quantum/:address/api/nft/tweet/:tweetId の各エンドポイントは、レスポンスごとに SHA-256 のコンテンツハッシュを ETag として付与します。画像 URL には ?v={hash} が自動的に付加されるため、メタデータが変化した瞬間にウォレットや NFT マーケットプレイスがキャッシュを破棄します。Cache-Control は public, max-age=60, must-revalidate — クライアントは約 1 分以内に更新を取得しますが、頻繁にアクセスするウォレットによる連続再生成は発生しません。If-None-Match ヘッダにマッチした場合は 304 Not Modified で短絡応答します。

書き換えサービス(パターン 2)

共有モジュール dNftMutateService は、NFTokenModify トランザクションを純粋関数として構築します。発行者の r-アドレスと 64 文字 16 進の NFTokenID を検証し、UTF-8 URI 文字列を往復変換します(日本語 URI も対応)。トランザクション JSON のみを返し、署名はウォレットアダプタ(Crossmark、GemWallet、WalletConnect、Xaman)が担います。Kairo Vault は秘密鍵を一切扱いません。

Dynamic NFTs サブタブ(コンシューマー画面)

保有中の可変フラグ付き NFT を「自分が発行したもの」と「他者から保有しているもの」にグループ化して一覧表示します。各 NFT カードに taxon、フラグ、現在の URI を表示し、メタデータをインライン展開します。「再取得」ボタンはパターン 1 のメタデータ再フェッチ。「オンチェーン書き換え」ボタンは自分が発行した NFT に対するパターン 2 の操作画面を開きます。

ライブデモを試す → XLS-46d 仕様(GitHub)

誇張しない範囲で

XRPL で動的 NFT を実現するために、rippled のフォーク、サイドチェーン、オラクルネットワーク、オフチェーンインデクサーは必要ありません。ここで説明した 2 つのパターンは、いずれも標準のメインネット上で今日すでに動いています。これ以外のインフラを追加する正当な理由は、特定のユースケースが両パターンのどちらでも提供できないものを必要とする場合に限られます — そして実際には、ほとんどのケースは両パターンで足ります。