RoundWatch

RoundWatch

自律型 x402 ワークフロー向けの、堅牢な Algorand USDC 決済モニタリング。

ウェブサイト · クイックスタート · 技術ガイド · 稼働中の API · OpenAPI · llms.txt · MCP レジストリ · アーキテクチャ

RoundWatch は、トランザクション ID がまだ存在しない、将来の特定の Algorand MainNet USDC 決済を監視します。呼び出し元は期待する決済を定義し、x402 のサービス料金を一度支払って、永続的な監視 ID を受け取った後、処理を終了できます。RoundWatch は支払い義務とスキャンの進捗を永続化し、後から取得できる検証済みのオンチェーン証拠を提供します。

本番環境： Algorand MainNet · Circle USDC · x402 v2 · GoPlausible ファシリテーター · Bazaar メタデータ公開中（カタログでの表示は再審査中） · リモート MCP エンドポイント · 再起動後の永続的な復旧。

解決する課題

短時間だけ実行されるエージェント、ジョブ、またはサービスは、呼び出し元が実行を停止した後に特定の決済が届いたかどうかを確認する必要がある場合があります。永続的なオブザーバーに待機を任せられるなら、呼び出し元を稼働させたまま Algorand Indexer をポーリングする必要はありません。

RoundWatch を使うと、呼び出し元は期待する決済を定義し、x402 経由で監視を 1 件購入して、処理を終了できます。サービスは支払い義務を永続化し、Algorand のスキャンを続け、一致するトランザクションを後から取得できるよう記録します。

永続的な Indexer またはサブスクライバーのインフラストラクチャーをすでに運用しているバックエンドであれば、これを自ら実装するのが妥当な場合もあります。RoundWatch は、その運用コンポーネントを自ら管理したくない呼び出し元向けです。

ライフサイクル

1. クライアントが、期待する送信元、受信先、アトミック単位の金額、および任意の請求書メモを正確に送信します。
2. x402 が決済要件を返し、クライアントがサービス料金への署名をローカルで行います。
3. GoPlausible がサービス料金を検証し、決済を確定します。
4. RoundWatch は、サービス料金のトランザクションが正確に確認された後にのみ、永続化された監視を有効化します。そのトランザクションの確認済みラウンドがスキャンの基準点になります。
5. RoundWatch が Algorand Indexer をポーリングしている間、呼び出し元は処理を終了できます。
6. 将来の USDC アセット送金が正確に一致すると、監視状態が matched になります。
7. 呼び出し元は GET /v1/watch/:id で永続的な結果を読み取ります。

通常の処理、復旧、および照合の流れについては、アーキテクチャを参照してください。

準備状態、バックアップ／復元、保持、およびインシデント対応手順については、運用を参照してください。

現在の製品方針と優先順位については、ロードマップを参照してください。

本番サービスの稼働状況

プロパティ	現在の値
API	https://roundwatch-api.onrender.com
監視の作成	POST /v1/watch
監視の読み取り	GET /v1/watch/:id
稼働確認	GET /health
準備状態	GET /ready
ネットワーク	Algorand MainNet
CAIP-2	algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=
アセット	Circle USDC、ASA 31566704
サービス料金	0.10 USDC（原子単位で 100000）
サービス受取先	EQPLN32HPLPGBCNPOZUL6BL34CTNQGT3VAAMNAJWSIZGQ5CUNXOHB634XY
Facilitator	https://facilitator.goplausible.xyz
ホスティング	Render。永続的な SQLite ストレージを /data にマウント
適格性の期限	永続化された作成から30分。終端状態の expired となるには、固定された終了チェックポイントまでの検証済みチェーン情報が完全に揃っている必要があります
作業予算	監視ごとに永続化されるバックグラウンド作業500ターン。予算を使い切ると indeterminate で終了し、expired にはなりません
未解決の義務の上限	全体で50件、検証済みサービス支払者ごとに5件

