AgentFeed on Algorand

agentfeed-algo

Algorand 上の有料 x402 データ API です。呼び出しごとに USDC で取引所横断の清算テープを提供し、情報が不明な場合はそれを伝えます。

Algorand Foundation Global x402 Challenge 向けに構築されました。

Algorand メインネットで稼働中

https://algo.ochinimus.app

network   algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=
asset     USDC, ASA 31566704
facilitator  https://facilitator.goplausible.xyz
catalog   https://algo.ochinimus.app/catalog
manifest  https://algo.ochinimus.app/.well-known/x402

閲覧は無料、読み取りは有料です。支払いなしで任意のルートを呼び出すと、レスポンス本文にルート、価格、アセット、支払いによって利用可能になる内容が記載された 402 が返され、支払いチャレンジ自体は PAYMENT-REQUIRED ヘッダー内に base64 で格納されています。このテープには、2026 年 7 月 8 日以降、Binance、Bybit、OKX で 900 を超える銘柄が記録されており、2026 年 9 月 16 日までの直近 7 日間の平均清算件数は 1 日あたり約 73,000 件です。

提供内容

5 つのエンドポイントを、x402 経由でリクエストごとに USDC で支払って利用できます。アカウント、API キー、登録は不要です。これらは /v2 で公開されています。

これらのルートが最初に公開された 5 つのパス、つまり /v1 のパスも引き続き応答します。ハンドラー、ペイウォール、価格は同じで、それぞれに固有のリソース URL があります。古い URL を持つエージェントは、移行によって動作しなくなることはありません。ただし、現在は /v1 を案内するものはありません。カタログ、マニフェスト、ランディングページ、MCP サーバーが掲載するのは /v2 のみであり、古いパスを対象に新たに構築するべきではありません。

1 つの銘柄の期間内の清算量を、取引所別、およびロングとショートのどちらが清算されたかで分類して提供します。価格は 0.02 USDC です。 その清算量が一度の急増として発生したのか、均等に分散して発生したのかを測定するカスケードスコアを提供します。価格は 0.05 です。 期間内にテープが記録した銘柄の全範囲を提供し、呼び出し元がデータの有無を把握できるようにします。価格は 0.10 です。 取引所ごとの報告の完全性を提供します。価格は 0.03 です。

5 つ目のルートは履歴を提供します。3 つすべての取引所を対象に、指定した銘柄について、このテープで最初に観測されてから現在までの記録済み清算履歴をすべて返します。時間単位または日単位にまとめられており、価格は 5.00 です。このルート以外では、7 日を超えて遡ることはできません。違いはそれだけです。清算記録は事後に補完できないため、履歴の深さこそが本当に希少な部分です。カバー範囲はテープ全体ではなく銘柄ごとに示されます。ある銘柄が初めて現れるのは、その銘柄で最初の清算が発生した時点であり、テープ自体の開始から数週間後になることもあるためです。また、ペイロードにはその銘柄固有のカバー開始時点が含まれているため、当サービスの開始日が市場の開始日と誤解されることはありません。

すべてのルートを 1 回ずつ呼び出すと、合計で 5.2 USDC かかります。最新の価格は /catalog の sweep_price_usdc で公開されており、手入力ではなくカタログから算出されています。そのため、この記載と食い違う場合はエンドポイントが正しく、このファイルの情報が古くなっています。

Global x402 Challenge の資格要件

Composite プロジェクトとして登録されています。5 つのエンドポイントが、1 つの payTo アドレスの下にあります。

すべてのルートに必須の x402-global-challenge タグが付き、Bazaar 検索用の拡張機能も宣言されています。そのため、このサービスを知らないエージェントでも見つけて、各ルートの料金を確認し、掲載情報だけをもとに有効なリクエストを作成できます。どちらもルートごとに記述するのではなく、compileCatalog と buildRoutes で適用されるため、いずれかのエンドポイントで付け忘れることはありません。また、確認用テストは 1 つのルートを抜き出すのではなく、サービスが応答するすべてのルートを対象に反復するため、どれかのルートからいずれかが抜けるとテストスイートに失敗します。

タグは resource.tags ではなく、リーダーボードが読み取る accepts[].extra に設定されています。ExactAvmScheme はその追加情報を置き換えずにマージするため、アセットの小数桁数や、ファシリテーターが通知する feePayer とともに渡されます。

決済は Algorand メインネット上の GoPlausible ファシリテーターを通じて行われ、支払いはエンドツーエンドで完了しています。現在の件数、それを支える個別の支払者数、決済済みの合計は、このファイルに記載された数字ではなく、レジャー上の数値が正となります。そのため、ここに入力された数字を信頼せず、agentfeed-algo ledger で確認してください。

