All posts

9 min read

What Is a Label 309 Gateway?

A Label 309 gateway is the publishing service that quotes, uploads, submits, confirms, and indexes Proof of Existence records through a standard API — while your keys stay on your device and proofs verify from public data.

A Label 309 gateway is the service that publishes Proof of Existence records to Cardano. It handles the operational work — pricing, uploads, transaction submission, confirmation tracking, record indexing, balances, API keys, and webhooks — so a client doesn't have to. The client prepares the proof and keeps private keys local; the gateway gets the record onto the network.

Label 309 is the open, vendor-neutral standard for anchoring a content hash on Cardano under metadata label 309. The gateway is the part that does the publishing. It is not a private backend that only one company can use — it is a defined service layer that any product can run or integrate against, and the reference implementation is open source. CardanoWall runs its own commercial product on exactly these surfaces, with no separate path reserved for itself.

Why does publishing need a gateway at all?

Verification is light. Publishing is operational.

To verify a proof, you usually start with a Cardano transaction reference, fetch the record from a public explorer, and recompute the hashes or signatures yourself. No special service is required — that independence is the whole point of the standard. (See how to verify a Label 309 record for the full path.)

Publishing has many more moving parts:

  • build a valid Label 309 record;
  • estimate the Cardano transaction cost;
  • upload ciphertext or content when files are involved;
  • pay storage costs;
  • submit the Cardano transaction;
  • wait for confirmation;
  • handle failures and refunds;
  • index the result;
  • expose status back to the user;
  • keep account balances accurate.

A gateway packages those concerns behind an API. Without one, every product that wanted to publish would have to rebuild the same chain-and-storage pipeline. With one, a product team can focus on its user experience and business workflow while the gateway handles chain, storage, and accounting.

What does the gateway actually do?

The gateway owns the publish pipeline and the money, chain, and storage state behind it. In practical terms it can:

  • quote a proof before you publish (the price holds for a short window, around 15 minutes);
  • accept encrypted uploads and public content uploads, returning content-addressed URIs;
  • accept a prepared proof record;
  • build and submit a Cardano transaction with exact fees;
  • track confirmation, including reorg handling;
  • automatically refund the charge when a publish fails permanently;
  • index every Label 309 record on the network into a shared, public feed;
  • manage prepaid account balances and apply pricing;
  • issue API keys and account tokens;
  • send webhooks for lifecycle events.

That makes it the publishing engine behind the CardanoWall web app, the desktop app, the command-line tool, SDK-based integrations, CI/CD workflows, and third-party products alike.

What does the gateway deliberately not do?

The gateway is not the root of trust.

It never needs your Identity Seed. It never needs private recipient keys. It does not decrypt sealed files. And it is never the only place a proof can be checked. Those properties are by design: keeping them out of the gateway is what lets a proof stand on its own.

A valid Label 309 proof rests on public data, not on the gateway's word:

  • the Cardano transaction;
  • the Label 309 metadata;
  • the original content or ciphertext, when needed;
  • record signatures and public keys;
  • Merkle proofs, for batched records;
  • the recipient's own keys, for sealed content.

If the gateway reports that a proof exists, a verifier can still confirm it against the chain — with no involvement from the gateway. For what a gateway operator can and cannot observe, see what CardanoWall can see.

What is the data plane?

