Published demo Evidence
a published static restore-drill artifact you can inspect and verify.
this named demo Evidence bundle includes a recorded restore outcome, its drill public key, and versioned verification metadata. it is not live status or proof about a customer Team.
verify it (copy-paste, ~10 seconds)
the verifier runs offline with zero dependencies, and its full source ships inside the npm package — read it before you run it. it checks the Ed25519 signature on the Manifest, recomputes the dump's sha256, and replays the Audit-chain hashes. needs Node ≥20, nothing else.
curl -fsSO https://walwarden.com/proof/walwarden-demo-evidence-bundle.tgz curl -fsSO https://walwarden.com/proof/walwarden-proof-pubkey.pem npx --yes @walwarden/verifier --bundle walwarden-demo-evidence-bundle.tgz --pubkey walwarden-proof-pubkey.pem
expected output
OK: manifest signature valid for backup_job=bjob_proof_20260612 OK: manifest artifact sha256 matches for backup_job=bjob_proof_20260612 (d91ea6fdb014…) OK: legacy audit rows internally valid through seq=8 (8 audit events); source completeness not proven OK: 1 manifests verified, legacy audit row set valid; source completeness not proven
bundle sha256: 3bca0d291cd68383ee34b66daf61e225deca727f48effe14d150a1afac776713
This expected output is captured metadata for the published static artifact. A successful verifier run against the downloaded bundle and matching drill key is the verification result for that artifact.
what you're looking at
the bundle is three things, tarred together:
- an Ed25519-signed Manifest for the backup — what was dumped, its sha256, and the signature over the canonical JSON.
- an append-only Audit chain — every state transition of the backup and the restore drill, each row hash-linked to the previous one. edit any row and the chain breaks at that seq.
- a restore record with its outcome — the drill ran to
restore.completed, and that row sits inside the same chain.
these statements describe only the contents recorded in this named demo bundle, subject to its checksum and verifier result.
- backup job
- bjob_proof_20260612
- restore drill
- rjob_proof_20260612
- audit events
- 8 (chain-intact)
- generated
- 2026-06-12T23:32:59.528Z
how it was made
the repository producer invokes the shared Manifest, Audit-chain, restore, and Evidence-export modules for a synthetic demo database. the dump ships inside the bundle so the verifier can recompute its checksum. this does not establish production execution or deployment configuration.
the signing key is a drill key generated for this bundle; its public half is the .pem download above. this self-contained demo says nothing about another bundle, key, or environment.
what we do and do not claim today is tracked, with tracking issues, on the roadmap. to explore the product workflow, create a Team .
logical recovery windows have a separate proof lane:npm run proof:logical-recovery checks the baseline snapshot plus supported transaction-tail replay, schema-change resnapshot, cursor-gap fail-closed behavior, and unsupported-source rejection. that proof does not turn managed-provider provider-native physical recovery into a walwarden claim.