エージェントから利用する

エンドポイントは URL ですが、これは料金を支払う側が認識できません。そこで、MCP サーバーも提供しています。

npx -y -p @seekdaseek/agentfeed-algo agentfeed-algo-mcp

または、MCP クライアントの設定で、npx -y @seekdaseek/agentfeed-algo を実行し、バイナリ agentfeed-algo-mcp を使う agentfeed-algo という名前のサーバーとして指定します。環境変数は 1 つで、USDC を保有し、アセット 31566704 にオプトイン済みの Algorand アカウントのニーモニックを ALGO_PAYER_MNEMONIC に設定します。

ツールは 6 つあります。4 つは有料で、それぞれ短期間のウィンドウを対象とするルートに対応します。無料のツールは 2 つあります。catalog は販売中のすべての項目と料金を一覧表示し、payer_status は残高と支払いを妨げている要因を報告します。どちらもキーなしで利用できるため、インストールして、提供内容を確認してから、資金を用意するかどうかを決められます。履歴ルートは料金とパスとともに catalog ツールに掲載されますが、専用のツールはありません。

支払いには自分のアカウントを使います。こちらのキーが関与することはなく、アカウントを作成する必要もありません。

測定できなかった応答はデータではなく、ツールエラーとして返されます。HTTP レイヤーはすでにその応答への課金を拒否しますが、ツールの結果を読むエージェントにも同じシグナルが必要です。答えのように見える穴は、答えがないことよりも悪いからです。

支払う価値を生むもの

すべての応答には、それぞれのステータスが付いており、3 種類あります。

測定済みとは、問い合わせを行い、回答を得た状態です。

不在とは、問い合わせを行ったものの、市場に該当するものがなかった状態です。対象のウィンドウ内に清算がなかったことは、市場が静かだったという確かな情報であり、購入者はその情報に基づいて行動できます。

未測定とは、こちらの検索に失敗した状態です。レート制限、ロックされたデータベース、例外が発生したクエリなどが該当します。これは情報が得られたということではなく、情報が得られなかったということです。

未測定の応答は 503 を返し、決済が確認された後に未測定と判明した場合でも、決して課金されません。その意図的な選択により、売上を逃すことになります。エージェントが呼び出しごとに支払う状況では、販売できる最悪の商品は、こちらが作り出したゼロです。呼び出し元には、それが本物のゼロと見分けられないからです。わからないときにそれを明示するフィードは、常に回答するフィードよりも、呼び出しごとの価値が高くなります。

実行する

npm install
npm test
node bin/agentfeed-algo.mjs catalog

設定は環境変数で行います。サンプルをコピーして、値を入力してください。

cp .env.example .env
node bin/agentfeed-algo.mjs doctor
node bin/agentfeed-algo.mjs serve

Doctor は設定、カタログ、ファシリテーターを確認し、各チェックの結果を 1 行ずつ出力します。いずれかのチェックに失敗すると、Serve は起動を拒否します。

メインネットへの移行は偶然ではありません

上記のデプロイ先はメインネットです。そこへ移行するには、ALGO_NETWORK を mainnet に、ALGO_ALLOW_MAINNET を yes に設定するという、意図的な2つの操作が必要です。設定がない場合は、メインネットではなくテストネットにフォールバックします。

これは意図的な設計です。変数を1つ入力し間違えただけで実際のお金を受け取ることがあってはなりません。また、資金を扱う設定にひっそりとデフォルトで切り替わるサービスは、いずれ誰も確認していないアドレスに支払いを受け取ることになります。

メインネットでは、プリフライトで localhost のリソース URL、平文のファシリテーター、テストネットのアセット ID、そしてすべての警告を拒否します。テストネットでは警告があっても処理を続行できます。この非対称性には理由があります。メインネットでは、設定ミスによって、取り消しのできない送金が発生するためです。

payTo アドレスはパターンではなくチェックサムで検証します

Algorand アドレスは、32バイトの公開鍵と4バイトの SHA-512/256 チェックサムを Base32 でエンコードしたものです。長さと文字種を確認する正規表現では、隣接する2文字を入れ替えたアドレスも受け入れてしまいます。チェックサムはそれを拒否します。その動作を確かめるため、2文字を入れ替えるテストもあります。

入力ミスが気づかれないまま実際のお金を失う原因になる項目はこれだけなので、パターンではなく、実際のデコーダーを使っています。

価格は常に BigInt です

