GetProofAnchor logo
GetProofAnchor
Verifiable web evidence
Dashboard
← Back to tutorials

Evidence ZIP explained — file by file

Open the ZIP and you'll find around 24 files in 4 directories. Here's what each file is for, and why none of them are optional.

An Evidence ZIP bundles the captured page together with a self-contained, offline-verifiable trust kit — every file needed to prove later that the package wasn't tampered with, even years from now, without ever contacting GetProofAnchor.

Tutorial Evidence ZIP SHA-256 Offline-verifiable Verification ~8 min read
Quick overview

The Evidence ZIP isn't just an archive — it's a self-contained verification kit. Captured content + capture context + four independent integrity layers + a bilingual verification guide for forensic experts. All offline-verifiable, no GPA required.

1) What it is
Self-contained, portable evidence package
2) What's inside
Every file, grouped by purpose
3) Integrity layers
Four independent cryptographic anchors
4) How to verify
Four steps, three open-source tools

What is the Evidence ZIP?

The Evidence ZIP is a portable, self-contained package you can export from any proof. Format identifier: getproofanchor-evidence-1. A typical bundle is around 24 files / ~3 MB, organized into four directories. It's designed to leave your account — for archiving, attaching to a case file, submitting to a regulator, or sending to a third-party reviewer.

The decisive feature isn't "just export" — it's that the package can later be verified completely offline , with only standard open-source tools. No internet connection, no GetProofAnchor service, no account.

Why offline-verifiable matters

Every external dependency that verification might need is frozen inside the ZIP itself: the cryptographic manifest, the proof's hash-chain entries, the Bitcoin OpenTimestamps receipt, the qualified TSA's full certificate chain, and even a snapshot of the EU Trusted List (LOTL) that proves the TSA was officially recognized at the moment of stamping. If GetProofAnchor disappeared tomorrow, your Evidence ZIP would still verify exactly the same — by anyone, anywhere, with a laptop and Python.

What's actually inside (every file, grouped by purpose)

Open the ZIP and you'll see something like this. Files are grouped here by what they do — captured content, how the capture happened, the cryptographic integrity layers, and human-readable docs.

Group A
The captured content

What the page actually was at capture time.

  • screenshot.png — full-page screenshot rendered at capture time, captured by Playwright (Chromium) at 1280px viewport width with full-height scroll
  • page.html — the captured DOM/HTML at capture time — useful for inspecting structure, links, and scripts that were actually delivered
  • content.txt — extracted plain text content — what a reader would actually have seen on the page, stripped of markup
Group B
Capture context

How the capture happened — the audit trail.

  • proof.json — the main proof record: Proof ID, source URL, final URL after redirects, capture timestamp, all SHA-256 fingerprints (content, screenshot, raw HTML), capture mode (server/browser), eIDAS status, anchor info
  • capture/capture_meta.json — detailed forensic metadata about the capture itself: capture engine (Playwright + browser version), user agent, viewport, full page dimensions after lazy-load scrolling, consent dialogs auto-handled and the method used, AI calls used, scroll rounds, image-load status, visual quality score, success verdict
  • capture/capture_meta.sha256 — SHA-256 of capture_meta.json stored separately — referenced by the eIDAS payload so the capture metadata is also covered by the qualified timestamp
Group C
The trust stack — four cryptographic integrity layers

Each layer is independent. Defeating any one doesn't break the others.

Layer 1 — File integrity
  • manifest.json — the integrity baseline: SHA-256 hash of every other file in the package + chain head + anchor and eIDAS metadata. Verification always starts here. Any byte changed in any file fails the check.
Layer 2 — Append-only hash chain
  • chain/proof_chain.jsonl — this proof's events in the global SHA-256 hash chain (one JSON object per line: seq, event_type, prev_hash, data_hash, entry_hash, created_at). Inserting or modifying any past entry breaks the chain.
  • chain/chain_head.json — snapshot of the chain head this proof was anchored to — the seq number and entry hash. Used to verify the chain's last link.
Layer 3 — Bitcoin OpenTimestamps anchor
  • anchor/anchor_payload.json — the minimal data structure that was committed to Bitcoin: chain head hash + observed UTC time + format version. Hashed canonically before stamping.
  • anchor/anchor_receipt.ots — binary OpenTimestamps receipt containing the Merkle path back to a Bitcoin transaction. Once confirmed, the timestamp is preserved by the entire Bitcoin network — not by GetProofAnchor.
Layer 4 — eIDAS qualified timestamp

Eleven files together form a complete, self-contained eIDAS verification kit.

  • timestamp/eidas.tsr — binary RFC 3161 TimeStampResp from the qualified Trust Service Provider — CMS-signed, in the same standard PKI format used by EU courts and regulators
  • timestamp/eidas_payload.json — the exact data that was timestamped, in canonical JSON (sorted keys, no whitespace): content_sha256, raw_html_sha256, screenshot_sha256, capture_meta_sha256, source_url, final_url, captured_at, proof_id. Format identifier: getproofanchor-eidas-stamp-3.
  • timestamp/eidas_payload.sha256 — SHA-256 of the payload above. This exact hash is the imprint embedded in the RFC 3161 timestamp, linking the timestamp cryptographically to the captured data.
  • timestamp/eidas_meta.json — high-level eIDAS status: provider name (currently SK ID Solutions, Estonia), TSA URL, exact timestamp time, status
  • timestamp/<proof_id>.tsa_signer_cert.pem — X.509 certificate of the actual TSA timestamping unit that signed the timestamp — the leaf cert in PEM form
  • timestamp/<proof_id>.tsa_certs.pem — the full PEM certificate chain: signer + intermediate CA + root CA. Lets you validate the chain offline without fetching anything.
  • timestamp/<proof_id>.tsa_certs.json — same chain in JSON form (subjects, issuers, serial numbers, validity periods, SHA-256 fingerprints) — easy to read without parsing PEM
  • timestamp/<proof_id>.qualified_context.json — pointer linking the TSA to the EU Trusted List snapshot used to confirm its qualified status at the moment of stamping
  • timestamp/eu_trusted_list_snapshot.bin — frozen XML snapshot of the EU List of Trusted Lists (LOTL), downloaded from ec.europa.eu at the moment of stamping (~470 KB). This is what proves the TSA was officially recognized as qualified under eIDAS at that exact moment — no need to trust any third party, ever.
  • timestamp/eu_trusted_list_snapshot.meta.json — metadata about the LOTL snapshot: source URL, download time, SHA-256, byte size
  • timestamp/<proof_id>.eidas_verification_report.json — internal eIDAS verification report produced at stamping time: status (granted), policy OID, hash algorithm, imprint digest, signature_verified flag, full TSA cert chain summary
