Tersign Evidence

Tersign は機械の時代の記録レイヤーです。AI エージェントが行うことや支払う金額を、取引に関与していない第三者が連署し、誰も動かせない場所に記録して、誰でも検証できるようにします。機械は何でも生成できますが、過去は生成できません。 販売者は EIP-712 レシートに署名し、Tersign は販売者ごとにそれらをチェーン化して、すべての記録に連署します。紛争が起きたときには、やり取りの記録はすでに封印されています。

取引の場は変わります。記録は残ります。

---

実際のエントリーを今すぐ検証

アカウントも API キーも不要です。これは本番チェーン上のジェネシスレシート、seq 1 です。これは自己署名デモです。Tersign は売り手として署名し、支払者として自社のキーを指定しているため、EIP-712 ペイロード署名（x402 のオファーおよびレシート拡張に基づくドメイン {name: "x402 receipt", version: "1", chainId: 1}）を復元すると、ペイロード自身の支払者である 0x36f82906859E5B0bd076069f8cdfAea355358b14 になります。/v1/genesis では、各署名の作成方法とともにレコードを提供しています。

npx tersign verify 0xe5874f1ffe87f0a6dd9eb157730f67b86ee4538b125fe30fcc4e165213dd3fc4

ledger:    https://tersign.ai
           reports: found, counter-signed chain intact (seller tersign-first, seq 1, …) — not checked locally
VALID (ledger-reported) — https://tersign.ai reports the record and its counter-signed chain; nothing was verified locally

npx tersign verify <receipt.json | 0xdigest> [--signer 0xaddr] [--ledger url] は、レシートファイルまたはダイジェストを受け取ります。

• レシートファイルはローカルで検査され、--ledger を追加しない限りネットワークには接続しません。EIP-712 署名が復元され、--signer は発行者のアドレスと照合します。このアドレスは、信頼できるチャネルを通じて発行者から入手してください。レシートから取得してはいけません。--signer を指定しない場合、署名者は UNAUTHENTICATED と報告され、判定結果は VALID (signer UNAUTHENTICATED) になります。どのようなペイロードでもアドレスを復元できるため、編集されたレシートも別のアドレスで同じ行に到達します。
• 公開済みテストキー（Hardhat/Anvil のデフォルト開発用ニーモニックの 20 個のアカウント、または秘密鍵 1、2、3）で署名されたレシートは、いずれの場合も published test key としてフラグが付けられます。その署名は誰でも作成できるためです。署名が対象としていないファイル内のフィールドは名前で列挙され、別の JSON 型になっている署名対象フィールド（"version": "1"）は拒否されます。署名は唯一の正規エンコード（0x + 130 個の小文字の 16 進数、v 27/28、low-s）でなければなりません。本物の署名を再エンコードしたもの（v 0/1、大文字の 16 進数、high-s の双子）も、異なるダイジェストのもとで発行者のアドレスに復元されるため、拒否されます。
• ファイルの形式は、レシート、{receipt, record}、または証拠バンドルのレコードファイル（records/NNNNNN.json。判定結果には record artifact only と付記され、ここではチェーンフィールドを検査しません）のいずれかです。トップレベルに 2 つ目のレシートがある場合や、レシート以外のフィールドがある場合など、レシートを内包するそれ以外の形式は拒否されます。読み手がそれらのフィールドを検証済みのレシートの一部とみなす可能性があるためです。重複キーと整数以外の数値も拒否されます。
• ダイジェストは、--ledger で別の台帳を指定しない限り、Tersign 台帳で検索されます。返されるのはその台帳自身による、相互署名済みチェーンの検査結果であり、ローカルで再検証されるものはありません。判定結果にはその旨が示されます（VALID (ledger-reported)）。照会した台帳は必ず表示されます。ローカルで検査する場合は、レシートファイルに --signer を指定してください。

終了ステータス：0 は有効（最終行を確認してください。ファイルの場合、単独の VALID は、レシートまたは {receipt, record} 上で署名者が紐付けられており、テストキーではないことを意味します。ダイジェストの場合は常に VALID (ledger-reported) です）、1 は無効、2 は使用方法の誤り（不明なフラグまたは値のないフラグ、ダイジェストと併用された --signer、ファイルが存在しない、または JSON ではない）です。生の HTTP を使う場合はこちらです。同じ証明を CLI なしで実行できます。

