arbiter

Arbiter

自律型エージェントの判断レイヤーです。

AI エージェントが現実世界で行動する前に、自力では下せない判断を求められることがよくあります。この取引に安全に署名できるか、この取引相手は実在するか、この写真は本当に説明どおりのものか。 Arbiter は、x402 を介して Algorand 上で USDC による支払いを受け付け、こうした判断を1回ごとに提供します。

3つのルートで、応答形式は共通です。

ルート	判断内容	価格
POST /v1/judge/transaction	機械 — 署名前に未署名トランザクションをデコードし、リスクを評価します	$0.002
POST /v1/judge/counterparty	データ — この支払い先は、本人だと名乗る相手と同一人物ですか	$0.01
POST /v1/judge/human	人間 — モデルだけでは判断できない質問に、審査済みのレビュアーが回答します	$0.25

すべてのルートは同じ判定エンベロープを返します。そのため、エージェントは1つの形式を統合するだけで、新たな分岐ロジックを追加せずに、あらゆる種類の判断を求められます。

{
  "decision": "block",        // allow | warn | block | escalate
  "risk": 100,                // 0-100
  "confidence": 1,            // 0-1; low confidence forces "escalate"
  "findings": [ /* itemised, each with severity, detail and source */ ],
  "evidence": { /* the decoded transaction, the counterparty record */ },
  "meta": { "degraded": false, "latencyMs": 378 }
}

初めての方、または技術に詳しくない方に説明する場合はこちらをご覧ください。 Arbiter が実際に行うこと — コードも専門用語もありません。

稼働状況

https://arbiter-hs23.onrender.com — API と、レビュアーアプリ（/work）です。

事前チェックでは、18項目に合格し、ブロッキング障害は0件でした。Render の無料プランで稼働しており、永続ディスクがなく、15分間アイドル状態が続くとスリープします。その費用と、10月のリーダーボード期間前に必要となるアップグレードについては、DEPLOY.md をご覧ください。

ステータス

コンポーネント	状態
x402 決済コア（Algorand、USDC、GoPlausible ファシリテーター）	稼働中。エンドツーエンドで検証済み
Bazaar による検出 + x402-global-challenge タグ	稼働中。402 応答で確認済み
/v1/judge/transaction Algorand ファイアウォール	稼働中。攻撃ケース5件中5件に対応
/v1/judge/transaction EVM ファイアウォール	稼働中。資金流出パターン7件中7件に対応、EIP-7702 を認識
/v1/judge/counterparty エンジン	稼働中。ライブのメインネット + NFD に対するケース5件中5件に対応
/v1/judge/human マーケットプレイス	稼働中。合意形成 + レビュアーの信頼性 + 支払い台帳
オンチェーンの支払い決済	稼働中。実際にレビュアーへオンチェーンで USDC を支払い済み
SDK、MCP サーバー、LangChain、ElizaOS、決済プロキシ	構築済み。型チェック済み、実行時検証済み
CrewAI ツール（Python）	構築済み。決済プロキシ経由で動作します。詳細は以下をご覧ください
KeeperHub 統合	稼働中。実際の Sepolia トランザクションを実行済み
レビュアーアプリ（React）	/work で稼働中。有料の質問を使ってエンドツーエンドで検証済み

トランザクションファイアウォール

自律型エージェントが資金を失う原因は、いくつかの特定のパターンに限られます。このファイアウォールは実際のトランザクションバイト列をデコードし、署名すると何が起こるのかを報告します。

• Rekey — rekeyTo により、アカウントの署名権限が恒久的に移転します
• Close-remainder — 表示された金額に関係なく、ALGO の残高全額が引き出されます
• Asset close-out — 表示された金額に関係なく、ASA の保有量全額が引き出されます
• Clawback — 第三者のアカウントから資産が移動されます
• 手数料による資金流出 — 目に見える送金ではなく、過大な手数料によって残高が流出します
• アプリの削除／更新 — コントラクトのロジックが破壊されたり、気付かれないまま置き換えられたりします
• 資産レベルのリスク：作成者が保持する clawback 権限と freeze 権限、存在しない資産
• アカウントレベルのリスク：署名者がすでに rekey 済み、受取人の資金不足、有効期限切れの有効期間

実際に新しくエンコードしたトランザクションを使って実行します。

npm run demo:attacks

[BLOCK]  Rekey attack              risk=100/100  confidence=1  1365ms
[BLOCK]  Close-remainder drain     risk=100/100  confidence=1   378ms
[BLOCK]  Asset close-out drain     risk=100/100  confidence=1  1432ms
[BLOCK]  Fee drain                 risk=100/100  confidence=1   379ms
[ALLOW]  Benign payment            risk=0/100    confidence=1   398ms

問題のないケースで指摘がゼロ件となることは、脅威をブロックするのと同じくらい重要です。誤検知するファイアウォールは、いずれ無効にされてしまいます。