The data plane is the user-facing API. It is what a client calls when it acts on behalf of a user or account — a web app, the desktop app, the CLI, an SDK, or an automation script asking to quote, upload, publish, read a balance, or list records. It lives at the /api/v1/* path.

The conceptual flow is short:

  1. Ask for a quote.
  2. Upload content or ciphertext, when files are involved.
  3. Publish the proof.
  4. Track status.
  5. Read records and balances.

This is the same path the reference product uses. If a flow works for CardanoWall, it is available through the public data plane to anyone.

What is the control plane?

The control plane is for operators and product backends, and lives at the /control/v1/* path.

If a company builds its own product on a gateway, its backend needs to create accounts, apply billing credits, mint short-lived account tokens, set per-account margins, create API keys, and run operator-level tasks. That is control-plane work, and it must happen from a trusted backend — never from browser code or a mobile client.

The control plane is what lets a gateway support more than one product. Another team can run its own vendor layer on top: its own users, billing, UI, support, and product semantics, while the gateway handles the base publish pipeline underneath. The boundary between the two is the HTTP API and the webhook firehose — not the gateway's database, which stays private to the engine.

What does "no private door" mean?

It means the reference product publishes through the same surfaces everyone else gets. There is no secret, faster, or privileged path reserved for CardanoWall.

This matters for credibility. If a project claimed its standard was open but published through hidden internal machinery, the ecosystem would stay dependent on that one vendor. The gateway model removes that dependency: CardanoWall can be the polished first product, while other teams build their own tools, services, dashboards, desktop clients, and industry workflows on the identical standard path. If you are building on it, see build on a Label 309 gateway.

Can a company run its own gateway?

Yes. The gateway core is open source — a single Rust binary plus PostgreSQL — and a company can run it itself: fund its own Cardano and Arweave wallets, create its own accounts and API keys, and publish Label 309 records without depending on CardanoWall as a hosted operator.

Self-hosting can make sense for:

  • high-volume publishing;
  • strict vendor policies;
  • regulated or air-gapped environments;
  • internal compliance workflows;
  • legal evidence systems;
  • AI provenance infrastructure;
  • CI/CD proof pipelines;
  • teams that already operate their own cloud and chain infrastructure.

Self-hosting does not change the record standard — a self-hosted gateway produces the same records, verifiable by anyone. It only changes who operates the publishing service. The practical setup is covered in run your own gateway.

When should I use the hosted CardanoWall gateway?

Use the hosted gateway when convenience matters more than running infrastructure yourself.

The hosted service handles funding, pricing, submission, confirmations, storage, and account management for you. That suits individual users, small teams, early integrations, and companies that want to start quickly. You still get standard records, you can still verify from public data, and you can still move to your own tooling or your own gateway later. Hosted does not mean locked in.

When should I self-host instead?

Self-host when operational control matters more than convenience. Good reasons include:

  • you publish at high volume;
  • you want your own fee and funding policies;
  • your organization cannot rely on a third-party hosted service;
  • your records belong to an internal, regulated workflow;
  • your product needs its own billing model;
  • you want to offer Label 309 publishing under your own brand;
  • you want direct control over API keys, accounts, and webhooks.

Self-hosting is more work. You run the gateway, fund the wallets, monitor providers, manage secrets, operate the database, handle upgrades, and keep the service healthy. The payoff is independence.

How does pricing fit in?

Publishing costs money because the gateway pays real costs. Every proof anchors a Cardano transaction, which carries a network fee. When files are involved, the gateway also pays for Arweave storage. On top of that it carries exchange-rate handling, funding, infrastructure, monitoring, support, refunds, and risk.

So a hosted gateway charges on a cost-pass-through basis plus a service margin. Exchange rates are live — the gateway prices each quote from current market rates rather than a hardcoded constant — and the rate behind a quote can move, which is why a quote is only valid for a short window. The displayed price can vary by account, partner, or operator policy. For the reasoning behind charging at all, see why publishing has a price.

If you want to avoid a hosted intermediary's margin, the answer is not free publishing — the chain and storage costs are real either way. The answer is to run a gateway, fund it directly, and take on the operating work yourself.

How does the desktop app relate to the gateway?

CardanoWall Desktop — an open-source desktop app built on the Rust SDK — is a gateway client, not a chain operator.

It holds identities locally, syncs and trial-decrypts sealed records on your own machine, caches data for offline use, prepares and signs records, encrypts files, and verifies proofs — all locally. It is explicitly not a wallet: it does not custody ADA or build and submit Cardano transactions itself. For anything that touches the chain or storage, it points at a gateway and lets the gateway own the publish pipeline.

You choose which gateway:

  • the hosted CardanoWall gateway;
  • your company's own gateway;
  • any third-party gateway;
  • a local or development gateway.

The desktop owns the local experience; the gateway owns publishing. More on the app in CardanoWall Desktop.

What should developers keep in mind?

Build against the standard boundary — the HTTP planes and webhooks — not against gateway internals.

A few rules keep an integration honest:

  • Do not query the gateway's database directly; it is engine-internal and can change without notice.
  • Do not put operator credentials in clients. Anything that needs operator authority belongs in your backend.
  • Do not treat a cached balance as the source of truth for a spend decision; read the gateway's balance when it gates a charge.
  • Do not build your own refund path for publish failures — the gateway already auto-refunds, and a second refund would double-pay.
  • Do not ask the gateway to decrypt user content.

The clean shape is straightforward: your client or backend captures user intent, your client keeps secrets local, the gateway handles quote, upload, publish, confirm, and index, your product builds its own UI and read models on top, and verification stays independent. That is how one standard can support many products without turning every product into a chain-and-storage operator.

The short version

A Label 309 gateway is the publishing layer. It quotes, uploads, publishes, confirms, indexes, and exposes records. It can be hosted by CardanoWall, self-hosted by a company, or integrated into another product.

It is not the root of trust, and it does not hold your private keys. It publishes standard records that anyone can verify from public Cardano data — which is exactly what keeps the standard open.

Further reading

gatewaylabel-309developers