Step-by-step guide How to verify a blockchain-signed document yourself

What do you need?

• The signed PDF, as downloaded. Not a copy that has been opened and saved again, annotated, or printed to a new PDF. Each of those changes the bytes and therefore the hash.
• The Certificate of Completion. LedgerSign generates it for every completed document. Page 1 shows the document's SHA-256 hash, a fingerprint mark derived from it, the Hedera network, and the transaction id of the anchor.
• Any computer with a browser or a terminal. No software to install and no LedgerSign login.

Step 1: Hash the PDF

Compute the SHA-256 hash of the file. Pick whichever of these you have:

Browser. Open the verify tool and choose the file. It is hashed locally with the browser's WebCrypto API and never leaves your device.

macOS or Linux terminal:

shasum -a 256 signed-agreement.pdf

Windows PowerShell:

Get-FileHash signed-agreement.pdf -Algorithm SHA256

Each prints 64 hexadecimal characters. Case does not matter; PowerShell prints uppercase and the certificate prints lowercase, and they are the same value.

Step 2: Compare with the certificate

Put the hash you computed next to the one on page 1 of the certificate. If every character matches, the file you hold is byte for byte the document that completed signing. The certificate also draws a fingerprint mark generated from the hash, so a visual glance can catch an obvious mismatch before you compare character by character.

A match here already tells you a lot: the certificate and the file belong together. What it does not yet tell you is whether the certificate itself is genuine, or when the document existed. That is what the ledger is for.

Step 3: Read the anchor on Hedera

The certificate carries a transaction id in the form 0.0.481…@1757768531.265460534 and names the network. Use either route:

On HashScan

Open hashscan.io, pick the network, and search for the transaction id, or scan the second code on the certificate. The transaction page shows a consensus timestamp, the topic it was written to, and the message. The message is a small JSON record; its document_hash field is the value to compare with your hash from Step 1.

Through the mirror node API

Mirror nodes use a slightly different id format: the @ becomes a hyphen, and so does the last period. 0.0.481@1757768531.265460534 becomes 0.0.481-1757768531-265460534. Then:

# 1. Transaction record, including its consensus timestamp
curl https://mainnet-public.mirrornode.hedera.com/api/v1/transactions/0.0.481-1757768531-265460534

# 2. The topic message written at that timestamp (base64-encoded)
curl https://mainnet-public.mirrornode.hedera.com/api/v1/topics/messages/<consensus_timestamp>

# 3. Decode it
echo '<message>' | base64 --decode

The decoded JSON contains document_hash. If it equals your Step 1 hash, the Hedera network recorded this exact file at that consensus timestamp. The verify tool performs these calls for you and shows the result.

What if the hashes do not match?

Work through the causes in order of likelihood:

1. A derivative file. Most mismatches are copies that were re-saved, annotated, flattened, compressed by an email gateway, or printed to PDF. Get the original download from the sender or from the LedgerSign dashboard and try again.
2. The wrong version. A document that was corrected and re-sent has a new completion, a new certificate, and a new anchor. Make sure the certificate and the PDF come from the same completion.
3. The wrong network. Check that the network selected on HashScan or in the mirror node URL matches the one named on the certificate.
4. Alteration. If the file is an original download, the certificate is from the same completion, and the hashes still differ, the file is not the document that was signed. Treat it accordingly, and use the audit trail to establish what was.

Do I need LedgerSign for any of this?

No. Every step uses the file, the certificate, and public Hedera infrastructure. If LedgerSign were offline, or no longer in business, the anchor would still be on the ledger and the arithmetic would still work. After an account is cancelled, documents remain exportable for 30 days, and anchors written before then stay verifiable indefinitely. That independence is the reason the mechanism exists; read what a blockchain e-signature is for the reasoning.

What does a successful verification mean?

Three agreements, file to certificate, certificate to ledger, ledger to file, establish that the document in your hands is, byte for byte, the one that completed signing, and that it existed in that form no later than the consensus timestamp. They do not establish who signed; that comes from the consent record and audit trail summarized on the certificate, which name each signer's email, the time of each action, and the IP address and browser used. For the mechanics behind each step, see how document hashing and blockchain anchoring work.