エージェント・トレジャリーのフォワードOTC決済:信頼に依存しないT+24時間取引

Dev.to / 2026/5/8

💬 オピニオンSignals & Early TrendsIdeas & Deep AnalysisIndustry & Market Moves

要点

  • エージェント向け決済スタックでは、T+0(即時)決済を目的とした複数の新しい標準やプロダクトが最近投入され、ほぼ瞬時のファイナリティを実現することが狙いだ。
  • 記事は、決済レールに取引を行わせるべきではないと主張する。取引は決済ウィンドウや複数レグ、原子的な実行などの要件を伴い、決済の設計思想とは異なるためだ。
  • エージェント・トレジャリーの実運用ワークフローとして、週次のリバランス、毎週の買い戻し、クロスアセットのヘッジ解消の3例を挙げ、それらがT+24時間〜48時間のようなゼロでない決済期間と、同期したクリアリングを必要とすると説明している。
  • 人間が行う暗号OTCフォワード取引の流れ(提示・合意・T+24hなどのデリバリーウィンドウ合意の後、後日送金)と、フォワードを両者が約定どおり履行するという2つの信頼前提が生むカウンターパーティリスクを指摘する。
  • 「エージェント・トレジャリーのためのフォワードOTC決済」により、支払いの即時性ではなく決済リスクに対処することで、信頼への依存を減らす方向性を提示している。

過去3週間で、エージェント決済スタックに5つ目の出荷済みスタンダードが追加されました。Pay.shはGoogle CloudでSolanaにローンチしました。Coinbaseのx402は累計167M件の取引を超えました。OKX Agent Payments Protocolはwallet+SDK+brokerを追加しました。ERC-8183はBNB Chainのメインネットに卒業しました。CoinbaseのAgent.marketは7カテゴリのアプリストアを開きました。

この5つには共通して、ある1つの特性があります。それはT+0で決済することです。

それをまさに行うべきです。あなたのエージェントがVertex AIを呼び出したり、Perplexityのクエリに支払ったりするなら、秒未満の確定性が欲しいはずです。Pay.sh、x402、OKX APPは、決済レールとして非常に優れています。決済レールにそれ以外のことをさせるべきではありません。

しかし、エージェントのトレジャリーは道具に支払うだけではありません。ますます、それらは取引もします。そして取引は決済ではありません。

エージェント決済レールが飛ばしている次元

取引には少なくとも2つの側面があり、しばしば2つ以上の資産が絡み、ほとんどの場合、ゼロではない決済ウィンドウがあります。

今日すでに本番環境で存在し、人間によって実行され、明日自律エージェントに実行が求められる3つの実在するワークフローを考えてみましょう。

  1. トレジャリーのリバランス。 DAOがETHを60%、BTCを30%、SUIを10%保有しており、方針で毎週リバランスすると定められています。エージェントは、すべての脚を同じ瞬間にあるプールへ叩き込もうとはしません――それはスリッページ税です。各脚をRFQして、同時に価格をロックし、グループとして清算したいのです。自然に、ある脚は他より時間がかかります。
  2. スケジュールされた買い戻し。 あるプロトコルは、直前の週に集めた収益を元に、毎週金曜のUTC正午にそのトークンを買い戻すことを約束します。買いと売りは、順次ではなく結び付けられている必要があります。エージェントは水曜にコミットし、金曜にデリバーしなければなりません。
  3. クロスアセットのヘッジ解消。 エージェントがある取引所でperpを使ってペアをショートし、別の取引所でスポットで相殺します。解消は、取引所間で原子的である必要があります。先行ウィンドウ(24時間のこともあれば48時間のこともある)が、人間のデスクがすでにそれを行っている方法です。

これらはどれも決済レールの問題ではありません。3つとも決済(セトルメント)の問題です。

今日、OTCデスクはどうやっているのか、そして何が欠けているのか

暗号のOTCデスクに電話してフォワードを頼むと、何が起きるでしょう。彼らは見積もりを提示します。あなたは価格に同意します。あなたはデリバリーウィンドウ――T+24h、T+48h、ときにはT+5――に同意します。メールで確認書にサインします。24時間後、双方が振り込みます。

そこには2つの前提が仕込まれています。1つ目は、デスクが、市場が約5%彼らに不利に動いたとしても、合意した価格でフォワードを履行するということです。2つ目は、あなたもそれを同様に履行するということです。OTCの歴史には、2つ目の前提が崩れてデスクが損失を飲み込んだケースが数多くあります。また、1つ目の前提が崩れて顧客が損失を被ったケースも、より少ないながら存在します。

これは、カウンターパーティリスクが最も純粋な形で現れたものです。報告によれば、1-in-10のOTC取引が人間のデスクレベルで失敗する理由であり、そして今年のあらゆる自律経済圏の論文が「エージェント間の信頼」を未解決のレイヤーとしてフラグを立てている理由でもあります。

レピュテーションでエージェント間の信頼を解決できます。ERC-8004はそのためのきれいな試みです。もう1つは担保で解決する方法です。Hashlockは担保の道を選びます。なぜなら、レピュテーションにはブートストラップの問題があり、担保にはそれがないからです。

Forward OTCを機械的に

