Tersignhead asking…--:-- UTCledger askingShows this page's sections as plain markdown, built in your browser from the page itself. The agent manifest is https://tersign.ai/llms.txt.
The record layer for the machine age.
Machines can generate anything but the past.
Intelligence is abundant. Independent records are not.
What AI agents do and pay, counter-signed by a party outside the deal, anchored where no one can move it, checkable by anyone. A record shows that its exact bytes reached the ledger, in what order, and that they existed no later than the time anchor that covers them.
SEALgenesis record
asking the ledger…
Rings cut from the record's digest. The core is cut from the counter-signature only when the ledger returns it live. A fingerprint, not an approval.
Schematic. Block 10 is the genesis record; the four blocks after it stand for the records that follow. A value appears beside a numeral only once the ledger has answered.
Record. The genesis record, the first on its chain.asking the ledger…
Counter-signature. The ledger's signature over the record's link, made when the record arrived. Filled only after the ledger answered this page's live request.asking the ledger…
Chain link. Each link folds into one commitment over every record before it.asking the ledger…
Time anchors. Scheduled anchoring runs commit the ledger's current head to independent time anchors, up to three per run, and a run commits the head only when it has changed. Each proof checks without us.asking the ledger…
What intelligence can't manufacture.
Capable systems can write any document, log or account of events, after the fact. What a record says is becoming cheap to produce. Three things cannot be produced after the fact.
FIG. 2One record, two signatures
101112
A signature from outside the deal.
Beside the issuer's own signature (11), Tersign counter-signs each record (12) as it joins its chain, when the record arrives. Tersign is not a party to any customer transaction it records. It is on both sides only of its own records: the genesis demo; test records, which no published figure counts; and the prober's daily census commitments, which the prober writes and the ledger counter-signs so that the independent time anchors date the census, and which no organic figure counts.
FIG. 3Commitment and anchorsAsked when nearhead ,
1416
A time no party to the record can move.
A scheduled anchoring run commits the ledger's current head (14), when it has changed, to up to three independent time anchors (16), so anyone can check that a record existed no later than the anchor's time. Each proof can be checked without us.
FIG. 4A removed recordIllustrative
101418
A record removed later shows.
Records are numbered in the order they are counter-signed, and each chain commitment folds in every earlier link, so a record removed later leaves a gap (18) that anyone holding the chain can see. Records never submitted to the ledger are outside it.
We don't judge what a record says.
A Tersign record attests that these exact bytes reached the ledger, in what order, and no later than its anchor's time. Whose signature they carry is yours to check against a key you trust. Never that the content is true.
Change one character.
The genesis record, the first on the ledger: a self-signed demo, with Tersign as seller and its own key as payer. Edit a value. Your browser recomputes the digest as the ledger does, keccak-256 over canonical JSON, and asks the ledger whether it holds a record with that digest. The verdict is the ledger's answer.
Recut from the digest. Its core appears only with a live counter-signature.
FIG. 5Detail of 10 and 12
101214
Digestcomputing…0 of 64 characters changed, computed in your browser
Ledger's answerasking…
Counter-signatureasking…
Your browser computes only the digest; it does not check signatures. To check the payload signature offline, save the record's artifact object and run npx tersign verify <file> --signer <issuer address> (see /verify); an evidence bundle's counter-signatures are checked by the bundle verifier at /verify/latest/.
What gets recorded, link by link.
A payment is one link in a chain of conduct. A business writes a record for each link it chooses to keep about its own agents' dealings, and Tersign counter-signs each one into that account's numbered chain.
Authority
The mandate an agent acted under, cited in the records made under it. Tersign issues no identity and grants no authority.
Next
Decision
That a decision was taken, the policy it was checked against, and its outcome: allowed, blocked or escalated. The record shows that a decision was recorded, with the time its writer gives, never why it was made.
Live
Action
A tool call an agent made, or a message it sent.
Live
Disclosure
That a counterparty was told it was dealing with an automated system, or that content was synthetic, and when.
Live
Payment
A receipt as the seller submitted it, counter-signed. Live today for x402 offer-receipts; a refund can be logged against the receipt it refers to, beside the chain and not counter-signed.
Live
Triage
Fixed rules classify two kinds of dispute, a duplicate charge and a respondent who stays silent through the evidence window; the result binds no one unless the parties separately agree. The duplicate-charge rule reads receipts from one seller to one payer that share one settlement transaction as one payment. A contested case leaves as an evidence envelope formatted for a supported venue, or generic.
Live
Remove a record afterwards, and the numbering shows where.
Deterministic by construction.
Counter-signing, numbering, anchoring and the dispute rules are fixed code.
No one else's funds.
Tersign never holds, moves or settles anyone else's funds.
The same for every payer.
A record's counter-signature and its public check are the same whatever anyone paid.
Not shipped. This is where Tersign is headed, not what it does today.
Where this goes.
Authority, on the record.
Every record an agent writes will carry the mandate it acted under, so whoever relies on the act can see the mandate it cites.
Records others rely on.
We are building the record insurers, auditors and courts rely on without taking its owner's word for it.
A record that outlives its makers.
A record made today will still check after the company, the model and the rail that made it are gone.
Superintelligence will run the world. Tersign keeps the record.
The x402 census.
prober.tersign.ai asking
Observations
asking…hash-chained, one chain per endpoint
Tersign's prober observes x402 endpoints listed for public discovery and keeps each endpoint's observations as its own hash chain. Observations cannot be made after the fact: anyone who starts watching later sees the endpoints as they are then, not what they served before.
endpoints observed
asking…
seen serving a valid signed offer
asking…
asking prober.tersign.ai…
drawn: asking…
Runs
asking…
Last run
One mark for each endpoint the census has observed, set in no order: no mark stands for a particular endpoint. The marks in ink count the endpoints seen serving a valid signed offer: an offer whose signature recovers to some signer, which the census does not check against the offer's payTo.
This page is also machine-readable. You are welcome here.
npm i tersign
TypeScript SDK and MCP server: receipts, action and disclosure records, refunds, disputes and evidence envelopes. Apache-2.0.
npx tersign
Starts the MCP server io.github.tersignhq/evidence, listed in the MCP registry.
pip install tersign
A Python verifier with no dependencies and no account. Offline, it checks a receipt's signature against the issuer address you supply and recomputes chain links and chain commitments from records you hold. Apache-2.0.
https://tersign.ai/llms.txt
The agent manifest, with the steps for a free API key by DNS domain check, no card. Catalog at /.well-known/ai-catalog.json.
Setup for agents, as one block
# Tersign: setup for agents
Manifest: https://tersign.ai/llms.txt
Catalog: https://tersign.ai/.well-known/ai-catalog.json
MCP server: io.github.tersignhq/evidence (start with: npx tersign)
SDK: npm i tersign
Verifier: pip install tersign
Check a record, no account: GET https://tersign.ai/v1/receipts/{digest}/verify
Record context, for the record's writer (API key): GET https://tersign.ai/v1/records/{digest}/context
Free API key: DNS domain check, no card; the steps are in https://tersign.ai/llms.txt
Pricing.
Every payer receives the same bytes. No output changes with who pays. Checking a record is free for everyone, with no account.
Write
Free up to a monthly cap, with an API key issued after a DNS domain check. No card.
Records plan
One annual plan adds capacity, zero-retention mode and priority support, on the same ledger as every account.
Statements
A party that relies on records it did not write pays per request for a ledger-signed statement over a range of them: $0.10 per statement, in USDC on Base over x402, with no account. The price is the same for every payer, and nothing in a statement depends on who paid. It attests which records were counter-signed and in what order; never what they say.
Four requests, from a domain you control to a record anyone can check. The same steps are in llms.txt, which also says how to write action and disclosure records.
1
Show that you control a domain
POST https://tersign.ai/v1/onboarding/domain/challenge {"domain":"example.com"}
Returns a token, a TXT record to publish at _tersign-challenge.example.com, and a secret shown only in this response (the TXT record is public; verify also requires the secret).
2
Get a free API key
POST https://tersign.ai/v1/onboarding/domain/verify {"domain":"example.com","token":"…","secret":"…","email":"<notices contact>","acceptTerms":true}
Checks the TXT record over DNS and returns a Free Tier API key once; a domain-verified account may write 10,000 counter-signed records per month (1,000 per UTC day); the 10,000-a-month allowance is for a domain whose public suffix (the list's longest matching rule) is in the ICANN section of the Public Suffix List, as the ledger's copy of the list holds it; any other verified name gets its own account with the limits of an account without a verified domain (100 a month, at most 50 per UTC day): a host under a suffix in the list's private section, such as vercel.app, workers.dev, github.io or uk.com, and a name under a top-level label the copy does not list. Free writing pauses (HTTP 503) for every free account while the ledger's shared free capacity is full, and Records plan writes go on. Issuing the key is acceptance of the Terms (https://tersign.ai/legal/terms.json). One registered domain, one free account: example.com and every name under it share it. A receipt's compliance block is not accepted from these accounts.
3
Write a record
POST https://tersign.ai/v1/receipts
Authorization: Bearer <apiKey> and the body {"sellerId":"<sellerId from step 2>","artifact":{"format":"eip712","payload":{"version":1,"network":"eip155:8453","resourceUrl":"…","payer":"0x…","issuedAt":<unix seconds>,"transaction":"…"},"signature":"0x<65-byte EIP-712 Receipt signature, v 27 or 28>"}}
201 {id, digest, seq, prevDigest, countersignature}. The artifact in GET https://tersign.ai/v1/genesis is a complete example.
4
Check it, with no account
GET https://tersign.ai/v1/receipts/{digest}/verify
The ledger's answer: whether it holds the record, its chain position and counter-signature, and whether the counter-signed link checks out.
Before you write
Every record you write is permanent. It is counter-signed into your chain at the next sequence number, a scheduled anchoring run commits the chain with it to a time anchor, and it counts toward the free plan's limits: 10,000 counter-signed records per month (1,000 per UTC day) for an account that has verified a domain whose public suffix (the list's longest matching rule) is in the ICANN section of the Public Suffix List, 100 per month (50 per UTC day) for any other account, a verified host under a private suffix such as vercel.app included. Free writing pauses (HTTP 503) for every free account while the ledger's shared free capacity is full, and Records plan writes go on. Erasing it later blanks its stored content; its digest, sequence number, counter-signature and anchors stay, and so does its place in the month's count.
Records are attributed to the legal name and jurisdiction the account declares at POST https://tersign.ai/v1/account/identity (Terms §4.1), kept as declared by the account, not verified by Tersign.
Every value in this section is asked of a public endpoint. Most are asked as the page loads; the anchors are asked when this section, or the time drawing above, is opened or scrolled to.
This page asks the ledger as it loads. The command below asks it directly, without this page.
That digest is the genesis record, a self-signed demo: Tersign signed it as seller and named its own key as payer. /v1/genesis carries the recipe for each of its signatures, and /independence walks through checking its payload signature offline.
Three times, kept apart.
On the ledger's schedule, a six-hourly cron submits the commitment for Bitcoin anchoring when it has changed: changes between two runs coalesce into one submission, a degraded run can defer it, and an unchanged commitment is not re-submitted. So the head can change without an anchor, and the job can run without committing a head.
Ledger head changed
asking…
Last anchoring run committed a head
asking…
Anchoring job last ran
asking…
A ledger anchor on Bitcoin.
Anchorednot asked yet
Anchored commitmentasked when this section is near
Statusnot asked yet
Proofnot asked yet
Co-anchor
Check it yourselfots info proof.ots runs offline with stock OpenTimestamps tooling and prints the attested Bitcoin block; cross-check that block in any explorer. With a local Bitcoin node: ots verify -d <anchoredDigest> proof.ots.
Every endpoint, with no account.
GET /v1/statsThe ledger head and the anchoring job's heartbeat.asking…
GET /v1/anchorsThe 20 newest ledger-wide anchors, each with its proof file.asked when this section is near