ジェネシス：2026年3月19日

AIネイティブのエージェント向けに構築する。

BTX は AI ネイティブなソフトウェアに特に適した2つの原語を開発者に提供します。入場制御のためのチェーン拘束型の新鮮な作業チャレンジと、エージェント、サービス、オペレーター向けのウォレット支援型ポスト量子アイデンティティです。レガシー署名への依存を減らしたいチームに適しています。

統合ガイド チャレンジ RPC
リクエスト経路
  1. 署名済みエージェント要求
  2. チャレンジ封筒を発行
  3. 新鮮な作業をローカルで解く
  4. 証明を償還して許可
アイデンティティ PQウォレット素材
入場 新鮮な作業証明
検証 解くコストに対して検証は安価
サーフェス RPC + ゲートウェイフロー
ユースケース チャレンジフロー パターン アイデンティティ 起動キット FAQ
なぜ重要か

AI ネイティブ製品には CAPTCHA 以上の入場制御が必要です。

人間専用のチャレンジフローは、自動化システム、API クライアント、オペレーターツールには適しません。BTX のサービスチャレンジを使えば、新鮮な計算を要求できます。大規模自動化には高コストで、検証は安価、しかも現在のチェーン条件に結び付いています。

AIエージェント CAPTCHA

自動化された呼び出し元向けに作られたゲートウェイパターン。

目的は人間をパズルで止めることではありません。目的は、すべての高コスト経路に対して、エージェントや API クライアントがプログラム的に満たせるライブの作業価格を提示し、実行前に安価に検証することです。

APIキーのみ

ルート単位の作業価格付けを伴わないアイデンティティ。

最も得意なこと:
  • 既知の有料ユーザーや安定したサーバー間クライアントには単純で使いやすい。
弱い点:
  • コピーされた資格情報、再販アクセス、あるいは高価なルートでの匿名乱用には弱い。
実際に提供するもの:
  • ルート単位の作業価格付けを伴わないアイデンティティ。
チャレンジフロー

曖昧な未来話ではなく、実用的な開発者ループ。

公開されている OpenClaw のゲートウェイドキュメントはその一例です。クライアントはハンドシェイク時にロールとスコープを宣言し、サーバー提供のチャレンジ nonce に署名し、ロールとスコープに紐づいたデバイストークンを受け取ります。BTX は、そのスタックの上にあるルートレベルの作業要件として、高価または乱用されやすい操作に適合します。 

# Pseudocode: gateway route protected by BTX work
POST /v1/generate
Authorization: Signature keyId="btx-wallet:agent-42",...
X-Device-Token: devtok_...
X-BTX-Challenge-Id: chal_...
X-BTX-Proof-Nonce: ...
X-BTX-Proof-Digest: ...

# Server sequence
1. validate role + scope + device token
2. verify request signature
3. redeem BTX proof for this route
4. only then run the expensive action
保護ルート契約 OpenClaw Gateway Protocol MCP Authorization
チャレンジフロー
  1. 1
    チャレンジを発行する

    getmatmulservicechallenge を使い、新鮮な作業を目的、リソース、主体、目標解決時間に結び付けます。

    関連ドキュメントを開く
  2. 2
    クライアントにローカルで解かせる

    要求者は現在のチェーン状態に結び付いた MatMul 証明を計算するため、事前計算の窓は限定されたままです。

    関連ドキュメントを開く
  3. 3
    償還して検証する

    redeemmatmulserviceproof が証明の有効性、新鮮さ、未消費性を確認したときのみリクエストを受け付けます。

    関連ドキュメントを開く
  4. 4
    アイデンティティを重ねる

    エージェントやサービスが持続的な暗号学的アイデンティティを必要とするとき、BTX ウォレット由来のアイデンティティと署名付きリクエスト標準を上に重ねます。

    関連ドキュメントを開く
サーバーが確認すること
  • purpose・resource・subject が保護したいルートと一致していること
  • 解決時間がクライアントに提示したウィンドウ内に収まっていること
  • 証明が一度だけ償還され、その後リプレイできないこと
  • 持続的なエージェントまたは運用者資格情報のために署名付きアイデンティティを重ねられること
