Ask any document: does your issuer stand behind this?

Forgery is now free

Until recently, a convincing forged certificate took skill, software, and nerve. Today anyone can ask a chatbot for a pixel-perfect insurance certificate, bank statement, employment letter, or test report — correct letterhead, plausible reference numbers, clean typography — in under a minute, at zero cost. Every control that relies on a document looking right is already obsolete.

Detection is an arms race that defenders lose: each generation of fakes is trained against the last generation of detectors. Attestation doesn't play that game. A document either hashes to a value the issuer's own domain stands behind right now, or it doesn't — and no improvement in generative models changes that arithmetic. The organizations that adopt issuer-side verification early aren't taking a bet on a trend; they're exiting an arms race they can't win.

How it works

Documents carry a verify: line pointing at the issuer's domain, e.g. verify:issuer.example.com/claims. Clip mode: select the text. Camera mode: snap and OCR it. Either way, the text is normalized, hashed with SHA-256, and looked up at the issuer's URL. You decide upfront whether that domain is an authority on the claim.

The bigger picture (once the basics click)

Taken together, the use cases add up to more than a single product: a decentralized way to check documents and claims of every kind. It works the way the web and email do — as an open standard anyone can implement, not a service anyone signs up to.

• It's a standard, not a company. The rule is simply text → normalize → SHA-256 → GET the issuer's domain. Any issuer can adopt it without permission, accounts, or fees.
• No central database. There is no master registry of valid documents and no single operator to trust, subpoena, breach, or switch off. Nobody — including us — holds a list of who verified what.
• Under ~195 sovereign roots at the top. A trust chain terminates at whoever has actual jurisdiction over the issuer — the sovereign that could subpoena or raid them under a court order. There are fewer than 195 such national roots, one per country. Beneath each, countless issuers — a hospital, a council, an insurer, an appraisal board — run their own hash endpoints on their own domains, answering only for their claims, with the sovereign above them able to vouch for (or disown) them. A handful of intergovernmental organizations (the UN, WHO, WIPO) are roots in their own right — not because they're large, but because no single nation has jurisdiction over them: the UN headquarters in Manhattan sits on international territory no US court order can reach. The "system" is the sum of all these independent servers under a small set of sovereign roots.
• Definitively decentralized. Trust is rooted in DNS — the same globally distributed namespace that already decides that gov.uk is the UK government and irs.gov is the US tax authority. Verification inherits that.
• Each country runs its own trust chain. Each issuer endpoint names the URL of the authority that endorses it, and a verifier walks those links upward to a national root — e.g. law-society.org.uk/v/… → gov.uk/verifiers/…, or a US state board → asc.gov/v/…. The chain is built from these declared endorsement URLs, not from domain structure: a multinational's uk. and us. endpoints can point at entirely different national authorities. Jurisdictions keep their own authorities; nothing is centralized across borders, and no country depends on another's infrastructure.
• Human in the loop — dual-channel trust. Verification and human judgement happen together, not in sequence, on two channels at once: the person reads the domain and trusts their gut, while the device walks the authority chain to a sovereign root. The machine does the maths — normalize, hash, look up — and the person weighs the result: “it came back verified, the issuer's domain (gmc-uk.org) is one I accept, and the endorsement chain makes sense — so I'll trust this, for now.” Equally, the human is the one who balks at “verified, but by djwgwbdss.com, with no chain behind it — I've no basis to trust that domain on its own.” A green tick is an input to a human decision, not the decision itself — and because issuers can revoke, that trust is only ever for this moment.

The plumbing is deliberately boring: a verification is a plain HTTPS lookup against the issuer's own server, answered live — the document carries a link, and checking it is like checking a tracking number. That live answer is exactly why a claim can be revoked the instant an issuer changes its mind. (No ledger, token, or consensus network is involved; if you're weighing this against a blockchain or an NFT credential, that comparison is on the how is this different page.)

What problems does this solve?

Fraud, safety, security, compliance, authenticity — unverified documents cause harm across every sector. We've mapped the landscape:

Browse all use cases →

What "Verified" means (and doesn't)

• Verified means: the domain in the verify: line currently attests to the hash for the extracted text above it.
• It is not "ground truth": the issuer can be wrong, malicious, or out-of-date.
• The human decides whether that domain is an authority for the claim in question.
• Look out for lookalike/typosquatted domains: while much of verification is automated the domain should be shown prominently for humans to judge or not as part of a "trust or don't trust" decision.

Verifications are revocable

Revocation is part of trust. Issuers can update or withdraw claims over time, so the result reflects what they stand behind today. Some issuers may return an operational instruction, e.g. Stolen ID — please retain/cut in half and contact https://example.com/stolen_and_found quoting reference 283762..

Privacy model

Text normalization + SHA-256 happen on-device (Clip mode never sends your text anywhere; Camera mode runs OCR on-device too). The only network step is a hash lookup. The science of one-way hashes is explained at one-way-hash.html, and we go into the rest of the guarantees in the Privacy Declaration.

Does this depend on one person sticking around?

No — by design. It's an open standard (Apache 2.0), publicly disclosed as unpatentable prior art, with no trademark to capture. Every verification endpoint is a static file on the issuer's own domain, not on any infrastructure this project runs. If the project stopped tomorrow, every deployed endpoint keeps answering, and anyone can carry the spec forward. That's the opposite of the usual “what if the vendor disappears?” risk.