NDAs, contracts and deliverables with suppliers and freelancers: how to keep a provable record of date and version
Equipo Proovik · Sep 15, 2026 · 8 min read
To keep a provable record of the date and version of an NDA, a contract or a deliverable, compute the SHA-256 hash of the final file and seal it with an electronic time stamp: the seal shows that this exact file existed at that moment and has not changed. Do it before sharing confidential information, with every delivered version and with the final acceptance. The seal does not prove who wrote the file or that the other party received it.
This article is part of Proovik's proof-of-existence cluster. For the foundations (what a time stamp is, what it is worth and what it is not), read How to prove that a document existed on a date first. Here we go down to the concrete case of working with suppliers and freelancers, where most "that was not the agreed version" disputes arise.
The three moments where the evidence gets lost
In a relationship with a supplier or a freelancer there are three moments when, if you keep no record, it will later be your word against theirs.
- Before sharing. You send a brief, a dataset, a prototype or a customer list under NDA. If the supplier reuses that information, you will have to show what you handed over and when, and that the NDA was already signed.
- During the work. Deliverables change version: v1, v2 "final", v2 "final final". If there is a claim for defects or delays, you need to know which version existed on which date.
- At closing. Acceptance of the deliverable, the invoice and the assignment of rights must refer to an identifiable file, not to "the design you sent by email".
The usual approach is to rely on email. Email proves little: either party's server can edit or delete messages, attachments get replaced and mail client dates can be manipulated. A hash sealed on a public network depends on neither party.
What a sealed hash proves and what it does not
| Question in a dispute | Does the time stamp prove it? | What else is needed |
|---|---|---|
| Did this file exist on day X? | Yes, through the block timestamp | Keeping the original file |
| Is it exactly this version, unchanged? | Yes, the hash changes with a single bit | Nothing |
| Who drafted or created it? | No | Electronic signature, metadata, witnesses |
| Did the other party receive it? | No | Evidenced delivery, acknowledgement, recipient's signature |
| Is what the document says true? | No | Evidence on the merits |
| Did it exist before the other party's document? | Yes, by comparing the timestamps of both seals | The other party must also have a proven date |
A seal over the signed NDA proves that the signed version existed on that date; a seal over the package of information handed over proves what was handed over. Together they reconstruct the fact a judge needs: what information was protected when it was shared.
A procedure that fits in an afternoon
- Freeze the NDA. Once both parties have signed (electronically or on scanned paper), compute the hash of the final PDF and seal it. Note the transaction identifier in the supplier's file.
- Package what you share. Before sending confidential information, put the files in an archive, seal it and keep it unopened. The archive hash identifies the whole set.
- Seal every delivered version. Ask the freelancer to seal the deliverable before sending it, or seal it yourself on receipt. The certificate with the hash goes into the project email thread.
- Seal the acceptance. The acceptance email or record must quote the hash of the accepted version. "The final version" stops being ambiguous.
- Keep files and certificates together. The seal is only useful if you keep the file it corresponds to. One folder per supplier, with file, certificate and hash, is enough.
An example. A studio commissions a freelance designer to create the visual identity of a product. The studio seals the brief and the NDA on 3 February; the designer seals her proposals on 20 February and 4 March; the studio seals the acceptance record quoting the hash of the 4 March proposal. Six months later an almost identical logo appears under another brand. The studio can show which design existed on 4 March, and the designer can show that hers predates what the other brand published, if that brand has no proven date of its own. Neither of them depends on the other keeping their emails.
What the law says
Regulation (EU) 910/2014 (eIDAS), Article 41: paragraph 1: "An electronic time stamp shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic time stamp". Paragraph 2: a qualified electronic time stamp enjoys a presumption of the accuracy of the date and time it indicates and of the integrity of the data to which they are bound. Proovik's stamp is non-qualified: admissible, without that presumption.
Directive (EU) 2016/943 on trade secrets, Article 2(1): information is a trade secret only if it is secret, has commercial value because it is secret, and "has been subject to reasonable steps under the circumstances, by the person lawfully in control of the information, to keep it secret". A signed NDA with a proven date, plus a record of what was shared and when, is part of those reasonable steps. In Spain the directive is transposed by Law 1/2019 on Trade Secrets, with the same three conditions.
Spanish Civil Procedure Act (LEC), Article 326, as amended by Law 6/2020: private documents carry the same probative force as public ones unless their authenticity is challenged; where an electronic document that relies on a non-qualified trust service is challenged, the burden of carrying out the verification lies with the party who produced it. In other words, whoever relies on a non-qualified stamp must be able to show it is correct. With a publicly verifiable seal, that showing is an arithmetic check anyone can repeat. Other jurisdictions apply their own rules of evidence; the eIDAS admissibility rule applies throughout the EU.
How to do it with Proovik
On the certify page you pick the file; the SHA-256 hash is computed in your browser and only that 32-byte fingerprint is written in a transaction on the Kaspa network, which produces about ten blocks per second, so the seal is normally confirmed within seconds. You receive a PDF certificate with the PVK-PROOF/1 proof package embedded; anyone can verify it without Proovik, on the verify page or with the public specification. To seal deliverables systematically from a project management tool, use the API. If your case is protecting your own work or idea before showing it, see also how to protect your intellectual property without patents.
What it proves: that the file existed no later than the block timestamp and has not changed. What it does not prove: authorship, receipt by the other party or the truth of the content. Sealing an NDA does not make it more valid; it makes it easier to prove.
Frequently asked questions
Does sealing a contract replace signing it?
No. The signature binds people to the content; the seal binds the content to a date. The right order is to sign and then seal the signed version, so you can show that the signature already existed on that date.
What if the freelancer refuses to seal their deliverables?
You can seal what you receive at the moment you receive it. The seal proves that this version was in your hands on that date, which is what you need against a later claim. If the supplier also seals on sending, both parties hold their own evidence.
Does the seal reveal the content of the NDA or the deliverable?
No. Only the hash is written on chain. The document cannot be reconstructed from the hash, and Proovik never receives the file. To prove something you will have to show the file, but only to whom you choose and when you choose.
How long does the proof remain verifiable?
As long as the Kaspa network exists and you keep the file and the certificate. The certificate contains the transaction, the Merkle path and the block header: it does not depend on Proovik staying in business.
Sources
- Regulation (EU) 910/2014 (eIDAS): eur-lex.europa.eu/eli/reg/2014/910/oj
- Directive (EU) 2016/943 on trade secrets: eur-lex.europa.eu/eli/dir/2016/943/oj
- Spanish Law 1/2019 on Trade Secrets (BOE): boe.es/eli/es/l/2019/02/20/1
- Spanish Civil Procedure Act, consolidated text (Article 326): boe.es/eli/es/l/2000/01/07/1/con
- Spanish Law 6/2020 on electronic trust services: boe.es/eli/es/l/2020/11/11/6
Proovik team. Published 17 September 2026; last reviewed 6 September 2026. This article is general information, not legal advice.