CardanoWall Returns, Built on Label 309

CardanoWall is returning, and this time the product is the smaller part of the story. The durable part is Label 309: an open, vendor-neutral record format for anchoring Proof of Existence in Cardano transaction metadata. You hash content, optionally sign it, optionally seal it for specific people, and publish the result on Cardano. Anyone with the transaction reference can then verify it from the public chain alone, without trusting CardanoWall as a permanent vendor.

The original 2021 idea worked because Cardano metadata can carry durable public commitments. The relaunch turns that idea into something precise: a specified record format, an open gateway path, SDKs, a command-line tool, and user-facing software that people who are not cryptographers can actually use.

From a 2021 experiment to a specified format

CardanoWall started in 2021 with a simple bet: use Cardano transaction metadata as a public place to anchor proof.

Back then the proof was mostly hashes, text, and ad-hoc metadata. You could hash a file, write the hash on chain, and later — if you still had the original file — hash it again and compare it against the on-chain record.

That is the core Proof of Existence pattern, and it is worth stating plainly because everything else builds on it. You never publish the private file. You publish a cryptographic fingerprint of the exact bytes, and the blockchain supplies the public time witness. If the bytes match the recorded hash, they existed no later than the block's time.

People experimented with it, putting all sorts of messages and metadata into records. That was useful, but it exposed the limit of a loose experiment. To become infrastructure, the idea needed a precise format, strict verification rules, and tooling that works across different apps and different vendors. A proof is only as good as the second party's ability to check it without phoning the first party.

That is what Label 309 is for. It is built around Cardano metadata label 309, which the format reserves for Proof of Existence records, and the specification has been submitted to the Cardano CIP process. It is currently under review by the CIP editors as a Metadata-category proposal.

The wording there is deliberate. Label 309 is a proposal under review, not yet an accepted Cardano standard, and we describe it that way until the CIP process says otherwise. But the direction is settled: the original CardanoWall idea has grown into a carefully specified, vendor-neutral record format. If you want the full picture of the wire format, how Label 309 works is the place to start.

What actually changed in the relaunch?

The new CardanoWall is not a nicer interface over the old concept. It is a complete implementation path for an open standard:

a web app, for people who want a simple interface;
a gateway that quotes, uploads, publishes, confirms, and indexes records;
SDKs and a command-line tool, for developers and automation;
verification paths that do not depend on the CardanoWall website staying online;
and an open-source desktop app that syncs the public record set for local, offline use.

The architectural point underneath all of it: CardanoWall is a product, but the proofs are not trapped inside the product. A Label 309 record can be checked from the public Cardano chain, the record bytes, and — when needed — the original content or encrypted payload. The website can make that pleasant. It is never the root of trust. The chain is.

The clearest way to understand the relaunched product is as four layers, each a strict superset of the one before it. The same shape shows up in the standard's conformance profiles, and we walk through it in detail in hash, sign, seal, share.

Hash: prove exact bytes existed by a public time

The first level is the classic proof. CardanoWall hashes a file, message, dataset, or manifest and anchors that hash in a Cardano transaction under label 309. Later, anyone with the same original bytes can recompute the hash and confirm it matches the on-chain record.

This proves one narrow thing: the exact bytes existed no later than the block time of the transaction. It does not prove who created the file, that the file's contents are true, or that anyone owns it. That narrowness is exactly what makes it trustworthy — and worth understanding precisely, which is why what a proof does not prove is one of the first articles on this blog.

Sign: show that a specific key vouched for the record

The second level adds authorship. A hash shows that content existed; a signature shows that a particular key stood behind the record. Label 309 lets a record carry one or more signatures, so the claim grows from "these bytes existed" to "and this key vouched for them."

That distinction matters for a person or a company. A public timestamp is useful on its own. A public timestamp tied to a stable identity key is stronger when you need to show that you created, approved, or submitted the record yourself. Signatures are always optional, though — the format never requires you to reveal an identity to publish.

Seal: keep the file private while still timestamping it

The third level adds encrypted preservation. A bare hash is enough until the original file is lost or changes by a single byte; after that, the hash no longer matches. Good for integrity, painful if you no longer hold the exact bytes.