Hashlock MarketsにおけるForward OTC取引は、シールドビッドのRFQに続いて、各脚に対するハッシュ化タイムロック契約(HTLC)が設けられ、デリバリーウィンドウは実際のチェーン時間で計測されます。

流れは次のようになります。

  1. RFQ。 受け手(エージェントまたは人間)が、ペア、サイズ、デリバリーウィンドウを指定してRFQを作成します。たとえば「1 BTCを21.5 ETHに対して、決済ウィンドウT+24hでデリバーします」。複数の出し手がシールドビッドで応答します。受け手はそのうちの1つを選びます。
  2. ロック。 両者は、それぞれのチェーンにHTLCボンドを投稿します。出し手は、Ethereum上で21.5 ETHを、受け手が保持するプリイメージにハッシュした形でロックします。受け手は、Bitcoin上で1 BTCを、同じプリイメージにハッシュした形でロックします。各ロックには、デリバリーウィンドウに小さな猶予期間を足したタイムロックが設定されます。
  3. 開示。 ウィンドウ内で、受け手はプリイメージを開示して出し手のETHを請求します。Ethereumでの請求は、プリイメージをオンチェーンに公開します。出し手のリレーラーはそれを拾って、Bitcoin上でBTCを請求するために使います。2つの開示――1つのプリイメージが、2つのチェーン間で原子的に行われます。
  4. 返金。 いずれかの側がタイムロックが期限切れになる前に行動しなかった場合、ロックは解消されます。双方のボンドは、元の所有者に返ります。部分決済は可能ではありません。

時計はスマートコントラクトです。ブローカーが取引の両側を持つことはありません。召喚状を出され得たり、ハッキングされたり、ラグられたりし得るエスクローのカストディアンもいません。各当事者が信頼しているのは、数学が成り立つこと、チェーンが確定すること、そしてタイマーがカウントダウンすること――この3つだけです。

なぜSuiがこのプリミティブをよりきれいにするのか

Hashlock Marketsは、今週時点で3つのチェーン上で動作しています。Ethereum、Bitcoin、Suiです。Suiメインネットのサポートが5月1日に稼働開始し、それは思われている以上に重要です。

BitcoinはEVMの意味でスマートコントラクトを話せません。Suiネイティブの取引でBTCを担保として使うには、「ラップしたカストディアルトークンに押し込んで祈る」以外の方法で、それを保持する必要があります。私たちはこれにHashiを使います。これは、ラップトークンを鋳造せずに、検証可能な証明に対してBTCを保持するSuiネイティブのブリッジプリミティブで、HTLCとしてロックできるSui上のオブジェクトを出力します。

Suiのオブジェクトモデルが、この仕組みを機能させる理由です。ハッシュロック状態が、大きな共有マッピングの中の残高エントリである代わりに(Ethereumのアプローチでは、すべての請求/返金が互いの請求/返金に競合することを強制されます)、各Forward OTCボンドは、それぞれが自分自身の所有者とライフサイクルを持つ独自のオブジェクトです。異なる取引に対する請求は、互いの後ろにキューイングしません。ボンドは、他のSuiのプリミティブ(スポンサー付きトランザクション、プログラマブルトランザクションブロック、ガスポール)とも、他のオブジェクトと同じやり方で組み合わさります。

これは、つい6か月前には不可能だったスタックの一部です。今は可能です。

7 bpsの詳細

Hashlockは、現在の参照デプロイメントにおいて、決済済み出来高に7ベーシスポイントを請求します。また、コミットしたウィンドウ内で決済する出し手には、Execution Rewardsによって最大50%のリベートがあります。信頼できる出し手の実効手数料:3.5 bps。返金する出し手の実効手数料:7 bps。典型的なCEXのOTCデスクが8〜10 bpsであることと比べて、ではそのデスクは実際にスプレッドに対して何をしているのかを考えてください。

私たちは意図的に、これらを「production」ではなく「reference deployments」と呼んでいます。まだ事前監査前で、V1では契約は不変であり、出来高の下限も小さいからです。手数料体系は、期待を込めたマーケティング数値ではありません。契約が実際に受け取るものです。

試してみてください

今日、Claude Desktopを(スコープ付きで)hashlock-tech/mcpパッケージに向け、create_rfqsettlement_window=86400(24時間、秒)で呼び出せば、テストネット上でETH、BTC、またはSUIに対する実際のForward OTC RFQを送信できます。MCPは6つのツールを公開しています:create_rfqrespond_rfqcreate_htlcwithdraw_htlcrefund_htlcget_htlc。フォワードウィンドウは最初の呼び出しで指定するパラメータです。

Forward OTCのメカニクスの完全なウォークスルーをhttps://hashlock.markets/docsで公開します。タイムロック導出やクロスチェーンの請求グラフを含むプロトコル仕様は、SSRNの論文にあります:https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Hashlock Markets、公的な正規のURL: https://hashlock.markets。GitHub: https://github.com/Hashlock-Tech/hashlock-mcp

あなたのエージェント・トレジャリーは、実際にはどのフォワード決済ウィンドウが必要ですか――T+0、T+24h、またはT+48h?そして、それを最初に考えさせることになったのは、どのワークフローでしたか?