tersign

Tersign is the evidence layer for the agent economy — a neutral, counter-signed, hash-chained ledger for agent commerce. Sellers sign EIP-712 receipts; Tersign chains them per seller and counter-signs every entry. When the dispute comes, the transcript is already sealed.

Venues rotate. The transcript endures.

Verify a Real Entry — Right Now

No account. No API key. This is the genesis receipt, seq 1 on the production chain:

npx tersign verify 0xe5874f1ffe87f0a6dd9eb157730f67b86ee4538b125fe30fcc4e165213dd3fc4

ledger: counter-signed OK (seller tersign-first, seq 1 …) VALID

npx tersign verify <receipt.json | 0xdigest> [--ledger url] recovers the EIP-712 signature locally. A bare digest is then checked against the Tersign ledger unless --ledger names another; a receipt file verifies offline and touches no chain at all. The ledger consulted is always printed. Prefer raw HTTP? The same proof, no CLI:

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

Related MCP server: touchstone-mcp

One-Call Disclosure Evidence

Counter-signed evidence that your agent presented a disclosure — one command, no account:

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

The text is digested locally (only the digest travels — data-minimization by construction). Your key signs the record; the ledger counter-signs it into a per-signer hash chain whose head is submitted for Bitcoin anchoring on a six-hourly cron. First call self-provisions a free signer-keyed account bound set-once to your key (key resolution: TERSIGN_SELLER_KEY env → macOS keychain tersign-signer → ~/.tersign/signer.key, created on first use). Free tier is quota- and rate-limited — limits. What this is: independently verifiable evidence the disclosure was attested at that time. What it is not: a compliance certification.

Chain of Custody

Every entry takes the same path: the seller signs the receipt (EIP-712, x402 offer-receipt extension) → Tersign computes the keccak256 canonical digest → the digest joins that seller's hash chain, each seq n bound to seq n−1 → the neutral ledger counter-signs (secp256k1) → anyone verifies, and any venue gets a serialized envelope.

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-ready envelope"]

Diagram renders on GitHub. On npm, the paragraph above IS the diagram.

Refunds chain back to the original receipt via refundOf. Disputes attach to the digest with objective reason codes. Party statements are structurally segregated behind an UNVERIFIED marker — the evidence stays prompt-injection-hardened.

Enter the Record

npm i tersign

withAssure() wraps your x402 fetch handler so every paid call issues a signed, chained receipt. The full register:

Capture at the MCP Boundary — tersign intercept

An agent's tool calls are usually recorded, if at all, by the party running the agent. Put a recording clamp on the wire instead:

npx tersign intercept -- npx your-mcp-server

The proxy is a pure observer: bytes reach the server and the client exactly as sent, in order, unmodified. Every tools/call it sees becomes an ActionRecordV1 signed by your key and counter-signed into a hash chain — digests only, so the record proves what happened without carrying arguments or results anywhere. Records go to a configured ledger, and fall back to a local ~/.tersign/intercepts-<date>.jsonl so evidence is never silently dropped.

Experimental, and deliberately unopinionated about where the protocol lands: it implements the observation semantics of the audit-mode validator described in MCP SEP-2624 (Draft) as a transport-level proxy today, and is structured to move onto the interceptor primitive if and when that stabilizes. It makes no conformance claim to that draft.

For Agents — the MCP Server

npx tersign starts the MCP server (stdio). Official registry entry: io.github.tersignhq/evidence (active).

{
  "mcpServers": {
    "tersign": {
      "command": "npx",
      "args": ["tersign"],
      "env": { "TERSIGN_SELLER_KEY": "0x<your-seller-key>" }
    }
  }
}

Tools — issue_receipt · verify_receipt · verify_compliance_record · record_disclosure · record_refund · open_dispute · submit_dispute_evidence · adjudicate_dispute · get_dispute

Cold to counter-signed in one session: call issue_receipt, then check the issued receipt's digest with npx tersign verify <digest> --ledger <url>.

The agent skill tersign-evidence ships at tersignhq/skills.

The Live Record

• Ledger + dashboard — public verify page: https://tersign.ai/verify

• Census — hash-chained observations across the live x402 seller catalog, probed autonomously; the numbers are served live, never quoted stale: https://prober.tersign.ai/v1/prober/stats

• Conformance — RFC 8785 (JCS) canonical serialization, keccak256 digests, and the public two-sided vector suite (canonical bytes, number domain, content address, chain continuity, completeness, anchored existence, phase separation, offer binding, independence — every criterion carrying both an accepting and an adversarial vector): tersignhq/evidence-record-conformance. Reproduce the bytes and your implementation is conformant — in any language.

• Standards — the compliance-fields extension — a typed compliance-record schema plus four evaluator-side disqualifications (independence, completeness/existence, economic-phase separation, and commitment scope — an independence claim reaches exactly as far as the record's own commitments), each executable as a two-sided conformance vector — is under review upstream (x402-foundation/x402#2853) and referenced in the x402 TSC's evidence-record charter agenda (tsc#4). The merged offer-receipt spec already carries the completeness criterion at SHOULD strength (§4.5.1, #2811).

Machine Surfaces

Full URLs, readable without auth. If you are an agent, start here.