Is Label 309 Open Source?

Yes. Label 309 is an open standard, not a private product moat. The code is published under the Apache-2.0 license, the specification prose under Creative Commons Attribution 4.0 (CC-BY-4.0), and all of it lives in public repositories at github.com/cardanowall. Developers, companies, researchers, and the wider Cardano community can implement it, audit it, fork it, build products on it, and run their own infrastructure without asking CardanoWall for anything.

That is the whole point. CardanoWall is the first polished product built around the standard. It is deliberately not the only product that can use it.

Is it really a standard if one product created it?

It can be, but only if the work is usable outside that product.

A Proof of Existence standard should outlast the company that first ships a nice interface for it. If a record can only be produced by one website, verified by one server, or understood by one private backend, it is not a public standard. It is a feature.

Label 309 takes the opposite path:

the record format is fully documented;
the proof lives in Cardano transaction metadata under metadata label 309;
verification works from public chain data and local keys, with no issuer server in the loop;
the tooling — SDKs, command-line tool, desktop app, and gateway — is released as open-source software;
gateways can be run by anyone, not just CardanoWall;
clients can be web apps, desktop apps, command-line tools, SDK integrations, or internal company systems.

CardanoWall can still offer the easiest hosted experience. But the proof itself does not depend on CardanoWall being trusted, online, or commercially involved. For a walkthrough of that independence, see how to verify a Label 309 record.

Is this CIP-309?

The precise wording matters here, so it is worth being careful.

The Proof of Existence proposal has been submitted to the Cardano CIP process and is under review by the CIP editors as a Metadata-category proposal. Because the record uses Cardano metadata label 309, people sometimes informally call it "CIP-309" — but the metadata label is not the CIP number. The two are separate identifiers. In the open pull request the proposal currently appears with a tentative number, listed as "CIP-0190? | Proof of Existence Transaction Metadata". You can follow the discussion in the CIP pull request.

Until the review concludes, the accurate names are Label 309, metadata label 309, or the Proof of Existence CIP proposal. It is not yet an accepted or official Cardano standard, and there is no assigned "CIP-309".

The open-source commitment does not hinge on the final CIP number. The principle underneath it is simpler: the community should be able to read, implement, test, and reuse the standard without private approval from the original author.

What does open source give developers?

It turns the standard from a promise into something you can inspect and run yourself.

For developers, the public code means you can:

read the implementation instead of inferring behavior from marketing copy;
see exactly how records are encoded, signed, sealed, and checked;
reuse the SDKs (TypeScript, Python, and Rust) in your own applications;
build custom command-line tools, dashboards, verifiers, and upload utilities on top of them;
wire proof publishing into CI/CD, compliance systems, legal workflows, or AI content pipelines;
run conformance tests against your own implementation, validated against shared canonical test vectors;
report issues or propose changes in the open;
fork the code if you need a different product shape.

This matters because Proof of Existence is infrastructure, and infrastructure earns credibility when other people can build on it without a private handshake. Integrating at the lowest level — running your own gateway — is a supported path, not a workaround.

What does the Apache-2.0 license allow?

Apache-2.0 is a permissive open-source license, and it covers the code: the SDKs, the command-line tool, the gateway, the verifier, and the schemas.

In practical terms, it lets you use, modify, distribute, and build on the licensed code — including in commercial products — as long as you follow the license terms. It also grants an explicit patent license from contributors, which is one reason it is a common choice for infrastructure and developer tooling. You can read the full text at apache.org/licenses/LICENSE-2.0.

That fits Label 309 software well:

SDKs should be easy to embed;
command-line tools should be easy to package;
gateway code should be easy to self-host;
verifiers should be easy to run independently;
companies should be able to ship products without negotiating bespoke permission.

Open source does not mean "no conditions". License notices, attribution files, and the patent terms still apply. It means the permission comes from the license itself, not from a private conversation with CardanoWall.

Why is the specification under a Creative Commons license?

The code license and the specification license are separate decisions, and Label 309 makes both explicit.

The code, schemas, the CDDL grammar, and the conformance test vectors are Apache-2.0. The human-readable specification prose is licensed under Creative Commons Attribution 4.0 (CC-BY-4.0). A documentation license is a better fit for spec text because the goal is wide reuse — by implementers, educators, wallet authors, gateway operators, auditors, companies, and other standards writers. CC-BY-4.0 keeps attribution while allowing that broad reuse.

