Tersign Evidence

Tersign 是机器时代的记录层：记录 AI Agent 的行动和支出，由交易之外的一方共同签署，锚定在无人能够篡改的地方，任何人都可以核验。*机器可以生成一切，却无法生成过去。*卖家对收据进行 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)：任何载荷都能恢复出一个地址，因此编辑后的收据也会得到相同判定，但地址不同。
• 使用公开测试密钥（20 个 Hardhat/Anvil 默认开发助记词账户，或私钥 1、2、3）签名的收据，无论何种情况都会标记为 published test key：任何人都能生成这种签名。签名未涵盖的文件字段会按名称列出；签名字段若采用另一种 JSON 类型（"version": "1"），则会被拒绝。签名必须采用唯一规范编码（0x + 130 个小写十六进制数字，v 为 27/28，低 s 值）：真实签名的重新编码版本（v 为 0/1、大写十六进制、对应的高 s 值）也会恢复出发行方地址，但摘要不同，因此会被拒绝。
• 文件可以是收据、{receipt, record}，或证据包记录文件（records/NNNNNN.json，判定会注明 record artifact only：此处不检查其链字段）。其他任何包含收据的嵌套结构都会被拒绝，包括顶层出现第二份收据，或收据之外还有其他字段，因为读者可能会将这些字段误认为已检查的收据。重复键和非整数数字也会被拒绝。
• 摘要会在 Tersign 账本中查询，除非 --ledger 指定其他账本；返回结果是该账本自身的共同签名链检查，不会在本地重新验证其中任何内容，判定结果也会注明这一点（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

一次调用的披露证据

共同签名的证据，证明你的 Agent 出示过一份披露——一条命令，无需账户：

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

文本会在本地生成摘要（只有摘要会传输——从设计上实现数据最小化）。你的密钥会为记录签名；账本会为其共同签名，并将其写入按签名者区分的哈希链，该链的头部会通过每六小时运行一次的 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 起，每个锚点都会记录链承诺——即对每条共同签名链接的累加值——因此，一个锚定摘要就能覆盖整个前缀；更早锚定的行只绑定头部记录，并会注明这一点（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 结算响应，响应正文保持不变。如果无法生成这两份内容（结算网络既不是 CAIP-2，也不是表中的 v1 名称，例如 "bsc"，或发生账本错误），付费响应会原样返回处理器的结果，不附带收据；错误会传递给 onError（默认值：console.error）；启用幂等性后，使用相同付款 ID 重试会重放该响应。对于 402 响应，它会将 compliance-fields 添加到 PAYMENT-REQUIRED 标头中。用账本构建 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 正文的卖家，可以在接下来的一个小版本发布周期中设置 legacyBodyPlacement: true。

完整登记表：

能力	记录中的内容
收据	卖家签名的 EIP-712（x402 offer-receipt 扩展），keccak256 规范化摘要
withAssure()	x402 fetch 处理器适配器 — 每次能够生成收据的付费调用，都会将收据和合规字段记录放入 PAYMENT-RESPONSE；无法生成时，付费响应原样传递；402 响应中会声明 compliance-fields
合规字段记录	MINIMAL 层级（Art 226b 简化发票内容），通过 buildMinimalRecord 生成 · 账本导出 format=art226b · format=s51c — 这是映射，不是认证
操作记录	ActionRecordV1 — 符合 GDPR 最小化原则；记录 Art-50 披露已展示，并包含其文本的摘要，但绝不包含文本本身；由部署者签名，到达账本时再进行反签名；记录内容仍是部署者自己的陈述
退款	退款记录包含 refundOf，即其更正的记录摘要 · record_refund 会在账本上记录一条待处理退款条目（不进行反签名）；不会转移资金
争议 v0	客观原因代码、已签名的证据提交、确定性分流：固定规则会将重复扣款（R1 将同一卖家向同一付款方开具、且共享同一笔结算交易的收据视为一笔付款）或未答复的申诉归类，并将结果作为数据记录，而非作出裁决；其他情况都会标记为已升级，交由当事方选择的外部场所处理
场所信封	Internet Court（5,000 字符槽位） · Kleros ERC-1497 · UMA · 通用
证据包	format=art50 · format=safr（测试版）
幂等性	内存 + Cloudflare D1 存储
tersign intercept	在 MCP 边界进行审计捕获 — 每次工具调用生成一条已签名、仅含摘要的操作记录（实验性）

在 MCP 边界捕获——tersign intercept

Agent 的工具调用通常只会记录在 Agent 自己的代码中（如果有记录的话）。不如直接在传输线上记录：

npx tersign intercept -- npx your-mcp-server

