Regent Protocol Start building

What makes an audit trail tamper-evident?

Tamper-evident means structurally checkable: altering a record after the fact breaks the math, not a policy. Here is the exact construction — hash, batch, anchor, verify — and what each layer does and does not promise.

The construction

  • Hash on receipt. Each event's payload is hashed immediately — the trail carries payload_hash, so a later edit to the payload no longer matches its own record.
  • Merkle batching. Events group into batches; each gets an index and a proof path to one batch root. The root commits to every event beneath it — change any one, and the root changes.
  • On-chain anchoring. The root is committed to a public chain (Solana devnet today). That commitment is outside anyone's edit reach — including ours.
  • Independent verification. Recompute the hash, walk the proof, check the root on-chain. The recipe is public and runnable by anyone.

What this does not promise

Precision matters here. Anchoring proves a record existed and was not altered after commitment — it does not make storage infinite (retention is a plan property; the optional immutable archive is an Enterprise add-on), and it cannot vouch for data that was wrong before it was hashed. That is why the trail records decisions from the enforcement path itself, not self-reported summaries.

Why "trust me" fails audits

A vendor-held log proves what the vendor chose to keep. The question a reviewer actually asks — "could this have been edited?" — deserves a structural answer. When verification needs no cooperation from the party being audited, the answer stops being a negotiation.

Related

Audit Chain · Audit API · What is KYA?