Radomが発表した内容
Radomは9月14日にv2.0を発表しました。決済プラットフォーム上の残高は、ネットワークごとに分かれた表示から、対応する全ネットワークを横断した資産単位の一つの残高へ変わります。Radomによると、Ethereum、Base、Polygon、Arbitrum、BNB Chain、Tron、Solanaで受け取ったUSDCは、顧客がネットワーク別残高間で事前に資金移動せず、別の対応ネットワークから支払えます。
このリリースは、リアルタイム見積もりによる変換、資産・ネットワークをまたぐ出金、入金を希望する決済資産へ自動変換する任意機能も追加しました。Radomはv2.0が提供開始済みで、既存組織を今後数週間かけて移行すると説明しています。発表内の将来の銀行連携は、パートナーと規制当局の承認を前提とする見通しであり、現時点で利用可能な機能ではありません。
一つの残高でも、決済状態は一つではない
統合残高はプロダクト画面を単純化しますが、基盤は確定条件、再編成、手数料市場、トークンコントラクト、障害モードが異なる複数ネットワークを横断します。顧客向け台帳は資産単位で経済的エクスポージャーを集約できます。一方、運用台帳には、入金元ネットワーク、トークン識別子、トランザクションハッシュ、観測したファイナリティ、変換記録、出金先経路、出金トランザクションを残す必要があります。
この区別はインシデント時に重要です。一つのネットワークが停止した場合やトークンコントラクトが置き換わった場合、同じティッカーの全残高を止めずに、影響する入出金を特定できなければなりません。そのため、プロダクトAPIと内部イベントスキーマでは、統合残高を経路別証跡に対するビューとして扱い、その代替にすべきではありません。
見積もり、支払意図、再試行を一つの実行記録へ結合する
Radomは、変換や異なる資産への出金を確定する前にリアルタイム見積もりを表示すると説明しています。API駆動フローで必要な本番統制は、その見積もりと正確な支払意図の結合です。送付元金額と資産、送付先資産とネットワーク、受取人、手数料の扱い、有効期限、最低受取額を固定します。実行記録には見積もりIDと実際の決済値を保存し、後から市場価格を使って差異を推測せずに財務部門が説明できる状態にします。
再試行も同じく重要です。変換や出金の実行後、呼び出し元が確認を受け取る前にタイムアウトする可能性があります。クライアントには安定した冪等性キー、状態照会、未観測の成功と安全な再試行を区別する照合経路が必要です。最初の応答が失われたという理由だけで、キューワーカーが二重の変換や出金を作成してはなりません。
抽象化、トレジャリー、ブロックチェーンを照合する
Radomは、統合トレジャリーが各組織の残高を1対1で裏付け、継続的に支払能力を監視すると述べています。一方、発表はカストディ構造、算定方法、アテステーション、処理中取引の扱いを明示していません。インテグレーターはこれを事業者の説明として扱い、リスクに応じて、資産保全と法的所有権の条件、対応コントラクトアドレス、確定ポリシー、照合用エクスポート、インシデント手順、出金統制の証跡を取得すべきです。
堅牢な締め処理では、少なくとも四つのビューを比較します。顧客残高と取引履歴、Radomの口座または補助台帳、資産・ネットワーク別のカストディまたはオンチェーン残高、受取人側の最終決済です。例外には担当者と理由コードを付けます。処理中の確定、見積もり失効、変換スリッページ、手数料差異、送付先拒否、事業者調整などです。顧客向け表示の集約は手動の資金管理を減らしますが、経路別流動性、集中、カウンターパーティーのリスクはなくなりません。
Ineezaの見解
Radom v2.0は、プロダクトチームに代わって基盤がクロスネットワークの複雑性を吸収する好例です。適切な連携境界は「一つの残高」だけではありません。追跡可能な経路別証跡、決定論的な支払意図、再試行に安全な実行、独立照合できる記録、明確な縮退動作に裏付けられた一つの残高です。これらの統制を維持すれば、運用リスクを不可視化せずにユーザー体験を単純化できます。