デプロイパターン

BTX が実際の AI とゲートウェイのスタックのどこに収まるか。

ゲートウェイ型システムはすでにデバイスアイデンティティ、ルートポリシー、認可を区別しています。BTX は、その上に新鮮な作業レイヤーを追加し、高価で、スパムを受けやすく、自動乱用から守る価値のあるルートを保護します。

参照アーキテクチャ

自分の製品に合うルート形状から始める。

これは抽象的なペルソナではありません。ゲートウェイ、公開 API、エージェントフローへそのまま持ち込める具体的な BTX チャレンジ形状であり、その後に自分の脅威モデルへ合わせて締めていけます。

AI 推論プロファイル 単一ノード展開

公開 AI 推論 API

推奨バインディング
  • purpose: ai_inference_gate
  • resource: model:gpt-x|route:/v1/generate|tier:free
  • subject: tenant:abc123 または api_key:key-42
チャレンジ方針
  • target_solve_time_s: 無料または匿名トラフィックでは 2-4 秒
  • expires_in_s: 60-180 秒で古いエンベロープの価値を素早く落とす
  • redeem path: リクエストがキュー化または共有ワーカーへ分散するなら redeemmatmulserviceproofs を使う
ドキュメントを開く: AI 推論プロファイル ドキュメントを開く: チャレンジ発行 RPC ドキュメントを開く: バッチ Redeem RPC
本番準備状況

何が今すぐ安全に使え、何にルーティング規律が必要で、BTX の境界がどこにあるかを示す。

BTX のサービスチャレンジは実際の admission-control サブシステムとして扱います。まず単一ノードから始め、実際の判断点で redeem し、この証明が何を示し何を示さないかを明確にします。

今すぐ使える: 単一ノードの保護ルート

文書化されている本番経路は、同じ BTX ノードが同じチャレンジレジストリに対して issue と redeem を行う形です。多くの推論、登録、ゲートウェイルートは、まずこれで十分に運用できます。

スケール時の注意: マルチノードはアフィニティか共有状態が必要

issue と redeem が別の BTX ノードに着地し得るなら、チャレンジレジストリは運用上の依存になります。横に広げても安全と言う前に、sticky routing か共有 challenge ファイルを入れてください。

受け入れ規則: 本番は redeem、診断は verify

verify は証明がチャレンジに一致するかを示すだけです。redeem は proof を一度だけ消費するリプレイ安全な受け入れイベントであり、ゲートウェイに権威ある accept / reject 結果を返します。

保護ルート契約 Redeem RPC マルチノード展開 失敗セマンティクス
アイデンティティ層

最初からポスト量子で始まるウォレット支援型アイデンティティ。

BTX ウォレットはディスクリプタベースで、当初から ML-DSA と SLH-DSA を軸に設計されています。これにより、中核のアイデンティティ素材を後回しの移行案件として扱う可能性を減らせます。

ウォレットを作成する
アイデンティティ層

最初からポスト量子で始まるウォレット支援型アイデンティティ。

  • 最初からポスト量子ウォレット設計 BTX ウォレットはディスクリプタベースで、当初から ML-DSA と SLH-DSA を軸に設計されています。これにより、中核のアイデンティティ素材を後回しの移行案件として扱う可能性を減らせます。
    ソースを見る
  • チャレンジフローは生きた難易度に結び付く サービスチャレンジとマイニング RPC は、乱用価格付けのための生きた作業プロファイル、目標解決ウィンドウ、新鮮なチェーン拘束コンテキストを公開します。
    ソースを見る
  • エージェント協調サービス向けに構築されている プロトコル文書はすでに、BTX を単一の共有ランタイムではなく、ブリッジ、サービス、エージェント協調レイヤーの上にある狭い決済基盤として位置付けています。
    ソースを見る
設計方針