代理是纯观察者：字节会按照发送时的内容和顺序，原样到达服务端和客户端。代理在你这边运行，并使用你的密钥，因此每条记录仍是你自己的报告。每个收到响应的 tools/call 都会成为由你的密钥签名的 ActionRecordV1；如果配置了账本，还会添加共同签名并纳入哈希链；已取消或从未收到答复的调用不会留下记录。仅摘要：每条记录都包含调用参数以及结果或错误之一的摘要（规范化 JSON），绝不包含内容。记录会写入已配置的账本；如果不可用，则回退到本地的 ~/.tersign/intercepts-<date>.jsonl，并且在本地文件中只有你的签名，确保不会悄无声息地丢失证据。

该功能仍处于实验阶段，并且刻意不对协议最终走向作出判断：目前，它以传输层代理的形式实现了 MCP SEP-2624（草案）中所述审计模式验证器的观察语义；如果且当拦截器原语稳定后，架构也便于迁移到该原语。此功能不声称符合该草案。

面向 Agent——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 将同一卖家向同一付款方开具、且共用同一笔结算交易的收据视为同一笔付款。

环境变量	必需	用途
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

无需配置，即可在一个会话中从初始状态完成添加共同签名：调用 record_disclosure，然后运行 npx tersign verify <digest> 检查它返回的 digest（仅提供摘要时会针对 https://tersign.ai 进行检查）。设置 TERSIGN_LEDGER_URL、TERSIGN_LEDGER_API_KEY 和 TERSIGN_LEDGER_SELLER_ID 后，issue_receipt 也会添加共同签名；未设置这些变量时，它会返回仅在本地签名、未纳入链的收据。

Agent 技能 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 扩展——一种带类型的合规记录架构，以及评估器端的四项取消资格条件（独立性、完整性／存在性、经济阶段分离和承诺范围——独立性声明的范围恰好等同于记录本身的承诺范围），每项都可作为双向符合性向量执行——目前正在上游审议（x402-foundation/x402#2853），并已列入 x402 TSC 的证据记录章程议程（tsc#4）。已合并的报价收据规范已包含会话后验证指南——按 issuedAt 时点评估签名者授权，并明确处理可变来源轮换（#2811，已合并）；完整性、独立性、存在性和阶段取消资格条件则是待审扩展的规范核心。

机器接口

完整 URL，无需身份验证即可读取。如果你是 Agent，请从这里开始。

接口	地址
npm 包	tersign — https://www.npmjs.com/package/tersign
MCP 注册表	io.github.tersignhq/evidence — npx tersign 无需配置；首次调用 record_disclosure 时会自动为签名者密钥配置账户，除非该密钥已注册到 API 密钥账户（409），或已达到每日配置上限（429）
ARD 目录（Agentic Resource Discovery）	https://tersign.ai/.well-known/ai-catalog.json
验证 API	GET https://tersign.ai/v1/receipts/{digest}/verify
信封 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
Bundle 验证器，带外获取	从归档文件 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 列出了所有版本。Bundle 自带检查器；如要验证利益相关方提供的证据，请获取该版本并对比两者。
llms.txt	https://raw.githubusercontent.com/tersignhq/tersign-js/main/llms.txt
符合性向量（RFC 8785 + keccak256，双向）	https://github.com/tersignhq/evidence-record-conformance
合规字段示例记录 + 摘要	https://github.com/tersignhq/tersign-js/blob/main/test/fixtures/compliance-record.json
创世记录验证	npx tersign verify 0xe5874f1ffe87f0a6dd9eb157730f67b86ee4538b125fe30fcc4e165213dd3fc4

---

贡献 — 提交拉取请求前请先阅读

tersignhq/tersign-js 是发布快照，不是开发仓库。 每次发布都会从上游工作树整体覆盖 src/、test/ 和打包清单，因此在此处提交的拉取请求无法以任何持久方式合并——下一次发布会在不作提示的情况下将其抹除。这是流水线的特性，并非对这项更改的评价。

欢迎贡献；只是需要通过其他途径提交：

• 错误、问题、规范分歧——在此处提交 issue。我们会阅读 issue；对于无需修改此代码树的事项，这里是合适的渠道。
• 代码更改——先提交 issue，并附上差异内容或更改说明。更改会在上游应用，保留你的作者身份，随后发布；issue 会在附上包含你贡献的版本链接后关闭。署名依据提交作者信息，而非合并徽章。
• 符合性分歧——双向向量测试套件 tersignhq/evidence-record-conformance 正常接受拉取请求；如果你认为“这条准则有误”或“这是它遗漏的案例”，这里是更合适的渠道。外部向量已在此合并。

如果维护者曾因这个原因要求你在其他地方重新提交工作，原因就在于此。

---

_{自 0.6.1 起采用 Apache-2.0；更早的版本采用 MIT · 通过可信发布 CI 从 tersignhq/tersign-js 构建并发布，来源证明已认证 · Python 验证器：pip install tersign}

_{场所不断更迭，记录长存。}