Do I need your website to verify a certificate?

No. Every check can be done with a public block explorer and any SHA-256 tool. Open the transaction URL, read the input data as UTF-8, compare it with the payload hash, then re-hash the payload and the file. Nothing in that sequence involves our software, which is deliberate.

Why is my re-hash of the payload not matching?

Almost always YAML indentation. The payload appears in the certificate with leading spaces that are part of the file's formatting, not part of the payload being hashed. Strip the leading whitespace from each line before hashing and the value will match.

What happens if I lose the certificate file?

Less than you might fear, provided you know which transaction it was: the payload hash is on the chain, so the certificate can be reconstructed. What you must not lose is the original file, byte for byte — without it there is nothing to hash and compare, and re-saving a document changes its bytes.

What a Timestamp Certificate Contains

A timestamp certificate is a small file, and every field in it exists for a reason. Understanding what each one does is what turns the certificate from something you trust into something you can check.

The fields

A BlockchainSign certificate is a YAML file with these fields:

Field	What it is
`version`	The certificate format version
`provider`	Who issued it
`timestamp`	The block time of the transaction — the date being proven
`blockchain`	Which chain the record is on
`algorithm`	The hash function used, SHA-256
`payload_hash`	The hash of the payload block, and what appears on-chain
`tx_hash`	The transaction identifier
`tx_url`	A link to that transaction on a public block explorer
`payload`	Three lines: the delivery email, the file's SHA-256, and any metadata you supplied

The structure is deliberately boring. There is nothing proprietary, nothing encrypted, and nothing that needs our software to interpret.

Why the payload is hashed separately

This is the part worth understanding, because it explains the design.

The payload holds three things: an email address, your file's hash, and free-text metadata such as an author name or a project reference. It is not written to the chain directly — its own SHA-256 hash is.

Two reasons. First, keeping the on-chain data to a fixed 64 characters keeps the transaction cost predictable regardless of how much metadata you add. Second, the payload contains an email address, and there is no reason to publish that permanently on a public ledger.

The effect is a two-step chain of evidence: the file hashes to a value inside the payload, the payload hashes to the value on the chain. Both steps are reproducible by anyone with the certificate.

Verifying it yourself, step by step

You do not need us for any of this.

1. Check the transaction exists. Open tx_url. It resolves to a real transaction on a public explorer, with a block number and a timestamp.

2. Read what is on the chain. Find the input data on the transaction page and select "View as UTF-8". You will see the payload hash as readable text.

3. Compare it with the certificate. That string should match payload_hash exactly.

4. Re-hash the payload. Take the three payload lines exactly as they appear and hash them with SHA-256. The result should equal payload_hash. One caveat: YAML indentation adds leading spaces that are not part of the payload — strip them before hashing, or the value will not match.

5. Re-hash your file. shasum -a 256 yourfile.pdf on macOS or Linux, certutil -hashfile yourfile.pdf SHA256 on Windows, or use the free hash tool in your browser. Compare with the File SHA-256 line in the payload.

If all five check out, you have established that this exact file was committed to a public ledger at that block time, and that nothing has changed since.

What the certificate does not tell you

Being clear about the limits is what makes the rest credible:

Who created the file. The certificate records that someone held it. See proof of existence vs proof of authorship.
What the file contains. Only its hash is recorded. Anyone verifying the coverage needs the file itself, which is the property that makes this usable for confidential documents.
That the metadata is true. The free-text field says what you typed. It is fixed at that moment and unchangeable afterwards, which is useful — but the ledger does not check it.
Any legal status. It is evidence, not a registration or a right.

Keep the file, byte for byte

The most common way people lose the value of a certificate is by losing the exact file.

A hash covers an exact sequence of bytes. Re-saving a document, exporting it again, or letting an application rewrite metadata produces a different file with a different hash — and the certificate will no longer match. Archive the certified version separately and work on a copy.

The certificate itself is worth keeping too, though less critically: the payload hash is on the chain, so a certificate can be reconstructed from public data as long as you know which transaction it was.