AI チームに BTX をどう説明すべきか。

  • 署名付きリクエストが呼び出し元を識別する。
  • BTX の作業チャレンジが乱用とレート圧力に価格を付ける。
  • PQ ウォレット素材が呼び出し元により強い長期アイデンティティ前提を与える。
  • それらを合わせることで、エージェントツール、API、ゲートウェイフローのためのより持続的な入場スタックができる。
標準とエコシステム

スタック全体が、より強いエージェントアイデンティティとチャレンジフローへ進みつつあります。

2024-08-13

NIST が最初の PQC 標準を確定

BTX は、標準の世界がすでに進み始めている方向から出発している。ポスト量子署名と、後ではなく今の移行圧力である。

 RFC 9421 / 9449

署名付きリクエスト標準は十分に成熟している

HTTP Message Signatures と DPoP は、認証済みで proof-of-possession 的な API トラフィックに対する強い標準隣接フレームを提供する。
標準とエコシステム
2025-03-26

MCP は本物の認可と安全性の課題をエージェントツールへ持ち込む

エージェントシステムには今や適切な認可、スコープ付きアクセス、安全なツール利用が必要であり、BTX はその周囲の作業・アイデンティティ層として適合する。

 OpenClaw

ゲートウェイ型エージェントシステムは既に署名済みデバイス素材を使っている

OpenClaw のゲートウェイドキュメントは、署名済みデバイストークンとスコープ対応ロールを示している。BTX は高リスクルートに新鮮な作業要件を重ねて補完できる。

 2025-09-18

NIST は組織に今すぐ PQC 移行計画を始めるべきだと述べる

NCCoE の CSWP 48 草案は、PQC 移行を将来の節目まで先送りする課題ではなく、今のガバナンスと統制マッピングの課題として捉えている。
開発起動キット

まずルートを作り、次に運用を固める。

これらの束は、API チームがよく辿る順番でドキュメントを並べています。チャレンジルートを試作し、アイデンティティを結び付け、制御プレーンへ載せ、実運用の状態を監視します。

ライブチャレンジを発行して償還する

最小の有用なループから始めます。チャレンジを発行し、解き、守りたいルート上で償還します。

コアフローガイド getmatmulservicechallenge RPC
開発者 FAQ

BTX の challenge flow を試作するときにチームが確認すること。

ここでの回答は、現在の RPC とウォレットのドキュメントに沿っています。BTX は既存の認証を補完し、高価なルートに新鮮な work pricing を追加し、AI ネイティブなシステムに post-quantum identity の経路を与えます。

BTX は API キー、OAuth、またはゲートウェイのポリシーを置き換えますか？

いいえ。BTX は既存の認証スタックを補完するときに最も効果を発揮します。identity、scope、policy はそのまま維持し、乱用、コスト、リソース競合が重要なルートにだけ BTX work を求めてください。

関連ドキュメントを開く
challenge は AI やエージェントのワークフローのどこに入りますか？

通常は通常の request identification の後で、高価なアクションが走る前です。サーバーが live challenge envelope を発行し、呼び出し側がそれを解き、サービスが GPU 時間やモデル枠などの希少資源を使う前に proof を redeem します。

関連ドキュメントを開く
なぜウォレットベースの post-quantum identity をこの流れに入れるのですか？

BTX では、同じシステムの中で fresh work とより強い signing material を一緒に扱えます。すでに post-quantum 移行を計画しているチームにとって、identity と admission を別々の将来課題ではなく一緒に評価しやすくなります。

関連ドキュメントを開く
OpenClaw や MCP 系のゲートウェイスタックにも合わせられますか？

アーキテクチャ上は可能です。既存の role、scope、device trust モデルを維持したまま、BTX を route-level work requirement として重ねます。これはこのページで説明している適合の話であり、BTX が現在 native な OpenClaw 統合を提供しているという主張ではありません。

関連ドキュメントを開く
次の一歩

製品に乱用問題、無料層、またはエージェント層があるなら、BTX は設計レビューに入るべきです。

サービスチャレンジガイドから始め、ウォレットモデルを読み、アイデンティティと作業の両方を要求するエージェント安全なルートを試作してください。

フローを構築する BTX を見る