本番サーバーにウォレットのニーモニックや秘密鍵は含まれておらず、必要もありません。

Economics v1 は、0.02 USDC（原子単位で 20000）の価格で 80ed94c746f2eac4a784a3738c6dbe8306ecfa3e とともに2026-09-20にデプロイされました。2026-09-29に、30分の監視時間と500ターンの作業予算を変更せずに、公開サービスの契約料金を 0.10 USDC（原子単位で 100000）に改定しました。以下の過去の有料証明には、それぞれの証明が収集された時点で適用されていた価格が記載されています。

API

ヘルスチェックと準備状態

GET /health は稼働確認専用です。永続サービスが有料トラフィックを受け入れる準備ができているかどうかを判断するには、GET /ready を使用してください。Render のプラットフォームヘルスチェックでは /ready を対象にする必要があります。/health は軽量なプロセス稼働確認用エンドポイントとして維持し、有料トラフィックを受け入れる準備状態のシグナルとして使用しないでください。

GET /health

本番環境の応答：

{
  "status": "ok",
  "purpose": "liveness",
  "network": "mainnet"
}

準備状態：

GET /ready

準備ができている本番インスタンスは、HTTP 200 を返します。

{
  "status": "ready",
  "network": "mainnet",
  "checks": {
    "storage": true,
    "backgroundWorkers": true
  }
}

ウォッチを作成する

POST /v1/watch
Content-Type: application/json

リクエスト本文の例：

{
  "idempotencyKey": "invoice-2026-09-16-001",
  "expectedSender": "3YFZ47IAKPB4H6B7U6MXI35HCAB5E6DA47UANIHOON53J7I5SMXUSYQXQQ",
  "expectedReceiver": "EQPLN32HPLPGBCNPOZUL6BL34CTNQGT3VAAMNAJWSIZGQ5CUNXOHB634XY",
  "atomicAmount": "1",
  "invoiceNote": "roundwatch:invoice-2026-09-16-001"
}

通常のリクエストには 402 Payment Required が返されます。x402 対応クライアントは支払い要件を読み取り、提示されたサービスへの支払いに署名して、同じリクエストを再試行します。RoundWatch は、決済と永続的な有効化が成功した後にのみ成功を返します：

{
  "watchId": "f5d2fb6f-b224-4aae-989c-87a5418fd2ae",
  "workUnitBudget": 500,
  "eligibilityTtlMs": 1800000,
  "expiresAt": "2026-09-16T12:30:00.000Z",
  "message": "The watch is returned only if x402 settlement and durable activation succeed"
}

リクエストフィールド：

フィールド	必須	ルール
idempotencyKey	はい	8〜128 文字の文字列です。サービスデータベース全体で一意である必要があります。同じキーを再利用すると、既存の公開ウォッチレコードとともに HTTP 409 が返され、2 つ目のウォッチは有効化されません。
expectedSender	はい	新しいウォッチの作成には、チェックサムが有効な、ゼロではない 58 文字の Algorand アドレスが必要です。新しいウォッチでは Algorand のゼロアドレスは拒否されます。従来の支払い済みレコードを厳密に復旧する場合は、意図的に制限を緩和しています。
expectedReceiver	はい	チェックサムが有効な 58 文字の Algorand アドレスです。将来の請求支払いの受取人であり、必ずしも RoundWatch サービスの受取人とは限りません。
atomicAmount	はい	JavaScript の最大安全整数（9007199254740991）以下の正の整数文字列です。小数点以下 6 桁の USDC では、1000 は 0.001 USDC を意味します。
invoiceNote	いいえ	完全一致する UTF-8 ノートです。指定する場合は 1〜128 バイトです。

監視対象のアセットはリクエストフィールドではありません。サーバーは明示的なネットワーク設定から USDC ASA を選択します：MainNet ASA 31566704 または TestNet ASA 10458941。

