Offline · Zero-trust · Reproducible from source
Don't trust us.
Verify it yourself.
A sealed artifact carries its own proof. You re-derive it from the bytes on your own machine — you don't take our word, and you don't call our server. There isn't one.
This box is pinned to the digest of its original text. Change one character and watch it flip to REJECT — that's the entire product, running with zero network.
Why it's trustworthy
The trust model is: there is no trust.
0 accepted, 3 rejected. Drop it into CI to gate on the sealed file set — add --exact-dir when gating a build directory, so a file the seal never named is rejected too.Three ways to start
Check a sealed packet in under a minute.
Someone sends you a .vhevidence.json packet and the address they signed with. You confirm the bytes are unaltered and the signer is who they claim — offline.
In your browser
No terminal. Open one offline page (SHA-256 sidecar) — it has a built-in sample packet, so you can watch ACCEPT, tamper one byte, and watch REJECT before you ever drop a real packet in. The page contains no network API at all — the devtools Network tab stays empty. For CI/production gating use the node standalone, card 02.
In the terminal
One file, zero dependencies, Node core only. Built for CI gating.
curl -O https://verifyhash.com/verify-vh-standalone.js
node verify-vh-standalone.js packet.json --vendor 0x…Published SHA-256:699485793b6fb0e79281993e1c06e78ff331d26407796e871028200d29663b4f
From npm
Install the full vh toolchain — hash, anchor, seal, verify.
npm i -g verifyhash # or, no install: npx --yes -p verifyhash vh
vh --helpDon't trust our checksum either.
Rebuild the verifier from source in memory and confirm it's byte-for-byte what we published —
node verifier/build-standalone.js --check. The build-provenance
manifest maps every published hash back to the exact source modules it inlines, so you can root trust in code you read. Read the full source on GitHub →
For your coding assistant
Let your AI agent wire it up.
Paste this into Claude Code, Cursor, or any coding agent. It reads the machine-readable llms.txt and sets verifyhash up in your project — download, CI gate, and all — while keeping the honest trust boundary intact.
Add verifyhash (read https://verifyhash.com/llms.txt) to this project:
1. download the standalone verifier and check its published SHA-256,
2. add a CI step that runs it on any *.vhevidence.json artifacts and fails the build on exit 3,
3. show me how to seal our build outputs.
Keep verifyhash's trust boundary intact — a seal proves tamper-evidence + signer-pin, not time or identity.The honest part
What a seal proves — and what it does not.
Most tools oversell. A verifyhash seal makes exactly two guarantees, and we lead with the four it doesn't, so nobody builds on a promise we never made.
- →Tamper-evidence. Every byte re-derives to the same root, or the check fails and names the file that drifted.
- →Signer-pin. The packet was signed by the exact key whose address you pinned — a forged or swapped signature is rejected, never silently passed.
- →Build integrity. The published verifier is faithfully built from the source you can read.
- →A trusted timestamp. "Sealed at time T" needs an external anchor — a seal alone can't date itself.
- →That the logic is correct. Reproducibility proves the build, not that the source does what you want. Read it; run the conformance corpus.
- →Real-world identity. A pinned address is a key, not a legal person.
- →Anything about the producer's intent. It attests bytes, not honesty of the URI they attached.
The head-on question
Why not sha256sum + a signed git tag — or cosign + Rekor?
Because for many needs those free tools are the right answer. Their strengths are real, and we state them as strengths — then say exactly what verifyhash adds, and what it does not do.
What sha256sum, a signed git tag, or cosign + Rekor already give you |
Real strengths: SHA-256 is a FIPS 180-4 hash; git + GPG and Sigstore are large, mature ecosystems your counterparty may already run; and Rekor's public transparency log records an inclusion timestamp — an existence bound you get out of the box. If these cover your need, use them. |
|---|---|
| What verifyhash adds | One offline, single-file verifier your counterparty runs with no toolchain, no account, no CA — no git/GPG install, no Sigstore account or OIDC identity, no certificate authority to trust; one file plus Node (or the browser page), run on the bytes in hand. Plus signer-pin + per-file tamper localization — a REJECT names the exact file that changed, not just a digest mismatch — and an optional permissionless existence anchor (the ownerless on-chain registry below: no account there either, only gas). |
| What verifyhash does NOT do | No trusted timestamp without the anchor — a seal alone never proves "sealed at time T"; Rekor gives an inclusion timestamp by default, while here that property arrives only once you anchor. And keccak256 is not a FIPS-approved hash — the Merkle cores here are keccak256, so a compliance regime that requires FIPS-approved digests end-to-end is better served by the tools above today. |
Permissionless anchoring
An ownerless registry, live on Polygon.
Anchor a file or repository hash on-chain; anyone can later prove content is byte-for-byte what was anchored — trusting no server, admin, or key.
Pricing
Verifying is free. Forever.
Checking proofs never costs anything — that's what keeps the trust story true. You pay only when you want verifyhash to be your trust anchor or run signing for you at scale.
- ✓ Verify any sealed packet, offline
- ✓ The browser + Node standalone verifiers
- ✓ Produce your own unsigned seals
- ✓ Anchor & read the on-chain registry
- → Be verifyhash-anchored — your customers pin one identity; seals verify as you
- → Managed signing & key custody done right (or bring your own — we never hold it)
- → Batch, policy-gated & compliance-pack evidence at scale
- → Priority support + integration help