発表された内容
Open Standardは9月30日、Bridgeが発行するOpen USD（OUSD）をBase、Ethereum、Solana、Tempoで開始しました。発表ではBVNK、Stripe、Visa Stablecoin Platform、Coinbaseの4つを連携経路として挙げ、Coinbaseからの利用は10月1日に始まるとしています。全経路が1米ドル対1 OUSDのmintとburnを手数料なしで提供し、最初の取引場所としてCoinbase、Kraken、Uniswapを示しています。
Open Standardによると、OUSDの準備資産はBlackRock、Lead Bank、BNYで保管され、Bridgeが毎月attestationを公開する予定です。Bridgeは別の発表で、現時点の発行者はBridge Building Inc.であり、条件付き承認を受けたnational trust bankは未稼働でOUSDを発行していないと説明しています。Stripeの文書は、OUSDの受取、保有、払出し、カード利用、決済受付を製品ごとの提供条件付きで示しています。ここまでは各組織の公表内容であり、以下はIneezaの本番運用分析です。
一つのtickerは一つの運用資産を意味しない
Ineezaの分析: OUSDは一つのブランドと計算単位を示しますが、各chain上の実体は異なるcontractまたはmint、finality model、fee market、障害領域、連携経路を持ちます。本番台帳ではtickerだけでなく、issuer、network、検証済みcontract addressの組み合わせで資産を特定する必要があります。入金案内、allowlist、署名policy、照合規則にも同じcanonical identityを使います。
routing logicには明示的なpolicy versionも必要です。Base、Ethereum、Solana、Tempoの選択は、確認時間、transaction semantics、流動性、運用上の依存先、復旧方法を変えます。経路を選んだ理由を記録し、walletの署名やproviderの実行前に、承認済みintentへnetworkとcontractを結び付けるべきです。
四つの接続経路がprovider間の状態問題を生む
Ineezaの分析: あるproviderでmintし、onchainで移転し、別のproviderでredeemまたは支払う処理は、複数のidentifierと状態機械をまたぎます。APIの成功応答だけでは、発行、chain settlement、受取人への計上、変換、払出しがすべて完了した証明になりません。各操作にはidempotency key、provider reference、blockchain transaction identity、金額、network、timestamp、明確な終端状態が必要です。
provider記録、内部subledger、wallet残高、chain event、銀行預金を独立して照合します。結果不明のtimeout後も再試行を安全にし、例外時は二重送金ではなく統制された補償処理を使います。circuit breakerはprovider、chain、contract、機能ごとに限定し、redeemの遅延やnetwork障害によって、承認したrisk limitの外へ資金が暗黙に迂回しないようにします。
手数料なしの等価交換でも流動性リスクは残る
Ineezaの分析: 手数料なしの1対1変換は価格条件を表しますが、あらゆる状況での可用性やsettlement timeを保証するものではありません。providerの利用資格、取引・残高上限、cutoff、compliance hold、流動性監視、mintやredeem停止時の動作が依然として必要です。製品表示でも、受付済みの依頼とドル決済の完了を区別すべきです。
複数chainへの対応は在庫管理の問題も増やします。chain間で価値を移す場合、issuer-nativeのmint-and-burn、取引所在庫、bridgeのどれを使うか、移動中とdepegのriskを誰が負うかを特定します。rebalancingには上限と可観測性を持たせ、特定providerやchainの残高がグローバルなOUSD残高の隠れた制約になる前に警告する必要があります。
準備資産の証跡を運用モデルに組み込む
Ineezaの分析: 毎月のattestationは有用な開示ですが、リアルタイムの可用性指標ではなく定期的な証跡です。財務・risk teamは各attestationを保存し、対象期間とissuer範囲を確認し、償還義務を負うlegal entityへ対応付け、公開遅延や対象変更時のescalationを定義すべきです。provider statusとonchain supplyの監視は別の統制として残ります。
法的・流通上の境界も機械的に強制する必要があります。利用可能性はprovider、国、network、release statusで異なるため、onboarding eligibilityと取引認可は固定的なmarketing前提ではなく実行時に評価します。対応地域、条件、issuer structureの変更は、audit trailを持つ版管理された設定として扱います。
Ineezaの見解
OUSDは、企業向けの一つのステーブルコインを主要な決済事業者と4つのchainで同時に開始し、issuerによる変換と準備資産開示を共通基盤として位置付けた点で重要です。この抽象化は導入を簡素化できますが、信頼できる運用には、その内側の詳細を保持する必要があります。資産のcanonical identity、承認済みの経路policy、provider別の状態、legal entityの対応、流動性上限、準備資産の証跡、全経路を横断する加算的な照合を一体で設計することが重要です。