サーバーは有効期間、処理予算、受付ポリシーを管理します。購入前に、RoundWatch は 30 分の有効期間と 500 ターンのバックグラウンド処理予算を提示します。有効期間のカウントは、x402 の決済が完了する前に永続的な債務が準備された時点で始まるため、決済の遅延によって 30 分の有効期間の一部が消費されます。呼び出し側がいずれかの上限を変更することはできません。実時間の期限を過ぎただけでは、ウォッチは期限切れになりません。証明には、終了チェックポイントまでの完全なチェーン網羅が必要です。処理予算が先に尽きた場合、ウォッチは indeterminate として終了し、誤って expired とすることはありません。未完了の債務は全体で最大 50 件まで、検証済みのサービス支払者ごとに最大 5 件まで開くことができます。容量の上限に達した場合、決済前に HTTP 429 が返されます。

ウォッチを読み取る

GET /v1/watch/f5d2fb6f-b224-4aae-989c-87a5418fd2ae

レスポンスは { "watch": ... } です。この簡略化した一致例では、利用者向けの安定したフィールドを示しています。実際のレコードでは、利用可能な場合、決済およびスキャンのメタデータも公開されます：

{
  "watch": {
    "id": "f5d2fb6f-b224-4aae-989c-87a5418fd2ae",
    "state": "matched",
    "expectedSender": "3YFZ47IAKPB4H6B7U6MXI35HCAB5E6DA47UANIHOON53J7I5SMXUSYQXQQ",
    "expectedReceiver": "EQPLN32HPLPGBCNPOZUL6BL34CTNQGT3VAAMNAJWSIZGQ5CUNXOHB634XY",
    "assetId": 31566704,
    "atomicAmount": "1",
    "invoiceNote": "roundwatch:invoice-2026-09-16-001",
    "createdAt": "2026-09-16T12:00:00.000Z",
    "expiresAt": "2026-09-16T12:30:00.000Z",
    "matchedTransaction": "VZKWYELPR4HHXPXM476NRLNU4JUKAEUUD4HGHFNAHDRD5IBFB2MA",
    "matchedRound": 65096073
  }
}

不明な ID には HTTP 404 が返されます。

ウォッチの状態

状態	意味
settlement_pending	ウォッチの仕様と決定論的なサービス支払い ID は永続化されていますが、有効化はまだ証明されていません。照合処理により、決済または有効化中のクラッシュから復旧できる場合があります。
active	サービスへの正確な支払いトランザクションが確認されました。その確認ラウンドが有効化の基準点および初期スキャンカーソルとなります。ポーラーは将来の請求支払いを検索しています。
matched	条件に完全一致する将来のアセット転送が見つかりました。一致したトランザクション ID と確認ラウンドが保存されています。
settlement_unknown	決済によって、すぐに利用可能な有効化は行われませんでした。settlementReconciliationTerminal=false は、厳密な照合によって復旧できる可能性があることを意味します。true は、照合が最終的なフェイルクローズの結果に達し、再試行しないことを意味します。
expired	完全な有効チェーン範囲が、固定された終了チェックポイントまでスキャンされましたが、完全一致はありませんでした。終了したレコードも引き続き読み取れます。
indeterminate	RoundWatch は、一致の確認も期限切れの完全な証明もないまま停止しました。terminalReason=work_budget_exhausted は、ウォッチごとに永続化された処理予算を使い切ったことを意味します。terminalReason=indexer_permanent_failure は、ポーリング中に、ウォッチ固有の Indexer による再試行不能と判定された拒否が発生したことを意味します。いずれの結果も、監視対象の支払いが存在しなかったとは断定しません。

完全一致

トランザクションは、設定されたすべてのプロパティが一致した場合にのみ一致します。

• 送信者
• 受信者
• ネットワークに応じて選択された USDC ASA
• アトミック単位の金額
• リクエストに指定されている場合は請求メモ

