All posts

8 min read

Creative Proofs for Artists

Hash your source files, drafts, prompts, exports, or whole project folders and publish a timestamped Label 309 proof that they existed by a given time — without making the work public.

Artists can prove that a specific creative file existed by a specific time.

With Label 309, you hash original files, drafts, project folders, prompts, AI outputs, stems, exports, or delivery packages, then publish a public timestamped commitment on the Cardano blockchain. The work itself never has to be public: you can publish the hash alone, and keep sensitive source material private or sealed in encrypted form.

A proof like this does not grant copyright, prove ownership, or stop anyone from copying your work. It creates something narrower and durable: evidence of timing and integrity that does not depend on a platform staying online.

What problem does this solve?

Creative work is easy to copy and hard to date.

A file gets reposted without credit. A client disputes what was delivered. An AI output turns up in someone else's campaign. A draft becomes evidence in a rights dispute. A project folder gets modified long after the original version was made.

In each case a creator is trying to answer one of a few timing questions:

  • did this file exist before it appeared somewhere else?
  • is this the same file I delivered?
  • did I have the source project before the public release?
  • was this prompt-and-output pair part of my workflow?
  • did this folder contain the stems, layers, or drafts I say it did?
  • was this concept created before the client meeting?

A Proof of Existence puts a public timestamp behind each of those answers, so the date does not rest on a file's own metadata, a platform's upload log, or your word against someone else's.

What can an artist timestamp?

Almost any digital artifact.

For example:

  • original images;
  • raw photos;
  • layered design files;
  • audio stems;
  • video project files;
  • scripts;
  • drafts;
  • sketches scanned to files;
  • prompts;
  • AI-generated outputs;
  • model settings;
  • style boards;
  • client delivery packages;
  • website exports;
  • NFT metadata;
  • final mastered files;
  • entire project folders.

What matters is the exact bytes. If the file changes by one byte, the hash changes — which is the whole point. A proof binds to one specific version, not to a title or a vague "the design."

How does the proof work?

The file becomes a hash.

CardanoWall — or any other Label 309 tool, including the open-source cardanowall CLI and SDKs — computes a cryptographic hash of the file or manifest. That hash is published in a Label 309 record on Cardano, carrying the block's timestamp. Later, you recompute the hash from the file and show that it matches the published record.

If the hashes match, the file you hold now is the same byte sequence that was committed at that time. Anyone can check this with the transaction reference and a public Cardano explorer — they do not have to trust CardanoWall, our servers, or our domain.

The chain never needs the artwork itself. It only needs the commitment.

Should source files be public?

Usually, no.

Source files often hold private layers, client material, unreleased concepts, contract details, prompt experiments, or commercial secrets. Publishing them in the open can weaken your position more than it helps.

The default is to publish only the hash. If you also want the original bytes recoverable later, use a sealed record: the source file is encrypted, the ciphertext is stored off-chain, and only the hash of the plaintext goes on the chain. The proof still commits to the real file, but the file stays encrypted for whoever holds the keys.

That way you keep both the proof and the original bytes, without handing the artwork to the public. Before you seal anything to someone else, though, verify their receive address — a sealed file is only as private as the key it was wrapped to.

What about whole project folders?

Use a manifest and a Merkle root.

Creative projects rarely live in one file. A design folder has images, fonts, drafts, exports, and notes. A music project has stems, MIDI files, mix versions, and masters. A video project has footage, timelines, graphics, proxies, and final renders.

For a folder, build a manifest that lists, per file:

  • file path;
  • file size;
  • content hash;
  • modified time, if useful;
  • project version;
  • a note about its source or role;
  • its leaf index in the tree.

Then publish a single Merkle root that commits to that whole list. One 32-byte root on the chain stands in for the entire folder. Later you can prove that one specific file was part of the project — with a small inclusion proof — without revealing every other file at once. The same trick scales from a folder to thousands or millions of files in one record.

How can AI artists use this?

Anchor the whole creative record, not only the final image.

