Skip to content

Blockchain e-signature mechanics How document hashing and blockchain anchoring work

How a SHA-256 hash turns a signed PDF into a 64-character fingerprint, how that hash is written to Hedera, and why a single changed byte breaks the match.

Updated
Updated
Reading time
8 min read
Author
By the LedgerSign team

Key takeaways

  • SHA-256 turns any file into a fixed 64-character fingerprint. The same bytes always give the same fingerprint; one changed byte gives a completely different one.
  • Anchoring means writing that fingerprint to a public ledger with a network-assigned timestamp, where nobody, including the vendor, can edit it afterwards.
  • LedgerSign writes the anchor as a message on a Hedera Consensus Service topic. The transaction id on the certificate points at it.
  • Verification is arithmetic plus a lookup: re-hash the file, read the anchor, compare.

What is a document hash?

A hash is the output of a function that takes any amount of input and produces a fixed size result. SHA-256, the function LedgerSign uses, produces 256 bits, written as 64 hexadecimal characters. It is specified by the U.S. National Institute of Standards and Technology in FIPS 180-4 and is the same function that secures TLS certificates and most software downloads.

Three properties make it useful for documents:

  • Deterministic. The same bytes always produce the same hash, on any computer, in any language, forever.
  • Sensitive. Change one byte, a comma, a trailing space, and roughly half the output bits flip. Two documents that differ trivially have hashes that share nothing.
  • One-way. There is no practical way to reconstruct the document from its hash, or to build a second document that produces the same hash on purpose.

You can compute one yourself. On macOS or Linux, shasum -a 256 file.pdf prints it. On Windows, Get-FileHash file.pdf -Algorithm SHA256 in PowerShell does the same. The verify tool does it in the browser.

Why hash the final PDF and not the fields?

Because the final PDF is the artifact everyone keeps. Once the last signer finishes, LedgerSign renders the completed document with every signature, initial, date, and text field embedded, and that file is what is emailed to the parties and downloaded from the dashboard. Hashing anything else, the form data, the template, an intermediate draft, would prove the wrong thing. The question years later is always about the file in someone's hands, so the file is what gets fingerprinted.

This has a practical consequence: the hash is of the exact bytes LedgerSign produced. Opening that PDF in a viewer and saving it again, adding an annotation, or printing it to a new PDF creates a different file with a different hash, even if it looks identical. The original download is the thing to keep.

What does anchoring mean?

Anchoring means recording the hash somewhere that is public, timestamped by a party other than the vendor, and impossible to edit after the fact. A public blockchain fits all three. Every record is replicated across independent nodes, the network assigns the time, and history cannot be rewritten without the whole network agreeing to it.

The word anchor is deliberate. The document is not stored on the chain; it is tied to a point on it. The chain says: a document with this fingerprint existed no later than this moment. Anyone with the document can later show it is the one the anchor refers to.

How does LedgerSign anchor a document on Hedera?

LedgerSign uses the Hedera Consensus Service, which lets an application publish messages to a topic and have the network order and timestamp them. When a document completes:

  1. The final PDF is hashed with SHA-256.
  2. An anchor message is built: a small JSON record containing the document id, the document hash, the organization id, each signer's email, signing time, and IP address, and the completion time. The format carries a version number and is frozen once written, because on-chain records cannot be migrated.
  3. The message is submitted to LedgerSign's topic with a TopicMessageSubmitTransaction. LedgerSign's own account pays the fee; no customer holds tokens.
  4. The network returns a transaction id, which looks like 0.0.481…@1757768531.265460534: the paying account, then the time the transaction was created. LedgerSign stores it on the document and prints it on the Certificate of Completion.

Every Hedera mirror node keeps a copy of every message, and public explorers such as HashScan display them. The anchor is therefore readable by anyone, without any LedgerSign system involved. The reasons for choosing Hedera over other ledgers are in a separate explainer.

What is a consensus timestamp?

It is the time the network, not the sender, agrees the message was received. Hedera nodes run a consensus algorithm that produces a single agreed order and time for every transaction, with finality in seconds. That timestamp is what makes the anchor a statement about time that the vendor cannot backdate: LedgerSign could set any value it liked in its own database, but it cannot change the moment the network recorded the message.

The consensus timestamp is also the key used to fetch the message back. A mirror node returns the transaction record with its consensus timestamp, and the topic message can be read at that same timestamp. That is exactly what the verify tool does.

How does verification use these pieces?

Three checks, in order:

  1. Hash the file you have. If it matches the hash printed on the certificate, the file is the one the certificate describes.
  2. Read the anchor. Look up the certificate's transaction id on a mirror node or on HashScan and decode the message. It contains the document hash.
  3. Compare. If the on-chain hash matches your file's hash, the ledger confirms this exact file existed, unchanged, at the consensus timestamp.

None of the steps require LedgerSign to be online or cooperative, which is the point. The step-by-step verification guide walks through each one with the exact commands and URLs.

What can go wrong?

  • The file was re-saved. The most common cause of a mismatch is a copy that was opened and saved by a PDF viewer, annotated, flattened, or printed to PDF. The fix is to verify the original download from LedgerSign, not a derivative.
  • Hedera was unavailable at completion. Signing does not depend on the network. The document completes either way, and the anchor is submitted when the network is reachable again. Until then the document shows no transaction id.
  • Wrong network. Hedera runs a mainnet and test networks. The certificate names the network; a lookup on the wrong one returns nothing.
  • Genuine tampering. If the file is an original download and still does not match, it is not the document that was signed. That is the outcome the mechanism exists to detect.

Where does the mechanism stop?

Hashing and anchoring prove integrity and time. They do not prove identity: the hash does not know who clicked sign. Attribution comes from the consent record and the audit trail, which LedgerSign keeps for every document and summarizes on the certificate. They also do not judge content; a bad contract anchors as cleanly as a good one. Read what a blockchain e-signature is for the full list of what it does and does not establish, and the security page for how the two layers work together in the product.

See the proof layer
on your own documents

Send a document on the free plan, or drop a signed PDF into the verify tool to see how independent verification works.

No credit card required · Free plan includes 5 documents to try · Cancel anytime

Page updated September 13, 2026