How any party verifies a SiteSealed record without an account
Verification is designed for the opposing party, expert, lawyer or arbitrator, not only for the person who created the record. Public lookup is free, while the exported Evidence Report carries the source material needed for independent checking.
Start with the record identifier and the exact original
A public SiteSealed record is addressed by its record identifier. Entering that identifier in the verification interface retrieves the public receipt and proof bundle; it does not disclose the private Recovery Kit or decrypt private storage. The canonical Evidence Report contains the visible original and embeds the exact original as an attachment, so a recipient can work from the same bytes that were sealed rather than from a screenshot or recompressed copy.
Recalculate SHA-256 over the exact file and compare the result with the recorded file digest. If one byte differs, the digest differs and the file-integrity check fails. For a live web capture, the report also carries the canonical capture manifest and distinguishes client-reported location and time from hardware-attested facts. For an imported file, original capture time, place, author and sensor origin remain expressly unverified.
Recompute the evidence record and inspect its scope
The proof bundle contains the stable fields used to derive the evidence digest. Independent verification reconstructs the canonical representation and checks that its SHA-256 result matches the digest presented to the external rails. This catches a receipt whose fields were reordered incorrectly, substituted or altered after sealing. The report also identifies the schema and protocol versions required to interpret those fields.
A successful digest calculation answers a narrow question: the exported data is internally consistent with the committed fingerprint. It does not prove that every client-supplied statement is true. Read the scope section before reading status colours. It separates cryptographically proven identity and integrity, server-bound context, browser-reported claims and facts for which the system has no attestation.
Validate the RFC 3161 token as the rail it actually is
When a timestamp token is attached, compare its message imprint with the SiteSealed evidence digest, validate the CMS signature, confirm the signer binding and build the certificate path under the stated trust policy. Preserve the complete token rather than a provider dashboard screenshot. These checks can be performed with standard cryptographic tooling and do not require access to SiteSealed's database.
The current Evidency response comes from a sandbox. Even when its signature and pinned sandbox chain validate, it remains test-only, not qualified and without qualified eIDAS legal effect. An independent verifier must retain that qualification status in the conclusion. A future production token would additionally require the production provider and service to be qualified under the applicable EU Trusted List and the production validation policy to pass.
Verify the Ethereum anchor from any independent node
Fetch the full transaction by its 66-character hash from any Ethereum mainnet node. Confirm the chain ID, sender, recipient, block and finalized receipt. Decode the transaction calldata as the ASCII domain marker SSLD, followed by the protocol version byte and the 32-byte Merkle root. Compare that root byte-for-byte with the root printed in the Evidence Report; do not rely on a shortened explorer label.
Next start with the record's leaf hash and follow every inclusion-path entry in order. Each entry states whether the sibling belongs on the left or right before hashing the pair under the declared Merkle protocol. The final value must equal the root committed in the transaction. This proves that the record leaf was included in the anchored batch without revealing sibling records. It does not prove the truth of the original content.
Record failures as carefully as successes
A missing token, pending transaction, invalid signature, mismatched digest or incomplete path is not a cosmetic warning. It changes the proof state and must remain visible. SiteSealed therefore keeps NOT ANCHORED, sandbox, ALPHA and NOT QUALIFIED wording instead of collapsing partially complete rails into a single reassuring badge. Verification should report each rail independently and state which checks were not possible.
The result is portable by design. If SiteSealed disappeared, the exact original, receipt, timestamp token, Ethereum transaction data and Merkle path should still permit reconstruction with open tooling and public infrastructure. That is the practical meaning of proof over storage and verification by the adversary: the evidence does not become true because SiteSealed says so, and it does not become unverifiable because the portal is unavailable.