curl https://tersign.ai/v1/receipts/0xe5874f1ffe87f0a6dd9eb157730f67b86ee4538b125fe30fcc4e165213dd3fc4/verify

1 回の呼び出しで開示の証拠を作成

エージェントが開示を提示したことを示す、相互署名済みの証拠です。アカウント不要で、コマンド 1 つで実行できます。

npx tersign disclose "You are chatting with an AI assistant." --medium chat --agent-id my-agent

テキストはローカルでダイジェスト化されます（送信されるのはダイジェストのみです。設計上、データを最小限に抑えています）。キーがレコードに署名し、台帳がそのレコードに相互署名して、署名者ごとのハッシュチェーンに追加します。そのチェーンのヘッドは、6 時間ごとの cron で Bitcoin にアンカリングするために送信されます。最初の呼び出しでは、キーに紐付けられた、署名者キー単位の無料アカウントが自動的に作成されます。ただし、そのキーがすでに API キーの台帳アカウントに登録されている場合（409：そのアカウントを通じて送信してください）、または当日のアカウント作成上限に達している場合（429）は除きます。キーの解決順序：環境変数 TERSIGN_SELLER_KEY → macOS キーチェーン tersign-signer → 初回使用時に作成される ~/.tersign/signer.key。無料プランにはクォータとレートの制限があります。詳しくは制限をご覧ください。これは、開示がその時点で証明されたことを独立して検証できる証拠です。コンプライアンス認証ではありません。

連鎖管理

すべてのエントリーは同じ経路をたどります。販売者がレシートに署名し（EIP-712、x402 offer-receipt 拡張）、Tersign がkeccak256 正規ダイジェストを計算します → ダイジェストが販売者のハッシュチェーンに加わり、各 seq n が seq n−1 に紐付けられます → 中立的な台帳が（secp256k1で）副署します → 誰でも検証でき、あらゆる会場でシリアライズされたエンベロープを取得できます。

2026-08-28以降、各アンカーにはチェーンコミットメント（副署されたすべてのリンクを集約した値）が記録されます。これにより、1つのアンカーダイジェストでチェーン全体の先頭までをカバーできます。それ以前にアンカーされた行は、ヘッドレコードのみを参照し、その旨を明記します（subjectSchema）。

graph LR
    A["agent transaction<br/>x402"] --> B["seller-signed receipt<br/>EIP-712"]
    B --> C["canonical digest<br/>keccak256"]
    C --> D["per-seller hash chain<br/>seq n binds seq n−1"]
    D --> E["neutral counter-signature<br/>secp256k1 ledger"]
    E --> F["verifiable by anyone<br/>venue-formatted envelope"]

_{図は GitHub で表示されます。npm では、上の段落が図そのものです。}

返金レコードは、訂正対象のレコードをダイジェストで参照します（refundOf）。異議申し立ては、客観的な理由コードを付けてダイジェストに関連付けます。当事者の声明は UNVERIFIED マーカーの後ろに構造的に分離されるため、証拠はプロンプトインジェクション対策が施された状態に保たれます。

記録を入力する

npm i tersign

withAssure() は x402 の fetch ハンドラーをラップします。決済が確定すると、お使いのキーでレシートとコンプライアンスフィールド記録に署名し、両方を PAYMENT-RESPONSE ヘッダーにマージします。これは、x402 ウォレットがすでに読み取る base64 JSON の決済確定レスポンスです。レスポンスボディには変更を加えません。発行できない場合（"bsc" など、CAIP-2 でもテーブル内の v1 名でもない決済ネットワーク、または台帳エラー）は、有料レスポンスをハンドラーが返した状態のまま送信し、レシートは付与されません。エラーは onError（デフォルト：console.error）に渡されます。冪等性が有効な場合、同じ決済 ID で再試行すると、そのレスポンスが再送されます。402 レスポンスでは、PAYMENT-REQUIRED ヘッダーに compliance-fields を追加します。Assure が台帳とともに構築されている場合、台帳はレシートに連署してチェーンに記録します。コンプライアンスフィールド記録には連署されず、レシートのダイジェストを含むお客様自身の署名によってのみ、レシートと結び付けられます。台帳がない場合、どちらにもお客様自身の署名のみが付与されます。

import { privateKeyToAccount } from 'viem/accounts';
import { Assure, withAssure } from 'tersign';

