Proof that outlives the provider

Most compliance tooling asks you to trust the vendor.

The receipt lives in the vendor's dashboard. The verification link points at the vendor's domain. The audit trail is exportable, in a format the vendor defined, attested by the vendor's own signature. Every path to establishing that a document is genuine runs through the party with the strongest interest in it appearing genuine.

This usually goes unnoticed because it usually does not matter. It starts mattering at exactly the two moments the evidence was acquired for: when someone external is deciding whether to believe it, and when the vendor is no longer there.

The failure mode nobody plans for

Consider what happens to a vendor-hosted verification link when the vendor shuts down, is acquired and consolidated, or simply retires the product.

The link stops resolving. The dashboard export you took becomes a PDF with a logo on it. The cryptographic signature, if there was one, is checkable only against a public key that was published on a domain that now redirects to somebody's product page. What you are left with is a document and an assertion, which is what you had before you bought anything.

This is not a rare event. Infrastructure companies get acquired, pivot, and close constantly, and the retention obligations attached to the documents in question outlast a great many of them. Any evidence design that assumes the continued existence of the party providing it has a defect that only shows up at the worst time.

We took the opposite position early: the proof has to work when Lethra does not exist. That constraint shaped more of the verification design than anything else.

Three paths, each less dependent on us

Every deposit produces a receipt that can be checked three ways. The paths are progressive — each is more work and less dependent on us than the one before.

Path one: a scan, for someone with no technical background

A code printed on the document itself resolves to a page giving a plain answer: this was registered, on this date, under this regime, with this fingerprint.

This path is for the person whose document it actually is. Not the platform, not the platform's auditor — the individual who received a cancellation confirmation or a claim acknowledgement and wants to know whether it is real. They should not need to understand anything about hashing to get a truthful answer, and the answer should be legible in about four seconds.

This path depends on us entirely. That is acceptable because of what the other two do.

Path two: the full chain, for a lawyer or a sceptic

A verification page that takes a receipt and displays the entire signature chain: the receipt's own signature, the day certificate that scopes the key which produced it, the inclusion proof tying that receipt to a published daily root, the hardware signature over that root, and the external timestamp anchoring the root in time.

Everything is shown rather than summarised. Someone who wants to check each link by hand can, and someone who wants to hand it to their own security team can do that too.

This path still runs through our infrastructure, but it exposes enough that a determined reader can move to path three.

Path three: offline, for a court or an auditor

A command-line tool, run against the receipt and a published public key, with no connection to our systems at all.

The verifier reconstructs the hash, walks the inclusion proof to the root, checks the root's signature against the published key, and checks the external timestamp against the timestamping authority. It reports whether the receipt is genuine and what it attests to.

This path works if our API is down. It works if our domain has lapsed. It works if the company has been wound up and the infrastructure decommissioned, provided the recipient kept the receipt and the roots survive anywhere — in their own records, in a mirror, or in the timestamping authority's records.

That third path is the one that matters, and everything else in the verification design exists to make it possible.

Why the roots are published

An inclusion proof only means something if the root it terminates at is something you did not invent for this occasion.

So the daily roots are published, each hash-chained to the previous day. Chaining is what makes retroactive insertion detectable: to fabricate an entry in a past day's tree, you would have to change that day's root, which changes every root after it, which invalidates every proof anyone has ever been given.

Publication is what makes the chain checkable by someone who was not watching at the time. A root that only we hold is a root we could recompute. A root that has been public since the day it was made is a commitment.

And the external timestamp is what removes us from the question of when. An independent authority attests that a given root existed no later than a particular moment. We cannot backdate a root, because the attestation comes from a party with no relationship to us and no reason to accommodate us.

The commercial argument against building this

There is one, and it is not weak.

Every one of these paths makes us more replaceable. A partner who can verify their receipts without us has less reason to stay with us. A partner's auditor who can check our work without going through us has less reason to ask us anything, which means fewer touchpoints and less of the relationship that vendors normally cultivate.

Building a verification path that survives our disappearance is, from a narrow commercial view, engineering against your own retention.

We think that view is wrong here, and specifically wrong for this product. A trust layer that requires trust in the trust layer has not solved the problem it was hired for. It has moved the problem from is this platform trustworthy to is this platform's vendor trustworthy, which is a lateral move dressed as a solution.

The only version of this product worth building is one where the evidence stands without us. That is also, incidentally, the only version a serious compliance reviewer will accept, so the commercial argument is less one-sided than it first appears.

What this asks of a partner

One thing, and it is worth flagging because it is easy to skip.

Keep the receipts. The offline path needs the receipt itself, which we return at the moment of storage and which is small — a hash, some metadata, a signature. A partner who discards receipts and relies on retrieving them from us later has re-introduced the dependency the design was built to remove.

We recommend that partners keep their own copy of both the document and the receipt. Our copy is the rescue path and the attested one. Theirs is the one that works when we are not there. Neither is redundant, and the arrangement means no single failure takes out both.