Do not take this siteat its word.Every page here publishes a SHA-256 of its own text at /transparency.json. Recompute it in your own browser and confirm the content is exactly what we published. We sell proof, so it would be strange to ask you for trust.

That the page text you just fetched is byte-for-byte identical to what our build published. If a word had been changed after the fact, by us or by anyone else, the SHA-256 would differ and the check would fail. That is tamper-evidence. It is deliberately not a claim of cryptographic identity: on its own, a published manifest could in principle be rewritten by whoever can deploy the site. Sealing the manifest into an append-only transparency log is what removes that assumption, and we tell you on this page whether that has happened for the build you are looking at.

Because we sell verifiability, and a vendor who asks you to take their marketing on trust while selling you proof has an obvious problem. If we tell you that every payment intent produces a receipt you can check yourself, the least we can do is let you check the page making that claim. It is also a real test of the idea: the same primitive that seals a payment intent seals this build. If it is too much trouble to run on our own website, it is not a serious offer to run on your treasury.

Do not trust the button on this page either. Fetch the Markdown twin of any page by appending .md to its path, for example /quantum-safe-payments.md, and run it through any SHA-256 implementation you like: shasum -a 256, openssl dgst, a Python one-liner. Then compare the result to the value for that route in /transparency.json. The tool on this page does exactly that in your browser and nothing more. A verification you have to trust us to perform is not a verification.

Because the Markdown twin is the content. Our HTML carries build-hashed asset URLs, inline scripts, and framework markup that change between deploys without a single word changing, so a hash of the HTML would move constantly and prove nothing about the words. Hashing the twin means the number moves when the meaning moves, which is the only thing worth attesting to. The twins are generated from the rendered page at build time, so they are not a separate document we could quietly edit.

Check the readout above the verifier: it reports the state of the current build honestly rather than aspirationally. Publishing a hash is tamper-evidence. Sealing that hash into an append-only, RFC 6962 style log with independent witness co-signatures is what makes it non-repudiable, because at that point we cannot quietly rewrite history either. The plumbing is built and the receipt is published at /attestation.json. When a build is sealed, that file says so and carries the receipt; when it is not, it says that instead.