取引相手の検証

支払いエージェントが請求書を読むだけでは気づけない、損失の大きい次の2つの問題を検出します。

• 支払いアドレスのすり替え — 請求書は本物で、受取人も実在しますが、アドレスは別の人物のものです。NFD レジストリを照会し、そのIDが正当に管理するすべてのアドレスと比較して判定します。
• アセットのオプトイン漏れ — Algorand では、オプトインしていないアカウントへの ASA 送金は拒否されます。支払いは届きません。

ほかにも、リキーされた受取人、凍結された保有資産、最低残高未満、未登録または期限切れのID、資金が一度も入金されていないアドレスも検出します。

npm run demo:counterparty     # live NFD registry + Algorand mainnet, read-only

確認しておくべき2つのケースは、隣り合っていて正反対です。IDは検証済みなのにアドレスがアセットを受け取れないケースと、受け取り可能なアドレスなのにIDが検証に失敗するケースです。どちらも、まったく異なる理由で処理をブロックします。

人による判断

モデルだけでは結論を出せない質問は、審査済みのレビュアーに送られます。有料の呼び出しは、上限時間内でロングポーリングします。時間内にレビュアーが回答すれば判定がそのまま返され、そうでなければ保留中の判定と無料の取得 URL が返されます。タイムアウトしても、追加料金は発生しません。

npm run demo:human

• 設定可能な定足数に基づく多数決を行い、一致率を公開します
• 確信度は、パネルの実績に応じて割り引いた一致度です。そのため、実績のないレビュアー全員が一致しても、確実とは扱いません
• レビュアーへの報酬は、参加に対して支払われ、賛成に対して支払われるものではありません。賛成に報酬を払うと、見た内容を報告するより、多数派を推測する動機になってしまいます
• 不自然に速い回答は、品質を判断するシグナルとしてフラグが付けられます
• 各レビュアーの信頼性は、長期的な合意形成への一致度に基づいて蓄積されます