This split is intentional and already settled in the repository, not an open question waiting to be resolved before launch. The rights are released to the community so that building on Label 309 never requires private permission. If the community is expected to implement the standard, it needs a license that plainly lets it do so.

Can someone build a competing product?

Yes — and that is not a failure of the standard. It is evidence that the standard is open enough to matter.

Someone could build:

another hosted gateway;
a local gateway for internal company use;
a desktop-first proof manager;
a wallet-native Label 309 verifier;
a legal evidence dashboard;
an AI provenance pipeline;
a CI/CD attestation bridge;
a compliance archive;
a public explorer for Label 309 records;
a mobile client for receiving sealed records.

Some of those would compete with CardanoWall. Some would complement it. Some would serve industries CardanoWall never focuses on. All of it is healthy: a proof standard gets stronger when many independent tools can produce and verify the same kind of record.

What stays CardanoWall-specific?

Open source does not erase the line between a standard and a product.

The Label 309 record format, the SDKs, the command-line tool, the gateway code, and the verification logic are open for anyone to use. CardanoWall still has its own hosted service, user interface, pricing, support, operational policies, brand, domain, and product roadmap — and those stay its own.

That distinction protects both sides:

users get a convenient hosted product;
developers get reusable infrastructure;
companies can self-host when they need control;
the community can verify and extend the standard;
CardanoWall keeps building a product without making the protocol depend on one company.

The brand is not the standard. The hosted service is not the standard. The standard is the record format and the interoperable tooling around it.

Why does open source matter for trust?

Proof systems are easy to weaken with hidden dependencies.

If you must trust a vendor's database to know whether a proof exists, the system is weaker. If a record cannot be verified without a hosted account, the proof is less portable. If another developer cannot implement the same format, the ecosystem cannot independently test whether the format is sound. Open source removes those traps.

With Label 309, anyone can start from public Cardano data, retrieve the record, validate its structure, recompute hashes, check signatures, open sealed payloads locally when they are an intended recipient, and confirm Merkle inclusion proofs when a single record stands in for many files. CardanoWall can make that workflow pleasant; the open standard makes it independent.

What does this mean for companies?

For companies, open licensing lowers adoption risk.

A company might start with CardanoWall's hosted gateway because it is fast. Later, the same company might need to run a gateway in its own cloud, connect internal identity systems, archive evidence under a legal-hold policy, or publish thousands of Merkle commitments from a private pipeline. An open standard makes that path realistic.

The choice is not "use the hosted UI forever" versus "rewrite everything from scratch". A company can start with CardanoWall, add SDK or API automation, move some workflows to the command-line tool, and eventually operate its own gateway if policy or scale demands it. That gradual path is what serious infrastructure needs.

What does this mean for everyday users?

For most people, open source is not about reading code every day.

It means the tools around your proofs are less fragile. If you publish a proof today, you should not need one specific website to remain online to make sense of it tomorrow. Other tools can verify the record. Other clients can open sealed records when you hold the right identity. Other gateways can publish compatible proofs. In practice you can already use CardanoWall without the website through the open command-line tool and SDKs.

The experience can be simple because the product is polished. The long-term confidence comes from the format not being trapped inside that product.

What should you not confuse with open source?

Open source is useful, but it is not magic, and it does not settle every question on its own.

It does not mean every hosted service is free: a gateway still pays Cardano network fees, Arweave storage, infrastructure, and operational costs. It does not mean CardanoWall's brand or trademarks can be used in a misleading way. It does not mean every pull request gets accepted. And it does not mean an implementation is secure just because it follows the same standard.

It also does not replace due diligence. Before relying on a production implementation — your own or someone else's — it is worth checking:

the actual license files in the repository;
the specification license;
the CIP proposal status;
the SDK and gateway release state;
the security model for identities, sealing, and recipient keys;
the conformance tests the implementation is validated against.

The promise of open source is not that nobody needs to check anything. The promise is that checking is possible.

The short version

Label 309 is open at every layer that matters for interoperability. The code is Apache-2.0. The specification is CC-BY-4.0. The gateway is self-hostable. Verification works without trusting CardanoWall. Developers are free to build their own tools and products.

CardanoWall is the first complete product. The standard belongs to the ecosystem.