確認済みのサービス支払いラウンドより後にある、確認済みのトップレベルの直接アセット転送のみが対象です。適格性の境界は confirmed-round > activationRound および round-time < expiresAt であり、同じラウンドの請求は対象外です。また、ブロックのタイムスタンプが期限と完全に一致する場合も対象外です。送信者、受信者、ASA、アトミック単位の金額、および任意のメモが一致する必要があります。内部トランザクション、クローバック転送、アセットのクローズアウト転送は、現在の RoundWatch の照合契約の対象外であり、請求への支払いとしてカウントされません。処理時間は適格性に影響しません。

x402 による支払いと復旧

Hono リソースサーバーは、x402 v2 とホスト型の GoPlausible ファシリテーターを使用します。決済前に、RoundWatch は、検証済みの署名済みペイロードから導出した、決定的な Algorand サービス支払いトランザクション ID と、不変の受信者、ASA、アトミック単位の金額、支払者、FirstValid、LastValid の各条件を永続化します。決済後、正確な Indexer 検索によって確認済みサービス支払いラウンドが取得され、このラウンドが有効化の基準点と初期カーソルの両方になります。

オンチェーンでの決済後、アクティベーションの確定前にプロセスが停止した場合、調整ワーカーは、永続化された指数バックオフに従って該当するトランザクションを検索します。有効化されるのは、元の不変条件が一致する場合のみです。単なる 404 は再試行可能です。終端的な未払いを確定できるのは、LastValid 以降の履歴を十分にカバーする不在検索だけです。確定的な不一致があった場合は、フェイルクローズします。ID を指定しない無料の復旧検索では、正確な未解決チェックポイントに対して、retryable／terminal、安定した理由、次のアクションのメタデータを明示的に返しながら、監視 ID の開示境界を維持します。

すべての Indexer 呼び出しは、1 つのトークンバケット／同時実行ディスパッチャーを共有します。スキャンでは有限のラウンド範囲とページ単位の検証を行い、各ページと再試行は容量を消費します。各永続作業ターンにはさらに上限が設けられており、アクティブなポーリングでは最大 4 回、決済の調整では最大 3 回の論理的な Indexer リクエスト機会に制限されます。そのため、既定の 500 ターン契約では、バックグラウンドリクエストの保守的な上限は 2,000 回です。JSON の解析前に Indexer のレスポンスボディを 8 MiB に制限し、継続トークンを 4 KiB に制限するため、不正な上流や悪意のある上流によってパーサーやトークンのメモリが無制限に割り当てられることはありません。宣言サイズによる拒否、許可された 404、その他の OK 以外のステータスのためにレスポンスボディが消費されない場合、ディスパッチャーのスロットを解放する前に明示的にキャンセルします。検証済みの履歴スキャンページはスイープ間で再利用できますが、プロセス内の LRU はエントリー数とシリアライズ済みペイロードのバイト数の両方で上限を設けています。ページネーショントークンはメモリ内に保持されるため、再起動時には未完了のウィンドウが永続カーソルから再実行されます。期限が過ぎると、RoundWatch はタイムスタンプが期限以降のインデックス済みブロックを closingRound として固定します。このラウンドまでの完全な検証済みカバレッジがある場合にのみ、expired にできます。ステータスの読み取りによって、壁時計の時刻から期限切れが生成されることはありません。

ローカル開発

必要なもの：

• Node.js 24；
• pnpm 12.3.4（ワークスペースで宣言）；および
• 有料のローカルフローを意図的に試す場合のみ、TestNet アカウント。

依存関係をインストールします：

pnpm install --frozen-lockfile

apps/server/.env.example を apps/server/.env にコピーし、公開 TestNet 受取人アドレスを設定します：