Group D
Documentation

For humans, not for machines.

  • README.md — bilingual (English + Czech) verification guide for forensic experts. Walks through all 4 verification steps with copy-paste commands using only python3, openssl, and the ots client.
  • report.pdf — human-readable Evidence Report (~1 MB). Formatted summary with Proof ID, captured URLs, timestamps, all SHA-256 fingerprints, blockchain anchor info, eIDAS status — suitable for case files and printouts.

Four independent integrity layers

The trust isn't a single mechanism. It's four independent layers, each backed by its own files in the ZIP. Defeating any single layer doesn't break the others — and an attacker would need to defeat all four simultaneously, including breaking Bitcoin and forging an EU-qualified TSA signature, to forge a single proof.

Layer 1
File integrity (SHA-256 manifest)

Hash of every file in the package. If any byte of any file changes — even reformatting JSON whitespace — verification fails.

Files: manifest.json

Layer 2
Append-only hash chain

This proof's events live in a global SHA-256 chain. Each entry contains the hash of the previous one. Inserting or modifying any past entry breaks the chain mathematically.

Files: chain/*

Layer 3
Bitcoin OpenTimestamps anchor

The chain head is anchored to the Bitcoin blockchain via OpenTimestamps. Once confirmed, the timestamp is preserved by the entire Bitcoin network. Backdating becomes infeasible.

Files: anchor/*

Layer 4
eIDAS qualified timestamp

RFC 3161 timestamp from an EU-qualified TSA, with the full certificate chain and a frozen EU Trusted List snapshot included. Legally recognized in EU/EEA per Regulation (EU) 910/2014.

Files: timestamp/*

All 4 verifications PASS → the package is cryptographically intact, not just trusted. Each layer can also be verified independently to prove a specific property: file integrity, chain consistency, time of existence (twice — by Bitcoin and by EU-accredited TSA).

How to verify (the 4-step procedure)

The bilingual README.md inside the ZIP walks you through verification with copy-paste commands. The process maps one-to-one to the four integrity layers above:

  1. Step 1 — File integrity — A python3 script reads manifest.json, recomputes SHA-256 of each file, and compares. PASS = nothing in the package has been added, removed, or modified.
  2. Step 2 — eIDAS qualified timestamp — openssl ts -verify against eidas.tsr + eidas_payload.json + the bundled tsa_certs.pem. (A pure-Python alternative is included for environments without openssl.) PASS = the captured data existed at the timestamped moment, and the signature came from the qualified TSA recorded in the EU Trusted List snapshot.
  3. Step 3 — Bitcoin anchor — ots verify anchor/anchor_receipt.ots -d <payload_sha> — or upload the receipt to opentimestamps.org, or check the Bitcoin transaction directly on a public block explorer. PASS = the chain head was committed to a specific Bitcoin block.
  4. Step 4 — Hash chain — A python3 script walks chain/proof_chain.jsonl, recomputes each entry hash from (prev_hash | event_type | proof_id | data_hash), and confirms the link to chain_head.json. PASS = the internal event log is intact.

All 4 PASS → the package is cryptographically intact. The Bitcoin step also requires network access (or alternatively, just verify the transaction ID on a public explorer); steps 1, 2, and 4 work entirely offline.

Tools you'll need
  • python3 — everything works on Linux, macOS, and Windows. Used for steps 1, 2 (alternative path), and 4.
  • openssl — standard on Linux/macOS; on Windows use Git Bash or WSL. Used for the canonical eIDAS verification (step 2).
  • ots (from pip install opentimestamps-client) — for the Bitcoin OpenTimestamps verification (step 3). Optional — you can also verify by uploading the receipt to opentimestamps.org or checking the Bitcoin transaction on a block explorer.

Best practices for sharing

  • Share the ZIP exactly as exported. Don't re-zip, rename files, or "clean it up." Verification depends on every file path and every byte being identical to what was generated.
  • Store on read-only or write-once media when possible. Helps demonstrate chain of custody if the evidence is later challenged.
  • Keep Proof ID and capture timestamp visible in your notes or cover page. They're also inside proof.json and report.pdf, but a quick reference makes case files easier to navigate.
  • Point reviewers to README.md inside the ZIP. It has copy-paste verification commands in both English and Czech, and explains exactly what each PASS means.
  • Don't extract single files for forwarding. Verification requires the full package — manifest, chain, anchor, eIDAS kit. Always send the complete ZIP.
Try it now

Export an Evidence ZIP from a proof, then verify it. You'll see exactly how strict the integrity checks are — and how the package verifies even fully offline.

Create proof → Verify ZIP →

Not legal advice. Admissibility depends on jurisdiction and circumstances.

Next tutorial

Continue with: Browser widget — install, connect API key, capture behind login (Enterprise & Business).

Open widget tutorial → Back to tutorials →