Hash, Sign, Seal, Share: The Four Levels of a CardanoWall Proof

A CardanoWall proof has four practical levels, and you choose how far up the ladder you go:

Hash proves that exact bytes existed by a public time.
Sign adds a key-backed claim that a specific identity vouched for the record.
Seal encrypts the original file so it can be preserved privately alongside the proof.
Share wraps that sealed file for specific recipients, so they can later discover and decrypt it with their own keys.

Each level builds on the one below it, and the same standard underneath them all is Label 309. That is the simplest way to understand what CardanoWall is: not just a place to put hashes on a blockchain, but a layered way to make records durable, private, and verifiable — starting with a bare timestamp and adding only the protection a situation actually calls for.

Level 1: Hash — proving exact bytes existed by a time

The first level is the classic Proof of Existence.

You take a file, message, dataset, media asset, build artifact, report, or manifest. CardanoWall computes a cryptographic hash of the exact bytes and publishes that hash in a Label 309 record on Cardano.

Later, anyone with the same original bytes can compute the hash again. If it matches the hash in the record, the verifier knows those exact bytes existed no later than the transaction's block time. The check runs against the public Cardano chain — it needs no CardanoWall account and trusts no CardanoWall server.

The useful part: the file itself never has to be public. A private contract, a dataset snapshot, a software release manifest, or a legal evidence bundle can each carry a public proof. The record says these bytes existed. It does not have to show the bytes.

What are hash proofs good for?

Hash proofs are strong when the question is about timing and integrity. They answer things like:

Did this exact file exist before a deadline?
Is this the same PDF that was timestamped last month?
Was this release manifest already committed before the incident?
Did this dataset snapshot exist before the model was trained on it?
Did this media file exist before it was edited or disputed?

They are also efficient. A multi-gigabyte file collapses to one short digest, and a private file becomes a public commitment without disclosing its contents.

The limitation matters just as much: a hash does not prove who created the file, that the file is true, or that anyone owns it. It proves that the exact bytes existed by a public time — nothing more. That is enough for many workflows. For the rest, CardanoWall adds the next layers.

Level 2: Sign — attaching an identity key to the record

The second level adds a signature.

A signature lets a key vouch for the record. Instead of only proving that bytes existed, the record can also show that a specific identity key signed the proof. In Label 309 this is an optional, detached COSE_Sign1 signature over the record body, and authorship is never required — a record with no signature is still a complete, fully verifiable proof.

That option changes the practical meaning. For an individual creator, a signed record can connect a work product to the creator's CardanoWall identity. For a company, it can show that an approved key stood behind a report, release manifest, compliance snapshot, or dataset commitment. For an automated workflow, it distinguishes "someone timestamped this file" from "our system signed this record as part of the process."

The signature does not replace the hash; it sits on top of it.

The hash says: these exact bytes existed.
The signature says: this key signed the record that makes that claim.

What does a signature not prove?

Signatures are powerful, but they are not magic.

A signature proves control of a key at signing time. It does not, by itself, prove the real-world identity of the person or company behind that key. That identity comes from context: how the key was created, how it was published, how an organization manages it, and how others come to trust it.

A signature also does not prove that the signer paid the transaction fee or submitted the transaction to Cardano. In Label 309 the signature covers the record body, not the whole Cardano transaction. This is deliberate, and it is what keeps records portable: a gateway, an automation system, or any third party can publish a signed record without becoming the author of the content. A verified signature reads as "signed by this key" — never "this key submitted the transaction."

In plain terms: sign when you want the proof to say not only "this existed," but "this identity stood behind the proof."

Level 3: Seal — preserving an encrypted copy with the proof

The third level adds encrypted preservation.

A hash-only proof has one practical weakness: the verifier still needs the original bytes. Lose the file, or change it by even one byte, and you can no longer produce the content that matches the record.

Sealing solves this by encrypting the file and keeping the encrypted payload with the proof, at a content-addressed location such as Arweave or IPFS. The on-chain record still commits to the plaintext hash — never the ciphertext — so the timestamp claim is unchanged. The file is never published in the clear. Anyone holding the right key can later fetch the ciphertext, decrypt it, recompute the plaintext hash, and prove that this is the file behind the record.

That shifts the experience. With a hash-only proof, you keep the original file yourself. With a sealed proof, you can preserve an encrypted copy of the original as part of the proof workflow itself.

When is sealing worth it?

Sealing matters when the original file is important enough that losing it would weaken the proof. Think about:

legal evidence bundles and signed contracts;
compliance reports and sensitive incident logs;
original creative files and research data;
dataset manifests, AI prompts and outputs, and release artifacts.

In each case a hash is useful, but the original bytes are the thing you may later need to produce. Sealed Proof of Existence lets you keep those bytes encrypted while the timestamp stays public. The chain proves the timeline; the encryption protects the content.

The fourth level adds private recipient delivery.

Sometimes the proof is not only for you. You may need to send encrypted evidence to a lawyer, auditor, partner, journalist, customer, regulator, or internal team.

If you know the recipient's receive address, CardanoWall can create a sealed record that the recipient can later open with their own key. That record still has a public timestamp and still commits to the plaintext hash. It can still preserve an encrypted file. But now the encrypted payload can be opened by specific recipients, not only by the sender. This is where CardanoWall starts to feel less like a timestamping tool and more like a secure record-delivery system.

How does private delivery work without a public address book?

Recipient delivery needs no public address book on the chain, and no recipient's public key is ever written into the record as a readable field.

Here is the flow. A recipient has a receive address. The sender obtains it out of band — directly from the recipient, from a profile, a company page, or another trusted channel. When the sender builds a sealed record, the envelope carries per-recipient encrypted key slots that only the intended recipients can open.

On the receiving side, the recipient's software scans public sealed records and trial-decrypts — it locally tries each slot with its own keys. When a slot opens, the record appears in that recipient's inbox. The server never decrypts the message and does not need to know who the recipient is. (See how to receive sealed records for the recipient's side in detail.)

This is not a promise of perfect anonymity. Timing, payment flows, network metadata, browser behavior, and operational mistakes can still leak information, and a recipient can always share the plaintext once they have decrypted it. What the design does provide is narrower and real: the Label 309 record itself publishes neither the plaintext nor a human-readable recipient list — an observer sees only that a record is sealed and how many key slots it carries, never to whom.

Sealed records can live for a very long time. If encrypted content is stored permanently or semi-permanently, an attacker does not need to break it today: they can store the ciphertext now and try later, with better hardware and better cryptanalysis. This is the "harvest now, decrypt later" problem.

That is why Label 309 takes algorithm agility seriously. Receive addresses come in two forms — a classical X25519 address and an optional hybrid post-quantum address that combines X25519 with ML-KEM-768 (an X-Wing-style construction). The hybrid keeps classical X25519 security as a floor while adding resistance to a future quantum attacker, so it is the better default for content meant to outlast today's cryptographic assumptions. The point is not to claim permanent security — nothing honest can — but to avoid designing a proof system that assumes today's cryptographic comfort will hold forever.

The user-facing version stays simple: protect your Identity Seed, prefer the hybrid post-quantum receive address when your recipient publishes one, and let the software handle the cryptography.

How do the four levels work together?

The levels are not separate products. They are layers on one standard:

Publish a plain hash proof when you only need a timestamp.
Add a signature when you want an identity key to vouch for the record.
Seal the file when preserving the exact original bytes matters.
Share the sealed file when specific recipients need private access.

Because the same underlying standard supports every choice, you can start simple and reach for stronger layers only when the situation calls for them.

Which level should you use?

Hash when the original file is easy to keep and the only question is whether those bytes existed by a certain time.
Sign when you want a key-backed identity to stand behind the proof.
Seal when the original bytes are sensitive or important enough to preserve an encrypted copy with the proof.
Share when someone else needs to receive the encrypted content and verify it later.

There is also a fifth tool that cuts across all four: Merkle batching, for when you have too many hashes for one-by-one publishing — CI/CD artifacts, daily logs, dataset snapshots, generated media, or any workflow where thousands of items should be committed under a single record and root.

What do these proofs still not prove?

Even with all four levels, Proof of Existence stays precise about its claims.

It can prove exact bytes existed, that a key signed the record, that encrypted content was preserved, that the content was delivered to specific keys, and — with a Merkle root — that an item belonged to a committed batch.

It does not, on its own, prove that the content is true, that anyone holds legal ownership, that a dataset was lawfully collected, or that a weak process is sound. For more on those boundaries, see what a proof does not prove. CardanoWall gives you a durable proof layer; the business process around that proof still matters.

The short version

Hash is the timestamp.
Sign is the identity claim.
Seal is encrypted preservation.
Share is private delivery.

Together they turn Proof of Existence from a bare hash on a chain into a usable workflow for files, datasets, evidence, software releases, AI outputs, and confidential records — and because Label 309 is an open standard with open-source tooling, the same four levels work through the website, the CLI, or anyone else's implementation.