USDC は小数点以下6桁です。このサービスの価格はすべてマイクロ USDC の BigInt 値であり、浮動小数点数は使いません。アセットで表現できる桁数を超える価格は、黙って桁数を減らすのではなくエラーにします。そのため、toMicroUsdc("0.0000001") はゼロになるのではなく、例外をスローします。

x402 の価格フィールドにはアセット額を渡し、アセット ID も明示します。これにより、小数が誤ったトークンに対して解釈されることはありません。

誰が支払っているのか

チャレンジでは参加者に支払い元の証明を求めますが、リーダーボードの合計額だけではそれに答えられません。エージェント10体がそれぞれ20回支払う場合と、エージェント1体が200回支払う場合では、合計額は同じでも、事業としてはまったく異なります。

そのため、成功したかどうかにかかわらず、すべての verify と settle をローカルの台帳に追記します。また、概要では合計額よりも集中度を先に示します。

node bin/agentfeed-algo.mjs ledger

データを取り込むフックについて、1つ補足します。この文書を書いた時点では、x402 が onAfterSettle に渡すコンテキストオブジェクトの構造を確認できていませんでした。確認していない構造を断定するのではなく、抽出処理では想定されるフィールドパスを試し、支払者が見つからない場合は null を書き込むのではなく、コンテキストのトップレベルのキーを記録します。2026-08-05 の最初の実際の決済で、誰かが確認できる台帳上に構造が記録されました。コンテキストには paymentPayload、requirements、declaredExtensions、transportContext、result が含まれ、支払者とトランザクション ID は result の下にあります。別のパスも引き続き試します。コストはかからず、構造を変更する権限は上流側にあるためです。

アーキテクチャ

カタログは1つの配列で、ほかのすべてはそこから生成されます。x402 のルート設定、/.well-known/x402 の公開マニフェスト、無料の /catalog 一覧、CLI の出力、テストはすべて同じデータを参照するため、ある場所で価格を変更しても、別の場所に古い価格が残ることはありません。

テープストアは注入可能です。テストはメモリ上の配列を使い、ファイルを開くことはありません。そのため、テープがない場合もクラッシュせず、未計測として扱われます。

ファシリテータークライアントは注入可能です。テストでネットワークにアクセスすることはありません。

テスト

npm test

ネットワークも、実時間の時計も、スリープも使用しません。エンドツーエンドのテストスイートでは、実際の Express アプリを一時ポートで起動し、ペイウォールが有効な場合も含めて実際の HTTP 経由で操作するため、402 の経路が推測ではなく実証されます。

ルートのテストも HTTP 経由で実行します。これは単なる飾りではありません。ハンドラーレベルのテストでは、サーバーが渡していないクエリパラメーターを確認できません。履歴ルートが bucket パラメーターを無視するようになったのは、まさにパラメーターが渡されていなかったからです。ハンドラーは bucket を検証して hourly をデフォルトにしていたため、ハンドラー単体のテストは通っていましたが、サーバーはそのパラメーターを渡さずに呼び出していました。そのため、bucket=day に対しては何事もなかったかのように hourly の結果が返され、無効な bucket に対しても、ハンドラーなら未計測として拒否して課金しないはずのところ、hourly の結果が返されて課金されていました。この問題が潜んでいたのはルーターとハンドラーの間の境界なので、現在はその部分をテストしています。

シンボルは取引ペアであり、カバレッジの欠落は静かな市場ではありません

テープには SOL ではなく、SOLUSDT が保存されています。SOL を要求して 0 件の行が返された呼び出し元に、「SOL の清算はありません」と伝えてはいけません。それは事実を示すものであり、誤りだからです。実際には、その名前のシンボルを一度も取り扱っていません。

そのため、まず解決を行います。単独のシンボルは USDT、USD、USDC の各サフィックスを付けて照合され、解決されたペアと解決方法の両方が返されます。このテープで取り扱っていないシンボルは、理由が symbol_not_covered の未計測として返されます。未計測の結果は課金されないため、カバレッジの欠落によって呼び出し元に費用が発生することはなく、市場の事実として推論に入り込むこともありません。

テープで取り扱っているシンボルで、対象期間内のデータが空の場合、それはデータの欠落です。これは静かな市場についての実際の調査結果なので、通常どおり課金されます。

ファシリテーターがクライアントライブラリとは異なるネットワーク識別子を提示します

ご自身でデバッグする前に知っておくと役立つ情報です。CAIP-2 ではチェーン参照の長さが 32 文字に制限されており、@x402/avm パッケージの定数もそれに従っています。一方、GoPlausible ファシリテーターは Algorand について、パディングを含む 44 文字の完全な base64 ジェネシスハッシュを提示します。同じレスポンス内で Solana は正しく切り詰めた形式で提示しています。