const signer = privateKeyToAccount(process.env.TERSIGN_SELLER_KEY as `0x${string}`);
const assure = new Assure({ signer, issuer: { name: 'Example API Ltd', jurisdiction: 'HK' } });
export default { fetch: withAssure(app.fetch, { assure }) }; // app: your x402-protected Hono app

ウォレットは、デコードした PAYMENT-RESPONSE の extensions["offer-receipt"].info.receipt からレシートを、extensions["compliance-fields"].info.record から記録を取得します（x402 v1 では X-PAYMENT-RESPONSE）。JSON ボディをまだ解析するリーダーを使っている販売者は、もう1回のマイナーリリースに限り legacyBodyPlacement: true を指定できます。

機能の全容：

機能	記録される内容
レシート	販売者が署名する EIP-712（x402 offer-receipt 拡張機能）、keccak256 の正規化ダイジェスト
withAssure()	x402 fetch ハンドラーアダプター。発行可能な有料呼び出しごとにレシートとコンプライアンスフィールド記録を PAYMENT-RESPONSE に追加し、発行できない場合は有料レスポンスを変更せずにそのまま渡します。402 では compliance-fields を通知します
コンプライアンスフィールド記録	buildMinimalRecord による MINIMAL 層（Art 226b の簡易請求書の内容）。台帳のエクスポート形式は format=art226b。format=s51c。認証ではなく、マッピングです
アクション記録	ActionRecordV1 — GDPR に配慮してデータを最小化。Art-50 の開示が提示されたことを記録し、そのテキスト自体ではなくダイジェストを含みます。デプロイヤーが署名し、台帳に記録される際には連署されます。記録内容はあくまでデプロイヤー自身の報告です
返金	返金記録には、訂正対象の記録のダイジェストである refundOf が含まれます。record_refund は保留中の返金エントリーを台帳に記録します（連署されません）。資金は移動しません
紛争 v0	客観的な理由コード、署名付きの証拠提出、決定論的なトリアージ。固定ルールにより、重複請求（R1 は、同一販売者から同一支払者へのレシートのうち、同じ決済トランザクションを共有するものを1つの支払いとして扱います）または未回答の申し立てを分類し、その結果を裁定ではなくデータとして記録します。それ以外はすべてエスカレーション対象としてマークされ、当事者が選択する外部の紛争処理機関に委ねられます
紛争処理機関向けエンベロープ	Internet Court（5,000文字枠）・Kleros ERC-1497・UMA・汎用
証拠パック	format=art50・format=safr（ベータ）
冪等性	メモリ内ストアと Cloudflare D1 ストア
tersign intercept	MCP 境界での監査キャプチャ。ツール呼び出しごとに、署名付きのダイジェストのみのアクション記録を作成します（実験的）

MCP 境界でキャプチャ — tersign intercept

エージェントのツール呼び出しは、記録されるとしても、通常はエージェント自身のコード内で記録されます。代わりに、通信上で記録します。

npx tersign intercept -- npx your-mcp-server

このプロキシは純粋なオブザーバーです。バイト列は送信されたとおり、順序も変更もなく、サーバーとクライアントに届きます。プロキシは自分の側で自分のキーを使って実行されるため、各記録は引き続き自分自身の報告です。応答が返されたすべての tools/call は、自分のキーで署名された ActionRecordV1 となり、台帳が設定されている場合はハッシュチェーンに副署されます。キャンセルされた呼び出しや応答がなかった呼び出しは記録されません。ダイジェストのみです。各記録に含まれるのは、呼び出し引数のダイジェストと、結果またはエラーのいずれかのダイジェスト（正規化された JSON）であり、内容そのものは含まれません。記録は設定された台帳に送られます。送信できない場合はローカルの ~/.tersign/intercepts-<date>.jsonl に保存され、そこでは自分の署名のみが付与されるため、証拠が黙って破棄されることはありません。

実験的な機能であり、プロトコルの今後の落ち着き先について意図的に特定の立場を取りません。現時点では、MCP SEP-2624（ドラフト）で説明されている監査モードのバリデーターの観測セマンティクスを、トランスポートレベルのプロキシとして実装しています。また、それが安定した場合にインターセプターのプリミティブへ移行できるよう構成されています。このドラフトへの準拠を主張するものではありません。

エージェント向け — MCP サーバー

npx tersign を実行すると、MCP サーバー（stdio）が起動します。公式レジストリエントリーは io.github.tersignhq/evidence（有効）です。

{
  "mcpServers": {
    "tersign": {
      "command": "npx",
      "args": ["tersign"]
    }
  }
}

