What an eSignature blockchain record proves, and what it doesn't

An eSignature blockchain record is a short entry on a public ledger that lets anyone check, years later, that a signed file hasn't changed since it was recorded. It doesn't hold the contract. It holds a fingerprint of the file, called a hash, and in Chaindoc's case the signers' cryptographic signatures, written once when the document is published and again when the last person signs.

That's useful, and narrower than most vendor pages suggest. The blockchain doesn't make your signature legal: e-signature law does that, and the signing itself happens in an ordinary e-signature workflow. It doesn't encrypt anything. It doesn't know who your signers are, either. What it adds is a record that neither you, the other party nor the vendor can quietly rewrite.

Four things are worth knowing before you pay for one: what a hash is, why it isn't encryption, how a chain-anchored record compares with a normal audit trail, and what US and EU law make of the whole thing.

Vendor pages use four words as if they meant the same thing. They don't, and the difference decides what you can prove later.

• A signature is the act of agreeing to a document, captured by the e-signature tool.
• A hash is a fixed-length fingerprint computed from the file's bytes.
• A timestamp says when something was recorded, and nothing more.
• Encryption scrambles content so that only someone holding a key can read it.

An eSignature blockchain involves the first three. It doesn't involve the fourth at all.

One more trap. The word "signature" means two things here. Every blockchain uses digital signatures internally, because each transaction is signed with a private key: that's a blockchain digital signature in the cryptographic sense, and it says nothing about your contract. Your contract signature is a legal act. The chain's signatures only authorise ledger entries. If the vocabulary still blurs, our explainer on how digital and electronic signatures differ untangles it.

Here's what each blockchain signature claim you'll meet actually means, and what Chaindoc records for it.

You may have noticed the word "encryption" in this page's address. It shouldn't be there. Blockchain encryption is the most common mix-up in this whole field, so here's the plain version.

Encryption is reversible by design. You scramble a document with a key, and anyone holding the right key turns it back into the document. Its whole purpose is to keep content away from people who shouldn't read it.

A hash is one-way. NIST's Secure Hash Standard describes hash digests as a way to detect whether a message has changed since the digest was generated. That's the job: spotting change. You can't turn a SHA-256 hash back into the contract, and nobody needs a key to compute one. Hand the same file to two people and they'll get the same 64 characters.

The chain itself is public, too. NIST's blockchain technology overview says information on a blockchain network is generally publicly viewable, and that in a permissionless network anyone can read it. Great for proof. The opposite of confidentiality.

So what keeps a contract private in an eSignature blockchain set-up? The ordinary things. The file stays off chain, access is limited to your account and the people on the request, and the file travels over HTTPS. Chaindoc doesn't claim end-to-end encryption, and we'd be wary of any vendor that says a ledger encrypts your document. When someone asks about blockchain document security, the honest answer splits in two: the chain covers integrity, while storage and access cover confidentiality.

Every serious e-signature tool keeps an audit trail: who was invited, who opened the document, when each person signed, from which IP address, whether an identity check passed. It's rich evidence, and it's where most disputes actually get settled. Our guide to what an e-signature audit trail records covers it field by field.

Its weakness is custody. The audit trail sits in the vendor's database, and the vendor can correct it, export it, migrate it and, if the company folds, lose it. Courts usually accept it anyway, because records kept in the regular course of business are routine evidence. It just isn't independent of the vendor.

An eSignature blockchain record is the reverse. It holds far less, only hashes and signature proofs, but nobody controls it after the fact. Honestly, you want both, and the table shows why.

Picture the usual fight. Your client says the PDF you're holding isn't the version they signed: the payment term was 30 days, not 15. Here's how the eSignature blockchain record helps, and where it runs out.

What an eSignature blockchain record can prove

• Your file is the one that was published and signed. Hash your copy with SHA-256 and compare the result with the hash on chain; a match means it's the same file, byte for byte.
• When the file existed. The block time says the record was there no later than that moment.
• Signer proofs were recorded at completion, and nobody edited them afterwards, Chaindoc included.
• The check doesn't depend on trusting a vendor's database. Anyone with the file and the transaction link can run it.

That's blockchain document verification in the narrow sense, and it's a strong one. If you'd rather not open a terminal, Chaindoc's PDF verification service checks a signed PDF's signatures and integrity once you confirm your email with a one-time code.

What it can't prove

• Who was at the keyboard. An email address isn't a person; the audit trail and any identity check carry that.
• Whether the signer read the terms, understood them or was pressured.
• Whether the content is true or the deal is lawful. A hash of a bad contract is a perfectly good hash.
• When the document was first written. The record says "no later than", never "created on".
• Anything about a copy you've re-saved, printed to PDF or compressed. Different bytes, different hash.

So in the 30-versus-15 dispute, the chain settles which file was signed. Whether your client's colleague had authority to sign it is a question for the audit trail, the contract and, eventually, a judge.

