swarrm
The proof machine — offline, no account

Don't trust us. Verify it yourself.

Drop a Swarrm record below and this page checks it’s genuine and unchanged — entirely in your browser. Nothing is uploaded. And it’s a completely separate checker from the one that made the record, so you’re not trusting a single black box. No account, ever.

Drag bundle.json here
or click to choose a file
No bundle handy? Verify one of our real ones:
▶ valid bundle (E2) ▶ tampered bundle
The in-browser verifier isn't loaded here. Rather than show you a fake result, here's the honest path — verification is offline and needs no account either way:

pipx run swarrm verify bundle.json  →  VERIFIED, on your machine.

Files you drop are read locally and never uploaded — open your Network tab and watch: zero requests. (The “verify our sample” buttons fetch our sample file from this site; your own bundles never leave the page.)

Real artifacts, not handcrafted demos

These come straight from our public demo tenant. The valid bundle is anchored on Base Sepolia and carries an RFC 3161 timestamp (evidence level E2). Download them, open the Network tab, and check for yourself.

E2 · VERIFIED

Valid evidence bundle

Five signed receipts in a checkpointed RFC 6962 log, anchored + timestamped. Verifies clean.

▶ verify it ⬇ download
NOT VERIFIED

Tampered bundle

The same bundle with one byte of history flipped. The signature and the inclusion proof both fail — as they must.

▶ verify it ⬇ download
HUMAN-READABLE

Evidence Report

The same bundle rendered as a plain-English report — the artifact you hand an auditor.

↗ open report ⬇ download

What just happened

The six checks this page ran, in order
  1. Signatures. Every receipt is a DSSE envelope signed with Ed25519; each signature is checked against the key that claims to have made it.
  2. 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.
  3. Inclusion. Each receipt carries an RFC 6962 Merkle proof that it sits at its claimed position under the signed checkpoint root.
  4. Consistency. Checkpoints must extend one another append-only — a rewritten or truncated history fails here.
  5. Checkpoint chain. Every checkpoint is itself signed and linked to the previous one.
  6. Anchor & timestamp. If present, the on-chain anchor and RFC 3161 timestamp are bound to the exact checkpoint root — establishing existence and time to someone who wasn't watching.

verifier build (sha256 of the WASM this page loaded):
…
compare to INTEGRITY.txt and rebuild from source (verify-rs/) to confirm the verifier wasn't swapped. Trusting this page reduces to trusting that hash — which you can reproduce.