設定は不要です。TERSIGN_SELLER_KEY が未設定または空の場合、サーバーは macOS のキーチェーン（tersign-signer）または ~/.tersign/signer.key のキーを使い、初回実行時にその場所にキーを生成します。キーがマシンの外に出ることはありません。独自のキーを使う場合に限り、TERSIGN_SELLER_KEY を設定してください。

ツール — issue_receipt · verify_receipt · verify_compliance_record · record_disclosure · record_refund · open_dispute · submit_dispute_evidence · adjudicate_dispute · get_dispute

どのツールも資金を移動しません。issue_receipt と record_refund は、すでに発生した支払いと返金を記録します。adjudicate_dispute は決定論的なトリアージを実行し、その結果を記録します。ツールの説明に記載された固定ルールにより、二重請求または回答のない申し立てが分類されます。この結果はデータであり、裁定ではありません。また、法的請求に関する判断を下すものでもありません。二重請求のルール R1 では、同一の決済トランザクションを共有する、ある販売者からある支払者への領収書は、1件の支払いとして扱われます。

環境変数	必須	用途
TERSIGN_SELLER_KEY	いいえ	0x 接頭辞付きの独自の署名キーです。未設定または空の場合は、キーチェーンまたはキーファイルのキーが使用されます（初回実行時に生成されます）。台帳アカウントに登録済みの署名キーがある場合は、ここにそのキーを設定してください。台帳は、別のキーで署名された回答者の紛争証拠を拒否します
TERSIGN_LEDGER_URL	いいえ	副署とチェーンチェックに使う台帳です。紛争関連ツールで必要です。record_disclosure のデフォルトは https://tersign.ai です
TERSIGN_LEDGER_API_KEY	いいえ	台帳上の販売者 API キーです。販売者 ID と合わせて設定すると、record_refund とチェーン付きの issue_receipt が有効になります。また、回答者の紛争証拠の認証にも使われます
TERSIGN_LEDGER_SELLER_ID	いいえ	台帳上の販売者 ID です。API キーと合わせて設定すると、record_refund とチェーン付きの issue_receipt が有効になります
TERSIGN_ISSUER_NAME	いいえ	アクション記録に記載される発行者名です
TERSIGN_ISSUER_JURISDICTION	いいえ	アクション記録に記載される発行者の管轄地です
TERSIGN_ISSUER_TAX_ID	いいえ	アクション記録に記載される発行者の税務 ID または事業者登録 ID です

設定なしでも、1回のセッションで未署名の状態から副署済みの状態にできます。record_disclosure を呼び出し、返された digest を npx tersign verify <digest> で確認してください（ダイジェストのみを指定した場合は、https://tersign.ai に対して確認します）。TERSIGN_LEDGER_URL、TERSIGN_LEDGER_API_KEY、TERSIGN_LEDGER_SELLER_ID を設定すると、issue_receipt も副署されます。これらが未設定の場合は、ローカルで署名され、チェーンには追加されない領収書が返されます。

エージェントスキル tersign-evidence は tersignhq/skills で提供されています。

ライブレコード

• 台帳 + ダッシュボード — 公開検証ページ：https://tersign.ai/verify
• センサス — ライブの x402 販売者カタログ全体にわたるハッシュチェーン形式の観測データを自律的に調査します。数値はライブで提供され、古い値が引用されることはありません：https://prober.tersign.ai/v1/prober/stats
• 適合性 — RFC 8785（JCS）による正規化シリアライズ、keccak256 ダイジェスト、および公開の両方向ベクタースイート（正規バイト列、数値ドメイン、コンテンツアドレス、チェーンの連続性、完全性、アンカーされた存在、フェーズ分離、オファーのバインディング、独立性 — 各基準に受け入れベクターと敵対的ベクターの両方を収録）：tersignhq/evidence-record-conformance。バイト列を再現できれば、どの言語でも実装は適合しています。
• 標準 — compliance-fields 拡張（型付きコンプライアンスレコードスキーマと、評価側での4つの失格判定（独立性、完全性／存在、経済フェーズの分離、コミットメントのスコープ — 独立性の主張が及ぶ範囲は、レコード自体のコミットメントの範囲と正確に一致します）。それぞれ両方向の適合性ベクターとして実行可能）は上流でレビュー中です（x402-foundation/x402#2853）。また、x402 TSC のエビデンスレコード憲章の議題でも参照されています（tsc#4）。マージ済みのオファー領収書仕様には、セッション後の検証に関するガイダンスがすでに含まれています。署名者の認可は issuedAt 時点で評価され、変更可能なソースのローテーションも明示的に処理されます（#2811、マージ済み）。完全性、独立性、存在、フェーズに関する失格判定は、未マージの拡張の規範的な中核です。