Worker API（/v1/work/*）は有料ではありません。レビュアーは供給側です。

レビュアーへの支払い

npm run settle -- --dry-run    # check everything, send nothing
npm run settle                 # pay

この処理には2つのルールがあり、どちらを守るにもコストがかかります。

ブロードキャスト前に確保する。 トランザクションを送信する前に、支払いを試行IDとともに settling に移し、その試行IDをトランザクションのノートフィールドに記録します。そのため、処理が途中で停止した場合に発生するのは未払いであり、二重払いではありません。未払いであれば、停止した行と台帳を人が照合して復旧できますが、二重払いは復旧できません。

支払い前に受取人を確認する。 すべての支払いアドレスは、まず Arbiter 独自の /v1/judge/counterparty エンジンで確認されます。これは単なる飾りではありません。オプトインしていないアカウントへの USDC 送金はプロトコルによって拒否されるため、確認せずに支払うと手数料が無駄になり、レビュアーへの支払いも説明なしに未払いのままになります。ブロックされた支払いは保留され、レビュアーがオプトインした後に再試行されます。

[PAID]  0.150000 USDC -> GBRO5EM4JM57PDPS…
        txid  SIEXIGX6KQKA4D4PTOUL7R6M5BDP4BIUEW2TTOIFZHBU233LSKWQ
        note  arbiter:payout:pay_msft8csu_rfq0ch

[SKIP]  0.150000 USDC -> OEQWDYGTEXMDWSH2…
        Arbiter blocked this payee: Counterparty has not opted in to the asset

支払いアカウントは、意図的に PAY_TO とは別に設定します。PAY_TO は収益を蓄積するアカウントで、その鍵をサーバーに置く必要はありません。支払いアカウントが保有するのは運転資金のみなので、ホストが侵害されても収益を引き出されることはありません。

設計ルール：呼び出し元はすでに支払い済みです

エンジンが実行される時点で、エージェントはすでに課金されています。そのため、上流での障害が例外を送出することはありません。すべての algod 照会には厳格なタイムアウトがあり、データを実際に取得できたかどうかを示す結果を返します。照会に失敗すると confidence が下がり、meta.degraded が設定されますが、重大度の高い問題を検出する静的デコードルールは引き続き実行されます。劣化状態の判定も有用です。

また、confidence < 0.4 の場合は allow ではなく escalate を返すため、証拠が不十分な判定が、問題なしと誤認されることはありません。

エージェントへの導入

利用数順のリーダーボードでボリュームを獲得するには、他の人のエージェントに呼び出してもらう必要があります。そのため、クライアントは後回しにするものではなく、製品の表面です。詳しくはclients/README.mdをご覧ください。

パッケージ	対象
@arbiterlabs/sdk	TypeScript エージェント。x402 による支払いを自動で行います
@arbiterlabs/mcp	あらゆる MCP ホスト — Claude Code、Claude Desktop、OpenClaw
@arbiterlabs/langchain	LangChain.js ツール
@arbiterlabs/eliza	ElizaOS プラグイン
@arbiterlabs/proxy	TypeScript 以外のエージェント向けの、ローカルで支払いを行うサイドカー
arbiter-crewai	サイドカー経由の CrewAI（Python）

支出上限はインテグレーターへの注意喚起ではなく、クライアント内で設定します。有料エンドポイントへのリトライループに入ったエージェントは、ウォレットの残高を枯渇させるバグだからです。

const client = new ArbiterClient({
  baseUrl: process.env.ARBITER_URL,
  privateKey: process.env.ALGO_KEY,
  maxPricePerCallUsd: 0.5,
  maxTotalSpendUsd: 10,
});

どちらの上限も、何かに署名する前に支払いセレクターで適用されます。

Python にサイドカーが必要な理由

Algorand で x402 による支払いを行うには AVM スキームクライアントが必要ですが、現時点でそれが存在するのは TypeScript のみです。x402 2.18 には AVM クライアントが含まれておらず、名前に反して x402-avm 2.0.2 にも含まれていません。また、algosdk への依存関係もなく、ベースパッケージを上書きする形で x402 名前空間にインストールされます。そのため、Python エージェントは Algorand の x402 支払いをまったく構築できません。

そこで @arbiterlabs/proxy がキーを保持して支払いを行い、ループバック上で価格設定なしの判定を再公開します。一般的にも、こちらの構成のほうが優れています。資金のあるキーを保持して単一の予算を適用するプロセスを1つにでき、各エージェントのプロセスにその両方のコピーを持たせずに済むためです。

セットアップ

npm install
cp .env.example .env    # then set PAY_TO
npm run dev

PAY_TO は、実行するネットワーク（テストネット 10458941、メインネット 31566704）の USDC ASA にオプトイン済みの実在する Algorand アドレスでなければなりません。そうでない場合、決済に失敗します。

支払いゲートを確認します。

curl -i -X POST http://localhost:4021/v1/judge/transaction \
  -H 'content-type: application/json' \
  -d '{"chain":"algorand","transaction":"abc"}'

価格、アセット、payTo、feePayer、Bazaar の検出スキーマを含む base64 エンコードされた PAYMENT-REQUIRED ヘッダーとともに、HTTP 402 が返されることを確認してください。

ファシリテーターネットワーク識別子について

GoPlausible ファシリテーターは、CAIP-2 の参照としてパディングを含む完全な base64 ジェネシスハッシュを使用して Algorand を通知します。

algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=

一方、@x402/avm の ALGORAND_TESTNET_CAIP2 では、CAIP-2 で有効な32文字への切り詰めが使用されています。

algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDe

どちらも AVM スキーム内では同じネットワークに正規化されますが、リソースサーバーはルート設定をファシリテーターの通知文字列と完全一致で検証します。そのため、SDK の定数を使うと起動時に missing_facilitator エラーが発生します。src/facilitator.ts は起動時に /supported から識別子を取得し、正規化して照合するため、どちらの形式でも機能し、上流でパディングが修正された場合も引き続き動作します。また、通知された feePayer も取得するので、呼び出し側はガス代用の ALGO を保有せずに USDC で支払えます。

コンペティションの設定

Algorand Global x402 Challenge向けに、複合エントリーとして構築されています。3つすべてのルートで同じpayToを共有するため、各ルートはBazaarで個別に見つけられる状態を保ちながら、取引量は1つのマーチャントエントリーに集計されます。

要件は組み込み済みで、ライブの402レスポンスで確認されています。

• 支払いなしの場合にHTTP 402を返す有料エンドポイント
• GoPlausibleファシリテーター（代替ファシリテーターではありません）
• ルートごとの入出力スキーマを含むBazaarディスカバリー拡張
• すべてのルートにx402-global-challengeタグを設定
• すべてのルートで一貫した単一のpayTo
• MainNet上の公開HTTPSにデプロイ済み
• 実際のMainNet決済が1件完了し、USDCの受領を確認済み
• Algorand MainNetのUSDCリーダーボードに掲載済み

最初に決済されたMainNetの取引は IUTXAWFK…です。 0.002 USDC（ASA 31566704）がラウンド63,807,235で決済されており、決済レスポンスからではなく、インデクサーで確認されています。

帰属はpayToアドレスによって判定されます。リーダーボードにはタグフィルターがないため、x402-global-challengeタグはBazaarでの発見を助けますが、スコア判定の条件にはなりません。npm run preflight -- <url>は、タグから推測するのではなく、掲載状況を直接確認するようになりました。

assertChallengeReady()は、MainNetのデプロイ先がlocalhostまたはHTTPのままの場合、起動時に失敗します。