これにより別々の問題が 2 つ発生し、2 つ目のほうが深刻です。

プリフライトでは 2 つの形式を比較し、「ファシリテーターはお使いのネットワークをサポートしていません」という誤った結果が返されます。メインネットでは、実際には存在しない理由でサービスの起動が止まってしまいます。

さらに深刻なのは、@x402/core も独自の機能チェック内で同じ単純な文字列比較を行うことです。その結果、有料ルートはすべて支払いチャレンジを構築できず、サービスは 402 ではなく 503 を返します。本番環境では、誰も支払いができず、エンドポイントが機能しなくなります。エラーには「Facilitator does not support scheme exact on network algorand followed by the truncated identifier」と表示されます。

最初の修正では、境界で形式を正規化しました。ファシリテータークライアントをラップし、core が受け取る前に getSupported が切り詰めた識別子を返すようにしたのです。これで機能チェックは通りましたが、その次の段階である verify 時に失敗しました。ファシリテーターは、自身が提示する識別子、つまり切り詰めていない識別子に対して支払いを検証するためです。切り詰めた形式で構築したチャレンジは、呼び出し元がすでに署名した後で「Network not supported」として返されます。これは起動時に失敗するよりも深刻です。

そのため、設定にはファシリテーター自身が検証に使う切り詰めていない識別子を保持し、支払い処理の経路では一切書き換えません。

この対応への懸念はアセット解決です。@x402/avm の USDC_CONFIG には、切り詰めていない識別子に対応するキーがないためです。しかし、ここでは問題になりません。価格を小数値のまま、ネットワークをキーにしたテーブルで解決することはないからです。価格は ASA ID を明示的に持つアセット額として渡され、@x402/avm の parsePrice は USDC_CONFIG を参照せずに、その金額とアセットを変更せず返します。問題を引き起こすはずの検索処理には到達しません。

これが設定ミスではなく上流のバグだと言えるのは、@x402/avm がすでに 2 つの形式を調整する方法を備えているためです。normalizeAlgorandNetwork はどちらの形式も受け付けて正規形を返し、isAlgorandNetwork は両方を受け入れ、getNetworkFromCaip2 はどちらからでもテストネットまたはメインネットを正しく判別します。仕組み側のパッケージでは対応済みです。core の機能チェックだけが、その処理を呼び出していません。

正規化処理は引き続きコードベースに残し、テストも維持しています。プリフライトが防御的に比較を行うためです。また、将来 core が上流で 2 つの形式を調整するようになったときに、テストが黙ってしまわず、その動作を示せるようにしています。ファシリテーターの実際のペイロード形式を再現し、503 ではなく 402 が返ることを確認するテストがあります。

Algorand x402 を使っていて、有料ルートが 503 を返す場合は、これが原因です。

台帳の既知の制限

台帳への書き込みは、リソースサーバーの verify および settle フックで行われます。不正な支払いヘッダーなど、検証に到達する前に失敗したリクエストは、台帳に記録されません。ファシリテーターとチェーンが正式な記録であり、このファイルはそのコピーです。確認処理まで進んだ支払いについてのみ、記録が完全になります。

もう 1 つの欠落があります。こちらは上流ではなく、こちら側の問題です。これまでに書き込まれたすべてのエントリでは routeId と path が null になっているため、台帳から支払った人、金額、トランザクションは分かりますが、購入したルートは分かりません。抽出処理は requirements.resource や、ほかに考えられるキーからリソース URL を探しますが、実際のコンテキストではまだ見つかっていません。台帳が答えるために存在する問いである、支払者の集中度には影響しません。ただし、現時点ではこのファイルからルートごとの収益は確認できません。

制限事項

テープリーダーは、symbol、exchange、side、ミリ秒単位の ts、usd の各列を含む清算テーブルを想定しています。列名は venue ではなく exchange で、シンボルは SOLUSDT のような取引所ペアであり、SOL のようなティッカー単体ではありません。スキーマが異なる場合、変更が必要なのはストアだけです。

台帳はローカルファイルです。これは真実の複製であり、真実そのものではありません。真実はファシリテーターとオンチェーン上にあります。

カスケードの集中度は、1分間のバケット単位で計算されます。これは無期限先物の清算には妥当な粒度ですが、それ以外では恣意的な粒度です。

正確なスキームのみが登録されています。ほかのスキームを使用するには、それぞれに独自のサーバー実装が必要です。

ライセンス

MIT。