How to protect your work, code, design or idea without registering it: proof of priority
Equipo Proovik · Sep 7, 2026 · 9 min read
To protect a work, code, design or idea without registering it you need to fix two facts: that the creation already existed on a given date, and that it has not changed since. Copyright arises automatically on creation, with no formalities; what you are missing is proof of priority. You get it by computing the SHA-256 hash of the file and sealing it in a record nobody can rewrite, with a statement of authorship inside the file itself.
What the law already gives you without registration
In every country party to the Berne Convention, copyright does not depend on any register: the Convention states that the enjoyment and exercise of copyright shall not be subject to any formality, and national laws such as Spain's grant copyright to the author by the sole fact of creation, computer programs included. The law also adds a practical helper: whoever appears as the author on the work is presumed to be the author unless proven otherwise. That is why your name belongs inside the file, not only in the email you attach it to.
What no rule settles is the real dispute: two people show similar versions and each claims to have been first. The one who can prove the date of their version with evidence the other cannot dispute wins. That is proof of priority, and it has nothing to do with registration.
What protects each kind of creation, and what does not
- Works (text, music, photography, illustration, software): copyright from creation. Proof of priority establishes how long your version has existed.
- Designs: besides the registered design, EU law recognises the unregistered Community design, protected for three years from the date it was first made available to the public within the Union. Being able to prove the disclosure date decides whether the term is running.
- Inventions: that is patent territory. A timestamp grants no exclusive right and is no substitute for filing; worse, disclosing an invention before filing destroys its novelty.
- Ideas as such: copyright protects the concrete expression, not the idea. A business idea is protected, if at all, as a trade secret, and only if you take reasonable steps to keep it secret.
The poor man's copyright myth
For decades the folk advice was to put the work in an envelope, mail it to yourself by registered post and keep it sealed: the so-called poor man's copyright. It is weak evidence: an envelope can be steamed open and resealed, it can be posted empty and filled later, and the postmark proves the date of a mailing, not what was inside. A cryptographic timestamp solves exactly that problem: the file's fingerprint is written into a public record outside your control, and anyone can check that the file you present today is the same one that produced that fingerprint back then.
Five mechanisms compared
| Mechanism | What it proves | Cost | Time | Does the document leave your device? | Third-party verification |
|---|---|---|---|---|---|
| Intellectual Property Register | Registered entry with presumption of ownership unless proven otherwise | Fee | Weeks or months | Yes, it is deposited | Yes, public archive |
| Notary (deposit deed) | Public faith on the deposit date and the depositor's identity | Notary fees | Days, by appointment | Yes | As long as the notarial protocol is kept |
| Qualified electronic timestamp (eIDAS) | Date and time with presumption of accuracy (Article 41(2)) | Per stamp or subscription | Seconds | No, only the hash | By validating the signature against the EU trusted list |
| Blockchain timestamp (Proovik) | Existence, priority and integrity; admissible as evidence (Article 41(1)), no presumption | Low or free | Seconds | No, only the hash | Anyone with the proof file, without the issuer |
| Mailing it to yourself | The date of a postal mailing; nothing about the content | Postage | Days | Yes | Not reproducible |
The mechanisms combine: seal every version on the blockchain as you work and, if the matter turns into litigation, deposit the final version with a notary or the register. The five methods are compared in how to prove that a document existed on a date.
What to seal, and when
A seal fixes specific bytes: if you seal a file and then edit it, the proof holds for the sealed version, not for the new one. The practical rule is to seal at every milestone and keep the file and its certificate together.
Manuscripts, scripts and papers
Seal every version you share: novel-v3-2026-09-05.docx before sending it to a publisher, the screenplay before casting. Put your name and the date on the first page: that triggers the authorship presumption, and the seal proves how long that statement has existed.
Source code
A repository changes daily, so seal a single package at the milestones that matter: the first working version, each release, each delivery to a client. Two options that produce one file:
- A compressed archive of the working tree:
project-v1.4.0.zip. - A git bundle with the whole history:
git bundle create project-2026-09-05.bundle --all. Sealing that file fixes every earlier commit at once, because any change to the history changes the bundle's hash.
For the neighbouring problem of proving that a published binary has not been tampered with, there is a guide on verifiable software integrity.
Designs and illustrations
Seal the original working file (.fig, .ai, .psd, .svg), not just the PNG export: the original holds layers and history that a copy cannot reproduce. If the design is going to be disclosed, also seal the disclosure material (the catalogue, a capture of the web page) the same day: that is the date that starts the three-year term of the unregistered design.
Sketches and ideas
Photograph the notebook, or write a document describing the idea in detail and put your name inside. Seal it before pitching to investors or clients, together with the non-disclosure agreement they sign; there is more on those agreements in protecting your intellectual property without patents.
What the law says
On the value of a timestamp, Regulation (EU) No 910/2014 (eIDAS) distinguishes qualified from non-qualified electronic time stamps. Article 41(1) provides: "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." Article 41(2) reserves the presumption for qualified ones: "A qualified electronic time stamp shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound."
In summary, the rest of the applicable framework:
- Berne Convention: the enjoyment and exercise of copyright are not subject to any formality (Article 5(2)).
- Spanish Intellectual Property Act (TRLPI): copyright belongs to the author by the fact of creation (Article 1); whoever appears as author on the work is presumed to be the author (Article 6(1)); computer programs are protected works (Article 10(1)(i)); the register is voluntary and its entries are presumed accurate unless proven otherwise (Article 145).
- Regulation (EC) No 6/2002: an unregistered Community design is protected for three years from its first disclosure to the public in the Union (Article 11).
- Patent law (Spanish Law 24/2015): an invention must be new; anything disclosed before the filing date is part of the state of the art.
- Trade secrets (Directive (EU) 2016/943, Spanish Law 1/2019): information is protected as a trade secret if it has value because it is secret and its holder has taken reasonable steps to keep it so.
- Article 326 of the Spanish Civil Procedure Act (as amended by Law 6/2020): if the date or integrity of an electronic document backed by a non-qualified trust service is challenged, evidence is taken under the eIDAS Regulation (paragraph 3); if the service was qualified and on the trusted list, the document is presumed to have the disputed characteristic (paragraph 4).
This is general information, not legal advice.
How to do it with Proovik
Proovik issues a non-qualified electronic time stamp: it establishes that the file with that SHA-256 existed no later than the timestamp of the Kaspa block that includes it, and that it has not changed. It does not establish who created it or that its content is original, and it does not carry the presumption of Article 41(2), which belongs to qualified time stamps.
The process: open the certification page, drop the file (the ZIP, the bundle, the manuscript) and your browser computes its SHA-256. The file is not uploaded; only the 32-byte fingerprint travels, and it is written into a transaction on the Kaspa network. The seal is normally confirmed within seconds and you receive a PDF certificate with the PVK-PROOF/1 proof package. You can start without an account. Keep the PDF next to the original file: together they are the proof, and anyone can check it on the verification page without relying on Proovik. The differences from a qualified time stamp are explained in qualified versus non-qualified electronic time stamps.
Frequently asked questions
Does a timestamp protect my idea against someone else's patent?
No. Patents are granted on application and require novelty; a timestamp grants no exclusive right and does not stop someone else from patenting the same thing. It can provide evidence that you were using that solution earlier, which in some cases supports a right of prior use.
Can I use the seal to claim authorship?
Only indirectly. The seal proves that the file existed on a date and has not changed; it does not prove who wrote it. If the file carries your name, the law presumes you are the author unless proven otherwise, and the seal shows how long that statement has existed.
How often should I seal my code?
At the milestones you would want to be able to prove: the first working version, each release, each delivery to a client, and before showing it to third parties. A git bundle seals the whole history at once, so there is no need to seal commit by commit.
What if I change a comma after sealing?
The seal remains valid for the sealed version, not for the new one: a single different byte produces a completely different SHA-256. That is the desired behaviour: it prevents a retouched version from being passed off as the original.
Sources
- Berne Convention for the Protection of Literary and Artistic Works (WIPO)
- Royal Legislative Decree 1/1996, Spanish Intellectual Property Act (BOE)
- Council Regulation (EC) No 6/2002 on Community designs (EUR-Lex)
- Spanish Law 24/2015 on Patents (BOE)
- Directive (EU) 2016/943 on the protection of trade secrets (EUR-Lex)
- Spanish Law 1/2019 on Trade Secrets (BOE)
- Regulation (EU) No 910/2014 (eIDAS) (EUR-Lex)
- Spanish Law 6/2020 on electronic trust services (BOE)