マシン向けエンドポイント

完全な URL を認証なしで利用できます。エージェントの場合は、ここから始めてください。

エンドポイント	アドレス
npm パッケージ	tersign — https://www.npmjs.com/package/tersign
MCP レジストリ	io.github.tersignhq/evidence — npx tersign は設定不要です。record_disclosure の初回呼び出しでは、キーが API キーアカウントに登録されている場合（409）や、1日のプロビジョニング上限に達している場合（429）を除き、署名者キーに紐づいたアカウントが自動的にプロビジョニングされます
ARD カタログ（Agentic Resource Discovery）	https://tersign.ai/.well-known/ai-catalog.json
Verify API	GET https://tersign.ai/v1/receipts/{digest}/verify
Envelope API	GET https://tersign.ai/v1/receipts/{digest}/envelope?venue={internet-court|kleros|uma|generic}
台帳の統計情報	GET https://tersign.ai/v1/stats
台帳の署名者	GET https://tersign.ai/v1/ledger
バンドル検証ツール、帯域外	アーカイブの VERIFY.md のセクション0で指定されているアドレスから検証ツールを取得します。これはアーカイブのビルドに使用されたリリースのコンテンツアドレスです。https://tersign.ai/verify/sha256/<sha256 of its SHA256SUMS>/（VERIFY.md に https://tersign.ai/verify/v1/ と記載されたアーカイブでは、そちらを使用します）。各リリースには verify_bundle.py · keccak.py · secp256k1.py · SHA256SUMS が含まれ、ファイルが変更されることはありません。https://tersign.ai/verify/releases.json にはすべてのリリースが記載されています。バンドルには独自の検証ツールが含まれています。利害関係者によるエビデンスを検証するには、そのリリースを取得して2つを差分比較してください。
llms.txt	https://raw.githubusercontent.com/tersignhq/tersign-js/main/llms.txt
適合性ベクター（RFC 8785 + keccak256、両方向）	https://github.com/tersignhq/evidence-record-conformance
compliance-fields レコードのサンプル + ダイジェスト	https://github.com/tersignhq/tersign-js/blob/main/test/fixtures/compliance-record.json
Genesis の検証	npx tersign verify 0xe5874f1ffe87f0a6dd9eb157730f67b86ee4538b125fe30fcc4e165213dd3fc4

---

コントリビューション — プルリクエストを作成する前にお読みください

tersignhq/tersign-js は公開用スナップショットであり、開発リポジトリではありません。 リリースごとに上流の作業ツリーから src/、test/、パッケージ化されたマニフェストがすべて上書きされるため、ここで作成したプルリクエストを永続的な形でマージすることはできません。次のリリースで、変更が気付かれないまま消えてしまいます。これはパイプラインの仕様であり、変更内容の評価ではありません。

コントリビューションは歓迎します。手続き上の窓口を変える必要があるだけです。

• バグ、質問、仕様に関する意見の相違 — こちらでイシューを作成してください。イシューは確認されます。このツリーに手を加える必要がない場合は、イシューが適切な窓口です。
• コードの変更 — まず、差分または変更内容の説明を添えてイシューを作成してください。変更は作者のクレジットを保ったまま上流に適用され、リリース後、変更が含まれるバージョンへのリンクを添えてイシューがクローズされます。クレジットはマージバッジではなく、コミットの作者に基づきます。
• 適合性に関する意見の相違 — 両方向のベクトルスイートを扱う tersignhq/evidence-record-conformance では、通常どおりプルリクエストを受け付けています。「この基準は誤っている」や「このケースが考慮されていない」といった指摘には、こちらのほうが適切な場です。外部のベクトルも、ここでマージされています。

この理由で、メンテナーから別の場所で作業を再開するよう求められた場合は、これがその理由です。

---

_{0.6.1 以降は Apache-2.0。それ以前のリリースは MIT · 信頼された公開の CI を通じて tersignhq/tersign-js からビルドおよび公開。プロベナンスの証明付き · Python 検証ツール：pip install tersign}

_{開催地は変わっても、トランスクリプトは残ります。}