原文
ReceiptOS: a portable proof substrate for verifiable agent execution — pipavlo82 (2026-07-01)
ReceiptOS: 検証可能なエージェント実行のためのポータブルな証明基盤
このスレッドの目的
ERC-8312 (制限付きエージェントアクション)、ERC-8313 (プロトコルインタラクションマニフェスト)、ERC-8294 (ERC-8004用検証ネットワーク)、そしてWYRIWE (What You Read Is What You Execute)の入力コミットメントに関するスレッドに続き、それらすべての源流となる重要なピースが欠けています。それは、単一のエージェントアクションに対するレシートは実際にどのようなものか、そしてそれを生成したシステムを信頼することなく、どのように検証できるのかという問いです。
ReceiptOSは、この問いに答えようとしています。このカテゴリで形成されつつある構成スタック（8001は権限を記録し、8312はそれを計測し、8275は決済し、8294は検証し、8313はインタラクションを記述し、WYRIWEは入力をバインドする）に明示的に接続するために、これを投稿します。
問題点
今日のエージェントフレームワークはすべて、独自の形式で独自のアクションをログに記録しており、その信頼性はフレームワークのバックエンドを信頼する程度にすぎません。ツール、エージェント、またはチェーン間を移動しても存続する、「このエージェントがこのアクションを実行した、ここにその証拠がある、自分で検証せよ」というポータブルで再計算可能な単位が存在しません。コーディングエージェント、ウォレット、または実行基盤を交換すると、来歴の追跡 (provenance trail) も一緒に移動しません。
アプローチ：エビデンスカプセルモデル
ReceiptOSは、すべてのエージェントアクションを、再計算可能なレシートを生成する定義済みパイプラインを通過するものとして扱います。
- キャプチャ (Capture) — アクションとその入力/出力は、実行時点でキャプチャされます（エージェントに依存しない; 現在、Claude Code用のアダプターが存在し、Codex CLI / Cursor用のアダプターは、本番環境対応ではないスキーマのスケッチとして正直にラベル付けされています）。
- 規範化 (Canonicalize) — カプセルは規範形式に還元され、シリアライゼーションの癖に関わらず、同じアクションは常に同じ方法でハッシュされます。
- アンカー (Anchor) — 規範ハッシュは外部にアンカーされます（アンカーメカニズムに依存しない — アンカーは固定されたチェーンやサービスではなく、プラグイン可能なターゲットです）。
- 検証 (Verify) — 誰でも生のカプセルからハッシュを再計算し、最初にレシートを生成したバックエンドを信頼することなく、アンカーと照合してチェックできます。
このアプローチは、3つのアーキテクチャの軸によって推進されます。
- アクションタイプに依存しない (Action-type agnosticism) — レシートは、それが記述しているアクションの種類（取引、コード編集、コントラクト呼び出し）を想定しません。
- プラグイン可能なポリシー境界 (Pluggable policy boundary) — 有効/完全なカプセルと見なされるものはプロトコルではなくポリシーであり、デプロイメントごとに交換可能です。
- アンカーメカニズムに依存しない (Anchor-mechanism agnosticism) — cap-cursorスレッドでTMerliniが提起したのと同じ特性です。アンカーは実装の選択であり、それ自体ではありません。
現在の稼働状況
crystal-receipt— コア基盤（規範化、カプセルスキーマ、アンカリング）。Stealth（機密性の高いコーディングエージェントデスクトップアプリ、opencodeのフォーク） — レシートレイヤーを統合し、実際のコーディングエージェントセッションからのエビデンスをアンカーします。Chronicle— ReceiptOSの上位にある履歴蓄積レイヤーで、アンカーされたレシートをクエリ可能な履歴レコードとして具体化します。
Stealthセッション → エビデンスキャプチャ → アンカー → Chronicle具体化というエンドツーエンドのパスを検証しており、各ステップで独立して再計算可能です。
これがこのカテゴリで形成されつつあるスタックにどうマッピングされるか
- 8001は、エージェントが行動する権限を持つことを記録します。ReceiptOSはこのレイヤーには触れません — 上流に何らかの権限レコードが存在することを前提としています。
- 8312は、どれだけの権限が消費されたかを計測し、オンチェーンで強制され、状態から独立して再導出可能です（8312スレッドのキャップ保存パターン）。
- **8313 (PIM)**は、プロトコルと正しくインタラクトする方法（実行レシピ）を記述します。エージェントがPIMを使用してトランザクションを構築した場合、それはまさにReceiptOSカプセルがキャプチャしてハッシュすべき種類のものであり、検証者はキャップが尊重されただけでなく、正しいインタラクションパターンが守られたことをチェックできます。
- **WYRIWE**は、コミットされた入力ハッシュを、実行前にエージェントが実際に推論した内容にバインドします。これはReceiptOSの規範化ステップと精神的に近く、どちらも「エージェントが実際に何を見た/行ったか」を自己申告ではなく独立して再計算可能にしようとしています。違いはスコープです。WYRIWEは入力コミットメント境界に特化しており、ReceiptOSはアクション全体のための汎用カプセル形式を目指しており、WYRIWEスタイルの入力ハッシュはそのフィールドの1つになり得ます。
- 8294は、経済的または評判上の結果を伴う検証者ネットワークを介して出力を検証します。ReceiptOSレシートは、検証者が照合してチェックする自然な成果物です — それは検証される再計算可能なクレームです。
- 8275（8312スレッドで決済レイヤーとして参照されている）は、検証されたレシートが最終的に決済される場所です。
これらはいずれも、ReceiptOSが「唯一の」標準である必要はありません — カプセルモデルのポイントは、cap cursorやアンカー基盤が交換可能であるのと同じように、交換可能であることです。私たちが探しているのは、カプセルの形状（キャプチャ → 規範化 → アンカー → 検証）が現在の構成から欠落しているのか、それとも8001/8312/8275/8294/8313のどこかにすでに暗黙的に存在しており、私たちが異なる名前で重複させているだけなのか、という点です。
ご意見をいただきたい点
- カプセル/規範化ステップは、8313の実行レイヤーで既に指定されているものと重複しますか、それとも真にその上流にありますか？
- TMerliniがPIMとWYRIWEのリンクを提案したように、ReceiptOSスタイルのカプセルとWYRIWEの
sanitization_pipeline_hashとの間に、正式なrequires:/extends:リンクへの需要はありますか？ - アンカーメカニズムに依存しないことについて — このカテゴリで、8312のBase Sepolia cursorの議論で触れられた「頻繁にアンカーするのは安価」と「高価だが規範的」という間の同じ緊張に遭遇した人は他にいますか？
スキーマ、規範化仕様、または実例（Stealthセッション → Chronicle）が役立つようでしたら、喜んで共有します。
7件の投稿 - 2名の参加者