E-signatures · Glossary
What is a hash chain?
A hash chain is a sequence of records where each entry's fingerprint is computed over its own contents plus the fingerprint of the entry before it. Change any earlier record and every later fingerprint stops matching, so quiet edits become visible without anyone needing a separate copy of the log.
It is the cheapest way to make a log defend itself. The idea predates every blockchain marketing page by decades, and it is the part that actually does the work.
Indunil Asanka · Co-founder
5 min read · Published
| Plain log | Hash chain | Public blockchain | |
|---|---|---|---|
| Detects a changed entry | Only if a copy exists elsewhere | Yes, every later entry stops matching | Yes |
| Detects a deleted entry | No | Yes, the sequence breaks | Yes |
| Needs another party | No | No | Yes, a network of them |
| Cost to run | None | One hash per event | Fees and latency per write |
| Answers who wrote it | No | No, unless entries are signed | Only as far as the key is known |
How the links are made
Each entry carries the fingerprint of the previous one as one of its own inputs. The first entry has nothing before it, so it starts from an empty value, and every subsequent entry folds the whole history into a single string. Verification walks the sequence from the start, recomputing each fingerprint from the stored fields and checking it matches what was recorded. Where the chain is intact the check succeeds; where it is not, the walk stops and reports the position of the first entry that fails, which is a useful diagnostic rather than a bare pass or fail.
Why field order matters
A fingerprint is computed over a serialised version of the entry, so two systems that serialise the same data differently will produce different values. Databases that store structured data are free to reorder keys internally, which would silently break a naive implementation. The fix is to sort the keys before hashing, so the same facts always produce the same string regardless of how storage happened to arrange them. It is a small detail that separates a chain that verifies years later from one that fails for reasons nobody can explain.
What it proves, and what it does not
It proves internal consistency: the entries you are looking at have not been altered or removed since they were written, unless somebody recomputed the entire chain from the point of the change. It does not prove the entries were true when written, it does not identify who wrote them, and it does not stop an operator with full access from rebuilding the whole sequence. Those limits are why a chain is usually paired with something else, such as signing the head of the chain or publishing it somewhere the operator does not control.
The append only problem
A chain only helps if entries cannot be quietly replaced. That is usually enforced at the storage layer with a uniqueness constraint on the sequence number and a rule that rejects updates outright. Deletion is the harder case, because there are legitimate reasons to remove a whole record, such as discarding a draft that was never sent, and a blanket ban makes that impossible. The honest description is that updates are refused and deletions are constrained by what the surrounding application allows, rather than that the log is immutable in an absolute sense.
Reading the result as a non technical user
The verification outcome is usually surfaced as a single line: either the chain verified, or it broke at a particular position. Both are useful in a dispute. A verified chain lets the party relying on it say the record has not been edited since the events happened. A broken chain does not automatically mean fraud, since a botched migration can do it, but it does mean the log can no longer be offered as unaltered, and the party relying on it has some explaining to do. The right response to a break is investigation rather than silence: export the entries, identify the position reported, and check what happened to the system around that time, since migrations and restores are the usual culprits. Recording that investigation is itself worth doing, because a documented explanation of a break is far better received than a log that quietly stops being mentioned. Silence about a break turns a technical fault into a credibility problem.
How the signing trail applies it here
Every envelope event is written with a sequence number and a fingerprint computed over the envelope identifier, that sequence number, the event type, the time, the recipient, the address, the user agent, the metadata and the previous fingerprint, with keys sorted so storage cannot change the result. The verifier walks the rows and reports either that the chain is verified or the sequence number where it broke, and that line appears on the envelope status page. The events themselves, and what each one records, are covered on the audit trail page rather than here.
Questions people ask
Is this the same as blockchain?
A blockchain is a hash chain plus a way for many parties who do not trust each other to agree on what the next entry is. If one organisation keeps the log, the agreement machinery adds cost without adding anything you need. The chaining is the part that detects tampering, and that part is free.
Can somebody rebuild the chain after editing an entry?
Anyone with write access to every row and the ability to recompute fingerprints could produce a consistent but false history. That is why storage rules refuse updates, and why the chain is one part of the evidence rather than the whole of it. External anchoring, such as a timestamp from a third party, closes the gap further.
What breaks a chain accidentally?
Data migrations that rewrite rows, serialisation changes, clock or encoding differences, and any change to which fields are included in the fingerprint. Each of those produces a break with no bad intent behind it, which is why a break should prompt investigation rather than an accusation.
Does the chain include the document?
Not the file itself, but events can carry a hash of the document at a given moment, which ties the log to a specific version. That combination is what lets a record say that this person, at this time, signed this exact file, without storing the file inside the log.
How long should the log be kept?
For as long as the document it describes could matter, which usually means the same retention period as the contract. A signed agreement kept for seven years with its event history discarded after one is a common and self defeating arrangement, since the evidence disappears while the obligation remains.
Can I verify the chain myself?
Verification here runs inside the product and the result is shown on the envelope page. A determined reader with an export of the entries and the field list could recompute it, since the algorithm is standard. In practice the certificate of completion and the signed PDF are the artefacts you would put in front of somebody else.
Make one with e-signatures
The button opens the generator with this use case already described. Change the wording to match your own.
Send a document for signingRelated questions
- What does tamper evident mean?Tamper evident means a change can be detected, not prevented. What certification and hashing actually stop, and why tamper proof is the wrong word.
- What is a document hash?A document hash is a fixed string computed from a file's bytes. Why a signing certificate prints two of them, and what each one actually covers.
- What is an audit trail?An audit trail is the ordered, tamper evident record of everything that happened to a document: who opened it, who was challenged, who signed and when.
Written and checked by the OneCraft team. Last checked .