Don't trust the bundle. Verify it yourself.
Drop a Swarrm bundle below and this page checks its signed receipts and presented log history entirely in your browser. Nothing is uploaded. The Rust/WASM checker is a separate implementation from the Python producer.
bundle.json herepipx run swarrm verify bundle.json → runs the same tamper-evidence checks on your machine.
Files you drop are read locally and never uploaded. Choosing your bundle causes no bundle-related request. The page and WASM load from this site, and the “verify our sample” buttons fetch our sample file; your own bundles never leave the page.
Real artifacts, not handcrafted demos
These come straight from our public demo tenant. This offline page verifies the valid bundle at E1. The linked Evidence Report re-read its covering Base Sepolia staging anchor and verified its RFC 3161 token to the Sigstore Public Good TSA root retrieved from Sigstore's certificate-chain endpoint, earning E2 for every displayed receipt. The token remains non-qualified.
Evidence levels, briefly
Each level adds a requirement; this is not a score.
E0 · Signed receipt
The receipt's DSSE signature verifies. That authenticates the signed bytes, not the underlying action.
E1 · Presented history
E0 plus Merkle inclusion, key-log replay and signed-checkpoint consistency for the history presented—not latest history, capture/export completeness or independent time.
E2 · Public commitment
E1 plus a live report re-reading carried anchors; a row earns E2 only when one exact covering Base or Base Sepolia checkpoint is confirmed live and that same checkpoint digest has an RFC 3161 token verified to a TSA root independently supplied by the relying party.
E3 · Dual attestation
E2 plus the same receipt carries an evidence-issuer signature and a co-signature from an active non-issuer registered recorder, verified under the recorder key supplied by the relying party.
Valid evidence bundle
Five signed receipts in a checkpointed RFC 6962 log. The presented history verifies; its anchor and timestamp remain recorded claims.
Tampered bundle
The same bundle with one byte of history flipped. The signature and the inclusion proof both fail — as they must.
Evidence Report
The same bundle after its covering checkpoint was confirmed on Base Sepolia staging and its timestamp token verified to the independently retrieved Sigstore Public Good TSA root. E2 establishes public commitment—not the action time, completeness, qualification, or a legal conclusion.
What just happened
Five tamper-evidence checks plus one claim-binding check
- Signatures. Every receipt is a DSSE envelope signed with Ed25519; each signature is checked against the key that claims to have made it.
- Key history. Those keys aren't trusted on our say-so — the log witnesses its own keys (genesis, rotation, revocation), and the replay must be internally consistent for the history presented here.
- Inclusion. Each receipt carries an RFC 6962 Merkle proof that it sits at its claimed position under the signed checkpoint root.
- Consistency. Checkpoints must extend one another append-only. This proves the presented prefix is internally consistent; it cannot prove it is the latest key history. If an attacker omits a terminal key-history event and supplies a matching JWKS, that truncation is undetectable offline. Compare an independently obtained later checkpoint or key-log high-water.
- Checkpoint proof. The complete profile directly links every carried checkpoint. A declared sparse profile carries signed genesis, head and proof-relevant checkpoints with consistency proofs, and states that intermediate checkpoint history was not carried.
- Claim binding. If anchor or timestamp material is present, its checkpoint value must match. This offline check does not query Base Sepolia or independently trust the RFC 3161 certificate chain.
How this page checks the verifier files
Before checking your bundle, this page downloads two release files: the JavaScript module that loads the verifier and the WebAssembly (WASM) verifier itself. Your browser calculates a SHA-256 fingerprint for each file and compares it with the expected fingerprint built into this page. If either file differs by even one byte, the page refuses to run it and checks no bundle.
WASM release fingerprint shown by this page:
…
INTEGRITY.txt publishes the expected fingerprints for both files and pins the exact public source revision. On x86_64 Linux, following its pinned Rust and wasm-pack instructions reproduces the same bytes and fingerprints, so the release is inspectable rather than a black box.
What this does not prove: this check detects a changed module or WASM file relative to the fingerprints built into this page. It does not independently authenticate the page itself, prove that the verifier is correct, or prove that an evidence bundle is complete.