AI work usually involves prompts, negative prompts, seeds, model names, reference images, control images, upscales, edits, and final exports. If you timestamp only the final image, most of the process that shows the work was yours is missing.

A stronger AI-art proof can cover:

  • the final output hash;
  • the prompt file hash;
  • the model or service reference;
  • the generation settings;
  • the reference image hashes;
  • an edit-history manifest;
  • the upscaled export hash;
  • the project-folder Merkle root;
  • a Content Credentials (C2PA) manifest hash, if you produce one.

This does not prove you hold every legal right to every input — a hash says nothing about licenses or consent. What it does prove is that these specific materials existed by a specific time, which is often the hard part to establish after the fact. A Proof of Existence and a provenance layer like Content Credentials answer different questions: one fixes the timing and integrity of exact bytes, the other carries signed claims about how the content was made.

How can this help with clients?

Proofs make deliveries cleaner.

A freelancer, studio, or agency can timestamp a delivery package before sending it. If a dispute comes up later, the proof can show what was delivered and that that exact package existed at that time.

This is useful for:

  • final artwork delivery;
  • brand asset packages;
  • ad creative variants;
  • audio masters;
  • video cuts;
  • website exports;
  • source-file handoff;
  • milestone approvals;
  • pre-release campaign assets.

For client work, an optional signature adds one more useful fact: it shows which identity key vouched for the delivery. Signatures in Label 309 are never required — a plain hash-only record is fully valid — but when you add one, the record carries a signature from your identity key, so the proof is not just "these bytes existed" but "this identity stood behind these bytes at this time."

Can this prove I own the work?

Not by itself.

A Proof of Existence can support an ownership or authorship story, but it does not replace contracts, copyright registration, employment agreements, license terms, model releases, consent records, or legal advice. Whether it helps in a given dispute depends on your jurisdiction and the surrounding evidence.

It proves a narrower thing: that specific bytes existed by a specific time and, if signed, that a specific identity key signed the record. It does not prove that the work is original, that you have the rights to it, or that no one created the same thing earlier and never published it.

That evidence can still be valuable. It is one solid piece of a rights story, not the whole system. For a careful walk through where the line sits, see What a Proof Does Not Prove.

What if someone copies my work later?

The proof gives you a timeline.

If someone posts a similar file after you, you may be able to show that your original existed earlier. If the copied file is byte-identical, the hash is a direct match. If it was modified, the proof still helps: it can establish that your source file, draft, or project folder existed before the other version appeared, which is often enough to shift a "your word against theirs" argument.

For a real dispute, keep more than the final proof. Preserve the source files, project history, contracts, messages, invoices, and delivery records. A proof is strongest when it sits inside a broader evidence trail, not on its own.

What should artists avoid?

Do not rely on one final export.

A few habits make the difference between a proof you can lean on and one you can't:

  • keep the source material, the manifests, and the transaction references — the proof is useless if you can no longer produce the bytes it commits to;
  • keep signed delivery records where they help;
  • never publish private client files in plaintext; seal them instead;
  • verify a recipient's receive address before sending a sealed record;
  • do not let confidential prompts, sources, or license terms leak into public metadata by accident.

Proof is a habit, not a panic button. The time to timestamp a file is when you make it, not the day after a dispute starts.

The short version

Creators need timestamped evidence that belongs to them, not only to a platform.

Label 309 lets you commit source files, final exports, AI outputs, prompts, and whole project folders to public time on Cardano. Hash-only records keep the files private. Sealed records preserve encrypted originals for the people who should hold them. Merkle roots cover large folders with one on-chain commitment.

It does not grant rights by magic. It gives your creative timeline something solid to stand on.

Further reading

  • Label 309 — the open, vendor-neutral standard behind these proofs, submitted to the Cardano CIP process and under review by the CIP editors.
  • CardanoWall open-source code — the cardanowall CLI and the TypeScript, Python, and Rust SDKs (Apache-2.0).

ai-provenancec2paproof-of-existence