Free · no account · nothing stored

Verify a proof bundle

Paste a self-contained proof bundle and get the closed verdict: ANCHORED_VALID, SIGNED_PENDING, BROKEN, or INSUFFICIENT_PROOF. No network call is made — the bundle you paste is the entire input.

The ceiling here, and why it exists

This page can never return SIGNED_PENDING or better.

ANCHORED_VALID requires an anchor verified against material pinned in advance — a Bitcoin block-header source, Rekor’s log key, or a trusted TSA root. This service pins nothing on your behalf, because a hosted default "trusted root" would reintroduce exactly the vendor trust the anchoring layer exists to remove. Anchors you supply are reported as asserted, counted separately, and do not contribute to the verdict.

That is the same ceiling a default library deployment has. It is not a limitation of the web page; it is the honest state of any verification performed without material you pinned in advance.

Do it properly

Verification performed by the vendor, on the vendor’s server, is a convenience. The run that matters happens on your machine, against a DID document you fetched yourself.

# 1. Fetch the signing key document yourself, over TLS.
curl -s https://witness.getvda.ai/.well-known/did.json > did.json

# 2. Verify from your own copy. No network, no dependency on us.
npx witness-dao verify --bundle ./proof.json --did ./did.json --json

A bundle that supplies its own DID document proves only internal consistency: a forged record with a matching forged key verifies, necessarily. Obtaining the key independently is what makes the check adversarial rather than ceremonial.

Reading the four verdicts

Verdict	Means	Do
`ANCHORED_VALID`	Signature, chain and an independently verified external anchor all check out.	Compliance-grade, subject to the binding confidence of the underlying event.
`SIGNED_PENDING`	Tamper-evident, but not externally anchored — its existence in time rests on the issuing service’s own log.	Never describe it as verified. Not provable against the vendor, and not compliance-grade.
`BROKEN`	Integrity affirmatively failed. The bytes do not match what was signed, or the chain is discontinuous.	Treat as a security incident until tampering has been excluded.
`INSUFFICIENT_PROOF`	The material supplied was incomplete. This is not tampering.	Fetch the predecessor chain, the DID document or the anchors, and retry.

The distinction between the last two is load-bearing. The CLI even gives them different exit codes — 3 for BROKEN, 4 for INSUFFICIENT_PROOF — so a monitored job cannot quietly conflate a gap with an accusation.