ROUNDWATCH_NETWORK=testnet
AVM_ADDRESS=<public TestNet receiver address>
FACILITATOR_URL=https://facilitator.goplausible.xyz
ROUNDWATCH_DB_PATH=data/roundwatch.sqlite
ROUNDWATCH_POLL_INTERVAL_MS=5000
ROUNDWATCH_RECONCILE_INTERVAL_MS=5000
ROUNDWATCH_WATCH_TTL_MS=1800000
ROUNDWATCH_MAX_OPEN_WATCHES=50
ROUNDWATCH_MAX_OPEN_WATCHES_PER_PAYER=5
ROUNDWATCH_WORK_UNIT_BUDGET=500
ROUNDWATCH_INDEXER_REQUESTS_PER_SECOND=4
ROUNDWATCH_INDEXER_BURST=4
ROUNDWATCH_INDEXER_CONCURRENCY=2
ROUNDWATCH_SCAN_ROUND_WINDOW=100
ROUNDWATCH_SCAN_PAGE_CACHE_ENTRIES=16
ROUNDWATCH_SCAN_PAGE_CACHE_BYTES=8388608
ROUNDWATCH_SCAN_QUERY_VARIANT=C
ROUNDWATCH_MIN_FREE_DISK_BYTES=67108864
PORT=4021

次に、サーバーを起動します：

pnpm dev:server

無料のチェック：

curl -i http://localhost:4021/health
curl -i http://localhost:4021/ready
curl -i -X POST http://localhost:4021/spike/watch \
  -H "content-type: application/json" \
  --data '{"idempotencyKey":"local-invoice-001","expectedSender":"3YFZ47IAKPB4H6B7U6MXI35HCAB5E6DA47UANIHOON53J7I5SMXUSYQXQQ","expectedReceiver":"EQPLN32HPLPGBCNPOZUL6BL34CTNQGT3VAAMNAJWSIZGQ5CUNXOHB634XY","atomicAmount":"1"}'

有料の監視を受け付ける前に、レディネスリクエストが HTTP 200 を返す必要があります。この判定は、キャッシュされた SQLite の書き込み／ロールバックプローブ、ポーラーとリコンサイラーの最新の機能的な Indexer の証拠、ワーカーの停止検出、およびファイルシステムの空き容量の下限に基づきます。起動時は、読み取り専用の Indexer プローブを制限時間内に実行して健全性を確認するまで、レディネス状態になりません。顧客の処理サイクルが空の場合、レディネス状態にはなりません。レディネス状態でないサービスは、x402 の検証前にウォッチ作成リクエストへ HTTP 503 を返します。最後のリクエストは、支払い前に HTTP 402 を返す必要があります。サーバーのデフォルトのローカルルートは /v1/watch の本番ルートではなく、/spike/watch です。

有料の TestNet ユーティリティは apps/client/.env を使用し、署名処理はクライアントプロセス内で行います。ローカル開発に、資金のある MainNet のニーモニックを使用しないでください。また、.env ファイルをコミットしないでください。自動テストスイートではウォレットは不要で、支払いも行いません。

TestNet と MainNet の分離

設定	TestNet	MainNet
選択	省略時のデフォルト、または ROUNDWATCH_NETWORK=testnet	ROUNDWATCH_NETWORK=mainnet の設定が必須
ウォッチルート	/spike/watch	/v1/watch
USDC ASA	10458941	31566704
CAIP-2	algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=	algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=
ディスカバリータグ	roundwatch-spike-0	x402-global-challenge
公開ベース URL	任意	HTTPS および非ループバックが必須
データベースパス	ローカルのデフォルトを許可	永続化される明示的な絶対パスが必須

MainNet を運用する前に、デプロイを参照してください。

テストと CI

ローカル検証スイートを実行します：

pnpm typecheck
pnpm -C apps/server test
pnpm -C apps/client test
docker build -t roundwatch-local .

GitHub Actions は、リポジトリへの読み取り専用権限で実行され、サードパーティのアクションと Gitleaks イメージを変更不可能なリビジョンに固定し、全履歴を対象にスキャンを実施し、サンプル以外の追跡対象 .env ファイルを拒否します。また、固定されたロックファイルからインストールし、本番依存関係に対する High／Critical の勧告を監査し、両方のワークスペースを型チェックし、サーバーと MainNet の安全性テストを実行して、本番イメージをビルドします。Dependabot は npm／pnpm の依存関係と GitHub Actions の両方を監視します。テストは合成的かつ読み取り専用であり、MainNet での支払いを許可するものではありません。