Short answer: the signature can be, and the eSignature blockchain record is evidence. The main e-signature laws don't mention blockchains at all, and that's deliberate. They're technology-neutral.

United States

The ESIGN Act (15 U.S.C. § 7001) says a signature or record can't be denied legal effect solely because it's electronic, and section 7 of the Uniform Electronic Transactions Act says the same at state level. Neither cares how the signature was captured, so an eSignature blockchain record next to it doesn't add validity and doesn't take it away.

Some states went further. Arizona's HB 2417 of 2017, now A.R.S. § 44-7061, says a signature secured through blockchain technology is an electronic signature, and a record secured that way is an electronic record. Read the limit carefully. That puts blockchain signatures inside the existing rules; it doesn't make them valid for documents the law reserves for paper or a notary, and it doesn't prove who signed.

Vermont took the evidence route. 12 V.S.A. § 1913 lets a record registered in a blockchain authenticate itself in court, provided a qualified person swears a declaration about when it entered the chain and how it was kept. The record is then presumed authentic, with an accurate recorded date and time. The same section says the presumption doesn't reach the truthfulness, validity or legal status of the record's contents, and that nobody is obliged to adopt blockchain at all.

European Union

Article 25(1) of the eIDAS Regulation stops a court from refusing an electronic signature as evidence just because it's electronic or not qualified. Article 26 lists what makes a signature advanced: uniquely linked to the signer, capable of identifying them, created with data under their sole control, and linked to the signed data so that any later change is detectable. That last test is about the signature, not the ledger. Chaindoc's signatures are advanced electronic signatures (AES, as PAdES-BES), and the eSignature blockchain record sits next to them as evidence.

The word "blockchain" doesn't appear in eIDAS. Its 2024 amendment, Regulation 2024/1183, speaks of electronic ledgers instead, and it keeps the presumption of integrity and correct ordering for qualified ledgers run by a qualified trust service provider (QTSP). SKALE isn't one of those, and Chaindoc doesn't sell it as one.

Italy, the one EU statute that defines it

Italy is the exception worth knowing. Article 8-ter of decree-law 135/2018, converted by law 12/2019, says that storing a document with distributed-ledger technology produces the legal effects of an electronic time stamp under article 41 of eIDAS. Two limits come with it. The effect is that of an ordinary electronic time stamp, not a qualified one, and the article left the technical standards to AgID, Italy's digital agency. Outside Italy it's a precedent, not a rule.

"Blockchain" on a feature list tells you almost nothing. These questions sort the useful implementations from the decorative ones, and any vendor, Chaindoc included, should answer them in writing.

1. 1.
   What exactly goes on chain? A hash and signature proofs are fine. Names, emails or the document itself are a red flag.
2. 2.
   When is it written: on upload, on publish, on completion, or in a nightly batch?
3. 3.
   Which chain, and who pays for each transaction? A per-document fee that moves with crypto prices becomes somebody's problem.
4. 4.
   Can a person without an account check the record? Ask for the hash algorithm and what the transaction link looks like.
5. 5.
   What happens to the record, and to your files, if the vendor shuts down?
6. 6.
   Is the signature itself advanced or qualified under eIDAS, and who's the trust service provider if it's qualified?
7. 7.
   Is the chain record on by default, or an add-on someone has to remember to switch on?

That last question has history behind it. In its Fall '18 release, DocuSign announced an opt-in Ethereum integration: for customers who switched it on, DocuSign computed a one-way hash of each completed transaction and wrote it to the Ethereum blockchain. Same idea as an eSignature blockchain record, sold as an option. If a "docusign blockchain" search brought you here, the 2018 announcement is the record we cite; for today's status on your plan, ask DocuSign.

Plenty of pages promise tamper-proof documents. No technology delivers that. Anyone with a copy of a PDF can edit it, and the bytes don't resist. What an eSignature blockchain gives you is a tamper-evident record: an edit can't hide, because the altered file no longer matches the fingerprint written on publish or completion. It sounds pedantic until the other side's expert asks which of the two you meant. Write "tamper-evident" in your own policies and contracts. That's the claim you can defend.

Most signed contracts are never questioned, and for those the chain record just sits there, costing nobody anything. It earns its place in a narrower set of cases. A counterparty might dispute which version they signed. An agreement might outlive the tools that produced it, so whoever checks it in ten years has never heard of your vendor. Two parties in different countries might share no system and no reason to trust each other's. The useful property is the same every time: the proof is public, and it doesn't depend on any one company staying in business.

It won't rescue a deal the law reserves for a qualified signature or a notary, or a signer who was misled. And it doesn't replace the audit trail, which still carries the who and the how.

If that trade-off suits you, an eSignature blockchain record is something to expect as standard, not to pay extra for. In Chaindoc it's part of the normal signing flow rather than a switch you have to find. Compare the plans and send your next contract through it.