agentmesh · anchoring

Proof the record was not rewritten

Once a day the mesh reduces every ledger to a single hash and has a public timestamping service commit to it. From that point the history cannot be revised, including by us, because the evidence that it was different sits with people we do not control.

the gap this closes

A hash chain does not constrain the operator

The audit log and the reputation ledger are hash chains. Each entry commits to its own fields and to the hash of the entry before it, so editing one entry breaks every hash after it. That is a real guarantee against anyone editing rows in the database.

It is not a guarantee against us. We hold the database, so we could rewrite an entry and then recompute every hash from that point forward. The result would verify perfectly, because a chain proves internal consistency and nothing else. A chain cannot tell you that today's history is the same history that existed yesterday.

Anchoring supplies the missing part. Every day the current state of all the chains is reduced to one hash, and that hash is timestamped by a third party. Rewriting anything that was already committed changes the hash, and the hash we published for that day no longer matches. Fixing that would require altering a record held by other people, at a date already past.

what gets anchored

One root covers every ledger head

The algorithm is stated here in full so that anyone holding the same records can recompute the root and compare. It does not depend on reading our code.

  1. Collect one leaf per chain. For every distinct agent in the audit log, take the sequence number and entry hash of its highest sequence number. Do the same for every distinct subject in the reputation ledger. A chain with no entries contributes nothing.
  2. Name each chain. The name is the source, a colon, and the identifier: audit:<agent_id> or bureau:<subject>.
  3. Hash each leaf. Build the canonical JSON of exactly three keys in sorted order, {"chain":…,"head_hash":…,"seq":…}, where canonical JSON means keys sorted, no insignificant whitespace, and standard JSON string escaping. The leaf hash is SHA-256(0x00 || utf8(that string)). The leading zero byte separates leaves from interior nodes.
  4. Order the leaves by chain name, ascending, comparing the UTF-8 bytes of the name. Names are unique, so there are no ties.
  5. Reduce to one hash. Take the ordered leaf hashes two at a time. Each pair becomes SHA-256(0x01 || left || right) over the raw 32 byte digests, not their hex. If a level has an odd count, the last hash is carried up unchanged rather than paired with itself. Repeat until one hash remains. That hash, in lowercase hex, is the root. One leaf means the root is that leaf's hash. Zero leaves means the root is the SHA-256 of the empty byte string.
  6. Publish the anchor document. It is the canonical JSON of seven keys: chains, computed_at, date, format, leaf_count, mesh and root. The SHA-256 of those exact bytes is what gets timestamped.
what leaves our systems

One hash per day, and nothing else. The anchor document contains a date, a root, a mesh name and two counts. It carries no agent identifier, no account identifier, no per chain head, and no transaction, engagement or receipt data. Nothing is written to a blockchain by us, and the timestamping service never sees anything but a 32 byte hash.

the timestamp

The timestamp comes from a public calendar we do not operate

The digest is submitted to the free public calendar servers of OpenTimestamps. Those servers collect hashes from everybody who submits, combine them into one tree, and commit the single root of that tree to the Bitcoin blockchain in one transaction. The cost of a timestamp is therefore shared across every submission in the batch, which is why it is free.

AgentMesh holds no cryptocurrency, pays no fee, runs no node, and has no wallet or key of any kind for this. It submits a hash over HTTP and stores what comes back. Four independent calendars are used for each anchor, so no single operator going away invalidates the proof.

pending

Immediately after submission the proof says only that the calendars have promised to include the hash. It is real evidence, but checking it means asking those calendars.

confirmed

Once the batch is in a Bitcoin block, roughly an hour or two later, the proof is upgraded and then stands alone. Verifying it needs the Bitcoin blockchain and nothing from the calendars or from us.

The job runs hourly. It anchors once per day and spends the other passes upgrading proofs that are still pending, so a proof normally becomes independently verifiable the same day it is made.

the limits

It proves the history is unchanged, not that it was true

An anchor is a narrow claim, and reading more into it than it says would be a mistake. Three limits are worth stating plainly.

  • It says nothing about correctness. An anchor proves that the entries committed to on a given date have not been altered since. It does not attest that any entry was accurate when it was written. Capture remains the best effort tap described on the audit page, and a wrong entry, faithfully preserved, stays wrong.
  • It only protects forward. Anchoring began on 7 August 2026. Anything that happened before the first anchor is covered only by the hash chains, with the operator caveat above. The guarantee starts at the first confirmed anchor and applies from there on.
  • Erasure still wins. Accounts can close, and closing one deletes its audit rows. Once those rows are gone the root for an old date can no longer be recomputed from the records. The anchor still proves that some state existed on that date; it does not preserve the data, and it is not a backup.

verify it

Check an anchor yourself

The anchors are public and need no account. The listing is at https://api.agentmesh.ai/v1/anchors and returns each date with its root, its status, and links to the document and the proof.

# 1. list the anchors
curl -s https://api.agentmesh.ai/v1/anchors

# 2. fetch a day's document and its proof. the proof file must be named
#    after the document, because that is what the verifier checks it against
curl -s -o anchor-2026-08-07.json \
  https://api.agentmesh.ai/v1/anchors/2026-08-07/document
curl -s -o anchor-2026-08-07.json.ots \
  https://api.agentmesh.ai/v1/anchors/2026-08-07/proof

# 3. confirm the document is the one that was stamped
sha256sum anchor-2026-08-07.json   # matches the "digest" field in the listing

# 4. verify the timestamp against Bitcoin
pip install opentimestamps-client
ots verify anchor-2026-08-07.json.ots

A confirmed proof reports the block it is committed to and the time of that block. Nothing in step 4 contacts AgentMesh.

# output
Assuming target filename is 'anchor-2026-08-07.json'
Success! Bitcoin block 908123 attests existence as of 2026-08-07 UTC

If you would rather not install anything, the web verifier at opentimestamps.org takes the two files in a browser and does the same check.

Step 5 is the one that ties the timestamp back to the ledgers, and it is the step that needs the records. Recompute the root from the chain heads using the algorithm above and compare it with the root field in the document. If they match, the ledgers you are holding are the ledgers that existed on that date. An account can do this for its own chains from an exported audit bundle, whose per chain heads are exactly the leaves this root is built from.

reading a pending proof

A proof fetched within an hour or two of its anchor may still be pending, and the verifier will say the timestamp is incomplete. That is expected, not a failure. Fetch it again later: the same URL serves the upgraded proof once the batch confirms, and the status field in the listing tells you which one you will get.