セキュリティモデル

• ウォレットによる署名はクライアント側で行います。リソースサーバーに必要なのは、公開されている受取人アドレスだけです。
• MainNet の起動時に、ネットワーク、受取人アドレス、HTTPS エンドポイント、公開ベース URL、永続データベースのパスを検証します。
• サービスの決済は、復旧を有効化する前に、オンチェーンの正確なフィールドと照合して整合性を確認します。
• 今後の請求書との照合は完全一致で行い、安全なラウンドカーソルがない場合は有効化を開始しません。
• 冪等性キーに対する SQLite の一意性制約により、監視の重複作成を防ぎます。
• トランザクションによる全体および支払者ごとの受付制御と、共有の有限な Indexer ディスパッチャーによって、永続処理と外部処理を制限します。容量超過による拒否は決済前に行われます。
• MCP と無料の復旧 POST には、本文の解析前にそれぞれ独立した匿名リクエスト受付制御を適用します。MCP のバージョン、エンベロープ、ツール引数の検証では、寛容な型変換ではなく、サポート対象の最新およびレガシー契約に従います。
• .env ファイルとウォレットの機密情報をコミットしてはなりません。CI では、追跡対象の環境設定ファイルと、全履歴を対象とする秘密情報のチェックを実施します。

ステータス API は認証された保管庫ではありません。監視 ID を知っている人なら誰でも、その公開レコードを照会できます。ステータスやその他の監視固有のレスポンスには Cache-Control: no-store を使用します。機密情報を invoiceNote に記載したり、RoundWatch のメタデータを秘密情報の保管場所として使用したりしないでください。/health は稼働状態のみを確認します。有料トラフィックを流す前に、永続ストレージとバックグラウンドワーカーの準備状況を確認するには /ready を使用してください。チャレンジリリースでは、運用担当者が意図的にメンテナンスを行うまで、終端状態の行を保持します。公開削除 API はありません。信頼境界と運用手順については、セキュリティ と 運用 を参照してください。

MainNet の実証

本番フローは 2026-09-16 に正常に実行されました。

• x402 サービスの決済：OJMUUHJPZVXS6MNW4TISXXAZIHAPNYNM446DAFY35OAJOBDDOPYA、確定ラウンド 65095955；
• 永続ウォッチ：7c606f02-0257-4dfd-b59c-a13b61f480f0；
• 後続の請求書送金：VZKWYELPR4HHXPXM476NRLNU4JUKAEUUD4HGHFNAHDRD5IBFB2MA、確定ラウンド 65096073；
• RoundWatch は、同じ請求書トランザクションをラウンド 65096073 で一致として報告しました。

独立した MainNet Indexer による検証では、両方の送金で Circle USDC ASA 31566704、想定された送信者と受信者が使用され、アトミック単位の金額はサービス決済が 1000、監視対象の請求書が 1 であることが確認されました。一致したウォッチは、複数回の Render 再デプロイ後も保持されました。

最初の MainNet 実証後、本番サービスには、正確性とリソース管理をさらに強化する大規模な変更がマージされました（18e8712431bc02a904dd5a3f227b2f5a49e9f6f7）。このリリースでは、壁時計のみを基準とする有効期限を、チェーン時刻に基づく適格性と固定の終了チェックポイントに置き換え、確定したサービス決済ラウンドを正確に基準としてウォッチを有効化し、共有ディスパッチャーを通じてすべての Indexer 処理に上限を設け、ウォッチ全体に公平で上限付きの処理を追加し、決済の照合とページネーションの検証を強化しました。Render はこの変更を正常にデプロイし、無料の本番スモークテストでは、想定どおりの MainNet ヘルス、x402 402、ステータスの動作が返されました。

