Don't trust it.
Verify it.Verify a RankShield receipt yourself — signature, inclusion, consistency, witnesses, anchor.
Every RankShield protection produces a verifiable receipt. Paste one here and check it in front of you: the post-quantum signature, Merkle inclusion proof, consistency proof, witness quorum, and external anchor. None of it requires trusting RankShield — it's math you can run.
Is it
genuine?
The first check: the receipt is signed with a post-quantum signature (ML-DSA-65 with a classical algorithm). If the signature verifies against the known key, the record genuinely came from where it claims — and can't be forged, now or after quantum computers arrive.
Is it in
the log?
The receipt's hash climbs a Merkle path — combining with sibling hashes at each level — up to a single root. If that recomputed root matches the published, signed tree head, the record is provably included in the public log. One receipt, proven out of millions.
Was history
ever rewritten?
A consistency proof confirms the log was only ever appended to — nothing edited, nothing deleted. Everything in an earlier signed head is still present in a later one. Any tampering with the past would break this proof. The record is immutable, checkably.
Who else
saw it?
Independent witnesses co-sign the log's tree heads, so no single operator — not even RankShield — can present a private, forked version of history. A quorum of witnesses agreeing is what makes the log's state something you can trust without trusting any one party.
Five checks.
Zero trust required.
Signature, inclusion, consistency, witnesses, anchor — all pass, and the action is proven. Not because RankShield says so, but because the math checks out on data anyone can pull. That's what a receipt you can verify actually means.
What does it mean to verify a receipt?
To verify a receipt is to independently confirm — with cryptography, not trust — that a recorded action really happened as claimed and was never altered. Almost every security product is a black box: it tells you it blocked a threat, governed an agent, or protected your data, and you have no way to check. Logs can be edited after the fact, dashboards show whatever the vendor chooses, and generative AI makes fabricated evidence trivial. RankShield removes the need to take its word for anything. Every protection produces a receipt — a signed record of the action — that you, or your auditors, can verify by checking five independent things: the receipt's post-quantum signature (it's genuine), its Merkle inclusion proof (it's in the public log), a consistency proof (history was never rewritten), the witness quorum (independent parties co-signed), and an external anchor. Every one of these is math you can run yourself on public data, so verification works even if you assume RankShield is adversarial. That is the whole idea: trust replaced by proof you control.
How do you verify a RankShield receipt?
Two ways, both first-party and both requiring no trust in us. You can paste a receipt into the public verifier above and watch each check resolve, or point your own tooling at RankShield's open, read-only proof endpoints and verify continuously and automatically. Under the hood, verification runs the same five steps every time:
Check the composite post-quantum signature (ML-DSA-65 + classical) against the known key — proves the record is genuine.
Recompute the Merkle path to the signed tree head — proves the record is in the public log.
Check the append-only proof against earlier heads — proves history wasn't rewritten.
Confirm the independent witness quorum co-signed the head — proves no private forked history.
Confirm the external anchor — ties the log's state to an independent reference point.
Why is "verify it yourself" the strongest security claim?
Because it is the one claim that stays true when everything else can be faked. In an age where AI can fabricate a convincing screenshot, log, voice, or document, "we blocked the threat" and "your data is safe" are assertions with no defense against a determined skeptic — or a determined attacker planting false evidence. Verifiability changes the game by not relying on anyone's honesty. When a protection produces a receipt whose signature, inclusion, consistency, witness quorum, and anchor can each be checked against public data, the truth of the claim no longer depends on trusting the party making it; it depends on math that either checks out or doesn't. This is why RankShield builds proof instead of promises. It is also why the model is robust against RankShield itself: if we tried to fabricate a protection that didn't happen, or quietly delete one that did, the proofs would fail for anyone who checked. For auditors, regulators, insurers, and customers, that is a categorical upgrade — evidence you can independently confirm rather than a vendor's word you have to accept. "Trust us" is a liability; "verify us" is the product.
Who witnesses the log, and what is an external anchor?
These are the two checks that stop even the log's operator from cheating — and they're what make verification robust against RankShield itself. A transparency log is only as trustworthy as its guarantee that everyone is looking at the same history. On its own, an operator could in principle show one version of the log to one party and a quietly different version to another — a "split-view" attack — and each party's inclusion and consistency proofs would still pass against the version they were shown. Two mechanisms close that gap. First, independent witnesses: a set of separate parties observe the log and co-sign its tree heads, so a valid head requires a quorum of independent signatures, not just the operator's. If RankShield tried to present a private, forked version of history, it couldn't gather the witness quorum for it, and the fork would be detectable. Second, external anchoring: the log's state is periodically tied to an independent, hard-to-alter external reference point, giving an outside timestamped commitment to what the log contained. Together, witnesses and anchoring turn the log from "trust the operator not to rewrite it" into "the operator can't rewrite it without a quorum of independent parties and an external record disagreeing." That's the final piece of why verifying a RankShield receipt requires trusting no one: the signature proves origin, inclusion proves membership, consistency proves immutability, and witnesses plus anchoring prove that the history everyone sees is the same single truth.
Ask RankShield about verifying receipts.
What does it mean to verify a receipt?
To verify a receipt is to independently confirm — using cryptography, not trust — that a recorded action really happened as claimed and was not altered. A RankShield receipt is a signed record of an action (a protection, an agent decision, a payment attestation). Verifying it checks five things: that the signature is genuine, that the record is included in a public transparency log (inclusion proof), that history was never rewritten (consistency proof), that independent witnesses co-signed it, and that it is anchored externally. If all five pass, the action is proven — no trust required.
How do I verify a RankShield receipt?
Paste the receipt into the public verifier, or point your own tooling at RankShield’s open, read-only proof endpoints and verify continuously. The verifier checks the post-quantum signature, recomputes the Merkle inclusion proof to the published tree head, checks the consistency proof against earlier heads, confirms the witness quorum co-signed, and confirms the external anchor. None of these steps requires trusting RankShield — they are math you (or your auditors) can run yourselves.
What is a Merkle inclusion proof?
A Merkle inclusion proof is a short cryptographic path showing that a specific record is part of a larger append-only log, without needing the whole log. Each step combines your record’s hash with a sibling hash to compute the next level, climbing to a single root (the tree head). If the recomputed root matches the published, signed tree head, the record is provably included and unaltered. It is how you can trust one receipt out of millions without downloading them all.
What is a consistency proof?
A consistency proof shows that a transparency log was only appended to — never edited or rewritten — between two points in time. It proves that everything in an earlier signed tree head is still present, unchanged, in a later one. This is what stops an operator from quietly altering or deleting past records: any tampering would break the consistency proof. Together, inclusion and consistency proofs make the log both complete and immutable in a way anyone can check.
Why does RankShield use post-quantum signatures on receipts?
So that a proof trusted today stays unforgeable for years, even as quantum computers threaten classical cryptography. RankShield signs receipts with composite signatures — a post-quantum algorithm (ML-DSA-65) together with a classical one — so the record is protected against both today’s and tomorrow’s attacks, and is never weaker than classical signing. It is quantum-safe, not quantum-proof: standards-based durability, honestly described.
Do I have to trust RankShield to trust the proof?
No — that is the entire point. Verification is designed to work even if you assume RankShield is adversarial, because every check is something you can compute yourself from public data: the signature, the inclusion and consistency proofs, the independent witness co-signatures, and the external anchor. If RankShield tried to fabricate or alter a record, the proofs would fail. Trust is replaced by math you control.
Security you can check yourself.
Every protection, a receipt. Every receipt, verifiable. See why verifiability is the foundation of the whole platform.