A sealed proof solves this by encrypting the file and referencing the ciphertext through content-addressed storage such as Arweave. The public record still commits to the exact plaintext hash, but the plaintext never has to become public, and the encrypted file can be preserved alongside the proof. The claim shifts from "I can prove this hash existed, if I still have the file" to "I can keep the original file in encrypted form and later prove it is the file behind the hash."

The fourth level adds recipients. A sealed file can be encrypted for yourself, or for other specific people. If you know a recipient's receive address, you can publish a record that they can later discover and decrypt with their own key.

This is what makes Label 309 more than personal timestamping. It can support confidential evidence delivery, private business records, dataset commitments, and any workflow where the public chain should prove a record exists while the contents stay private. The recipient model is built to be privacy-conscious: the record carries no public "recipient" field announcing who the message is for. Instead, a client scans the public record feed and tries, locally, to decrypt the ones that might be addressed to its keys.

Why is post-quantum encryption part of the design?

Permanent storage changes the security conversation. Once encrypted data may sit on long-lived public storage, the question is no longer only "can anyone decrypt this today?" It is also "what if someone stores the ciphertext now and attacks it years from now?"

That is why Label 309 treats algorithm agility — and hybrid post-quantum encryption for sealed payloads — as first-class design goals rather than afterthoughts. The format is not pinned to a single primitive. It references named algorithm identifiers from extensible registries, so future implementations can add stronger algorithms without breaking the basic record model. Migrating to post-quantum algorithms is additive.

For sealed records, CardanoWall is designed to support both a classical receive address and an optional hybrid post-quantum one. In the current version, that post-quantum story is specifically about encryption for sealed payloads; record signatures remain Ed25519. You should not have to understand any of this to benefit from the safer default. You only need to protect your Identity Seed — the single 32-byte secret your whole identity derives from, and the real backup behind it — and use software that follows the standard. Your identity is a seed explains why that one value matters so much.

Why is the gateway open?

Publishing a proof is more than a button. Something has to prepare the record, upload ciphertext when files are involved, quote the cost, submit the Cardano transaction, pay the real network and storage fees, wait for confirmation, index the result, and expose it for verification. That component is the gateway.

CardanoWall is designed around a gateway model that any developer or company can use. There is no special private publishing path reserved for the official product — the web app reaches the gateway through the same public interfaces a third party would. A developer can build a different app on those same surfaces. A company can run its own gateway, fund its own Cardano and storage wallets, and publish Label 309 records without depending on CardanoWall as a hosted operator.

That openness is the point, not a footnote. If the standard is open but the only practical tool is a closed service, the system still has a weak center. CardanoWall is meant to be a good product and a reference path others can inspect, run, modify, and replace. The gateway core, the SDKs, and the command-line tool are open source.

What this does not claim

Proof of Existence is powerful precisely because it is narrow. It proves that exact data existed by a public time. With signatures, it can show that a key vouched for a record. With sealed payloads, it can preserve encrypted files and later prove the decrypted bytes match the committed hash. With recipient encryption, it can deliver confidential data to specific keys.

It does not prove that a file's contents are true. It does not prove that the publisher owned the content. It does not replace legal advice, a regulated timestamp where one is required, or a full compliance system. And while sealed records keep plaintext and recipient identities off chain, confidentiality is not the same as anonymity: network behavior, payment trails, browser fingerprints, and ordinary operational mistakes outside the Label 309 record can still leak who is doing what. A recipient who decrypts a sealed file can also choose to share the plaintext.

Those limits are not a weakness. They are the line between a serious proof system and marketing fog.

What comes next on this blog

This blog will explain the system one focused question at a time.

First, the basics: what Proof of Existence is, how Label 309 works, what goes on the chain, and what stays private.

Then the user model: the Identity Seed, receive addresses, sealed records, and the desktop client.

Then the operator layer: how the gateway works, why publishing has a price, how API access fits in, and when a company should run its own gateway.

And then the use cases that make the standard worth building: CI/CD proofs, AI-generated content provenance, private dataset commitments, compliance logs, legal evidence bundles, confidential disclosures, and Merkle batching for proofs at scale.

CardanoWall began as a way to write proof into Cardano metadata. The relaunched version is about making that proof durable, private when it needs to be, verifiable without vendor trust, and practical enough to use without becoming a protocol engineer first.

That is the relaunch.