続く本番修正（d05fabaea6124ed5658dd13cf06167a885aefeb0）では、無効な Bazaar の例示用受信者をチェックサムが有効な Algorand アドレスに置き換え、回帰テストを追加しました。デプロイ後に外部から実行した 402 スモークテストでは、稼働中の payment-required ヘッダーをデコードし、本番 URL、MainNet ネットワーク、exact スキーム、ASA 31566704、金額 1000、チェックサムが有効な Bazaar の例示用アドレスを検証しました。これらの強化リリース後に、2 回目の有料 MainNet E2E を実施したわけではなく、実施したことを示唆するものでもありません。

GoPlausible Bazaar は 2026-09-16 に本番リソースを検出しており、URL、ネットワーク、アセット、金額、受信者、チャレンジタグは正しく、settleCount: 1 でした。その時点で、加盟店のランキング項目には bazaar: true、challenge: true、settles: 1、volume: 0.001 と表示されていました。これは過去の証拠であり、カタログに恒久的に掲載されることを保証するものではありません。

2026-09-24 に新たに実施した適格性確認では、当初 RoundWatch リソースが見つからないと報告されましたが、生のカタログデータを調査した結果、パーサーの誤りが修正されました。GoPlausible は本番 URL と完全に一致する値をトップレベルの resourceUrl フィールドに保存しています。リソースは存在しますが、保存された決済条件と検出条件は、当初の 1000 アトミック（0.001 USDC）の契約から更新されていません。2026-09-24 に新たに承認済みの 0.02 USDC 決済を行ったところ、同じカタログレコードの lastSeen と settleCount は更新されましたが、保存された accepts の金額は、その時点で有効だった 20000 アトミックの価格に更新されませんでした。そのため、2026-09-29 の価格改定後に、カタログの適格性を改めて確認する必要があります。

詳細な証拠については、MainNet の準備状況を参照してください。

現在の制限事項

• 現在のチャレンジ解放ポリシーは、適格性判定の期限が30分、永続処理の上限が500ターン、グローバルな未完了義務の上限が50件、検証済みサービス支払者ごとの未完了義務の上限が5件です。これらは運用上の安全上限であり、商用 SLA や最終的な価格・容量ポリシーではありません。
• キャンセル操作、SLA、長期的な価格ポリシーはありません。
• 現在のデプロイは、プロセス内ポーラー／リコンサイラーとローカルの永続 SQLite を備えた単一アプリケーションインスタンスです。水平方向に協調するワーカーシステムではありません。
• 各ポーリングスイープでは、アクティブな各ウォッチに対して、上限付きの処理ターンを最大1回実行します。ページネーションはスイープ間で処理を譲り、FIFO の Indexer ディスパッチによってグローバルなリクエスト上限を適用します。これらの調整値は SLA でも、任意の規模に対応するという主張でもありません。
• 結果はポーリングで取得します。Webhook やプッシュ通知 API はありません。
• ウォッチ ID を知っている人なら誰でも、認証なしでウォッチのステータスを読み取れます。

リポジトリの構成

.
├── apps/
│   ├── server/              # Hono API, x402 integration, SQLite, Indexer workers
│   └── client/              # TestNet utilities and guarded MainNet verification runner
├── docs/
│   ├── ARCHITECTURE.md
│   ├── DEPLOYMENT.md
│   ├── MAINNET_READINESS.md
│   ├── OPERATIONS.md
│   ├── SECURITY.md
│   ├── FAULT_INJECTION.md
│   └── ROUNDWATCH_SPIKE.md
├── .github/workflows/ci.yml
├── Dockerfile
└── README.md

TestNet 開発の過去の記録は、RoundWatch Spike と Fault Injection に残っています。現在の製品と本番環境の契約については、このドキュメントと、上記でリンクされている4つの運用ドキュメントで説明しています。