Trust ledger methodology: how we anchor review evidence

The design goal in one paragraph

The Trust Ledger exists to make one specific claim testable: 'at time T, ScoreReview UK held evidence E for review R, and the moderation state was S'. Nothing more, nothing less. It does not attempt to prove the review is truthful. It proves only that the platform cannot silently rewrite history.

This is a narrow goal on purpose. Trust systems that try to prove too much end up proving nothing because the assumptions collapse. Anchoring a hash of the evidence and the state is a claim we can defend cryptographically and audit publicly.

The design borrows from certificate transparency: append-only log, third-party verifiers, published inclusion proofs. Nothing in the scheme is novel, which is a feature — it means the properties are well understood.

What is hashed and what is anchored

Every verification event produces a leaf hash. Leaves are batched into a Merkle tree every 60 seconds, and the tree head is anchored to two public transparency services on a five-minute cadence.

The consistent pattern is: identifiers and outcomes are hashed; personal data and free text are held internally, salted, and only their hashes appear on the log. This satisfies GDPR's data-minimisation principle while still allowing third parties to verify that no event has been added, removed or altered after the fact.

Salts are per-review and rotated only when a review is deleted for legal reasons (right to erasure). Rotation invalidates the previous inclusion proof but leaves the log structure intact, and the rotation itself is a logged event.

How anyone can verify a review

The verification recipe is public and language-agnostic. It requires the review ID, the ledger anchor timestamp, and access to the two public transparency services — all of which are free.

1. 1Fetch the review record from GET /api/public/ledger/{reviewId}. The response includes the event list, the leaf hashes and the tree-head anchors.
2. 2Recompute each leaf hash locally from the disclosed fields using SHA-256. Compare byte-for-byte against the returned leaf hashes.
3. 3Reconstruct the Merkle inclusion path for each leaf and confirm it produces the disclosed tree head.
4. 4Fetch the same tree head from the two independent transparency services using the anchor timestamp; confirm both return the same head hash.
5. 5If any step disagrees, the record has been altered. If every step agrees, the record has not been touched since the anchor time.

What the ledger is deliberately not designed to do

Being explicit about the limits is as important as the guarantees. Confusing the two is where most 'blockchain for trust' projects lose their footing.

The ledger does not prove the reviewer is a real person. That is a job for the verification tier system (see the tiers whitepaper) — the ledger only proves that whatever the platform held as evidence, it held at the claimed time.

The ledger does not prevent the platform from taking a review down for legal reasons. GDPR erasure and DMCC compliance sometimes require removal. What the ledger prevents is a silent removal: every deletion is itself an anchored event.

The ledger does not distribute trust across untrusted validators — that would be a full blockchain, with different trade-offs. It publishes anchors to two independent transparency services, which is enough for the specific claim being made and dramatically simpler to operate.

The ledger does not touch personal data. Nothing on the log can be reversed to expose a reviewer, a moderator or a business identity, even under compromise of the platform database, because those fields are never included in the hashed payload.

“The right question to ask a review platform is not 'do you use blockchain' but 'can I, without your cooperation, prove that no review has been altered since publication'. Trust Ledger v2 answers that question in the affirmative.”

Summary and next steps

A trust ledger is worth exactly as much as the ability to audit it. Published anchors, a published recipe and an open-source verifier are the minimum bar; anything less is marketing.

For consumers, no action is required — the badge on every verified review already links to the ledger anchor. Clicking it and seeing a tick from the verifier is the whole ceremony.

For enterprise buyers and insurers, the ledger is now a procurement-grade evidence artefact. We supply signed export bundles on request under the standard DPA, and Q3 2026 will bring a self-service export endpoint.