Introduction
What Label 309 is, the principles it guarantees, and how anyone can verify a record without trusting a server.
Label 309 is an open standard for Proof of Existence (PoE) on the Cardano blockchain. A publisher computes a cryptographic hash of some content and anchors it in a Cardano transaction under metadata label 309. From that moment, anyone holding the transaction reference can prove the content existed on or before the block's time — using only the public blockchain, with no need to trust the publisher, a domain, or any server.
The standard is deliberately small at its core: the content hash is the claim, and everything else is optional metadata about it. On top of that core it defines optional authorship signatures and an optional encrypted ("sealed") payload addressed to specific recipients — none of which ever requires a trusted intermediary.
The five invariants
Everything in Label 309 follows from five non-negotiable principles:
- Content-first. The content hash is the primary claim; every other field is metadata about it.
- Issuer-agnostic. Any wallet can publish a record. Verifiers never trust the publisher.
- Storage-agnostic. Storage URIs are an optional, plural list (
ar://,ipfs://); a hash-only record is fully valid. - Standalone-verifiable. A verifier needs only the transaction metadata, optionally the content bytes, and a public blockchain explorer. No issuer server is ever required.
- Algorithm-agile. Hashes, AEADs, KEMs, KDFs, and signatures all reference named identifiers from extensible registries. Migrating to post-quantum algorithms is additive, not a breaking change.
Conformance profiles
A record participates at one of four layered profiles, from a bare timestamp to an encrypted, recipient-addressed payload. Each profile is a strict superset of the one above it.
| Profile | Adds | Answers |
|---|---|---|
| core | a content hash under label 309 | "this content existed by time T" |
| signed | one or more COSE_Sign1 record signatures | "...and this key vouches for it" |
| sealed | an encrypted payload (passphrase or recipients) | "...kept confidential, but timestamped" |
| recipient-sealed | per-recipient key slots (X25519 or X-Wing) | "...delivered to specific keys, held privately" |
Authorship and encryption are always optional. A verifier that only understands
core can still validate the timestamp claim of any record.
Verification, at a glance
Label 309 defines three verifier roles, each a strict extension of the previous one:
- Structural validator — a pure function over the record bytes. No network, no signature checks, no decryption; it only confirms the record is well-formed against the schema and the standard's rules.
- Public verifier — fetches the transaction from a public explorer, runs structural validation, confirms the record is anchored on-chain, and verifies any authorship signatures. It does not decrypt.
- Recipient verifier — a public verifier that additionally holds a private key, decrypts a sealed payload addressed to it, and recomputes the plaintext hashes.
Because every role works from public data and a verifier-chosen explorer, verification never depends on the publisher's infrastructure.
The core property
A Label 309 proof is something you can check yourself. Given a transaction reference and — for content claims — the original bytes, any conformant implementation reaches the same verdict from the public chain alone.
How this specification is organized
The chapters that follow define the wire format (the record under label 309), the algorithm registries, the cryptographic key model, authorship signatures, sealed (encrypted) delivery, the verification pipeline and its error catalogue, the security model, and the cross-language conformance contract. Each page is self-contained and cites the named constants and rules an implementer needs.