Do CardanoWall Proofs Work Offline?

Yes — for anything already on your device. Once a Label 309 record, its content or ciphertext, and the keys to open it have been synced, CardanoWall Desktop can browse, search, decrypt, and verify them with no network connection. What it cannot do is invent data it never saw: a transaction it never synced, or a ciphertext it never downloaded.

CardanoWall Desktop works offline-first. Its local database is the source of truth for the screen in front of you; the network is a background synchronizer that fills that database in. So "offline" is a normal mode, not an error — the local machine becomes a working copy of the part of the proof world you already pulled down.

That working copy is exactly what makes proofs useful in the field: during travel, an audit, legal review, incident response, or anywhere the connection is unreliable. A proof should not become unreadable just because a tab cannot reach a server. CardanoWall Desktop is open source — built in Rust with Tauri on top of the open-source Rust SDK, with its code at github.com/cardanowall — so you can read exactly how it behaves rather than take this on faith.

What can you do with synced proofs offline?

A lot, as long as the data is already local. If it is, CardanoWall Desktop can let you:

browse synced public Label 309 records;
search the local record mirror, including by content hash;
view inbox records already discovered by trial-decryption;
open cached ciphertext;
decrypt sealed files with your local keys;
verify hashes against local files;
check the structure of cached records;
review your sent-record history;
prepare drafts to publish later.

These are real cryptographic operations, not cached screenshots. The hash check, the signature check, the trial-decryption — all of them run locally in the app's Rust core, against bytes that are already on disk.

What can't you do offline?

Offline mode has a hard edge, and it is honest about where the edge is. The app cannot manufacture data it never had.

If a transaction was never synced, the app cannot know it exists without the network or some other local copy of its metadata.
If a ciphertext was never downloaded, the app cannot decrypt it offline.
If a record points to a storage URI and those bytes were not cached, the app cannot fetch them without a connection.
If you want to publish a new proof, the app needs a gateway and a network: it must price the publish, upload, submit the Cardano transaction, and confirm it. (Publishing always runs through a gateway — see why publishing has a price.)

Offline-first is not a claim that the app can fill in missing data. It is a claim that once data is local, the app treats it as first-class.

What does the app cache, and how sensitive is each layer?

There are four layers, in increasing order of sensitivity.

Public record metadata. The desktop keeps a complete local mirror of Label 309 records — sealed and public — from the gateway you configured. Each record is small (a single transaction's metadata, capped well below Cardano's ~16 KB metadata limit), so the whole global set stays in the range of a few hundred megabytes even after years of heavy use. This mirror is the substrate for search, inbox discovery, sent-record tracking, and offline inspection. It contains only what is already public on chain, so it is stored unencrypted by design — encrypting a copy of public data buys nothing.

Ciphertext. Sealed records reference encrypted payloads through content-addressed storage (ar:// or ipfs://). Caching that ciphertext is safe because it is already encrypted; it can only be opened by someone holding a matching key. The desktop caches it so re-opening a received file is instant and works offline.

Decrypted content. This is the sensitive layer, and the app treats it carefully. By default it decrypts on demand into memory and never writes plaintext to disk. An optional, separately encrypted decrypted-file cache exists for users who want instant previews without re-unwrapping, but it is off by default, and plaintext is written to a normal location only when you explicitly choose Save. You should always know when decrypted files are kept, where, and how they are protected.

Identity material. Identity Seeds live in an encrypted vault and are unlocked locally. Without the relevant identity unlocked, a sealed record can still appear in the mirror as a public record — you just cannot open its content. The seed itself never leaves the device and never reaches any gateway. (For why that boundary matters, see why keys never leave the device.)

Can you verify a proof offline?

Yes — once you have the inputs the check needs. Label 309 verification is designed to run from public data alone, so the cryptographic checks have no dependency on CardanoWall's servers. What each check needs:

A hash proof needs the record and the original bytes. The verifier recomputes the hash from the bytes and compares it to the hash committed in the record. Fully offline.
A signed proof needs the record and its embedded signature. The signing key is carried in or resolved from the record's signature structure, so signature verification runs offline once the record is local.
A sealed proof needs the record, the ciphertext, and the recipient key (or passphrase) that opens it. With those local, the app decrypts, recomputes the plaintext hash, and checks it against the record's commitment — the step that ties the encrypted bytes back to the timestamped claim.
A Merkle proof needs the root from the record plus the inclusion proof (or the leaves-list to rebuild it). Then the inclusion check runs offline, with no gateway in the loop. Building a Merkle tree and verifying inclusion are pure computation — see one record for thousands of files.

The only thing that normally needs the network is obtaining data you do not yet have, plus confirming current chain state. The math itself runs locally. (For the full verification model, see how to verify a Label 309 record.)

What about blockchain confirmation when you're offline?

A proof's timestamp and confirmation status come from Cardano, and those are facts the app reads from the chain — it never makes them up.

If the app already synced a transaction and its confirmation depth, it can show that cached state offline. What it cannot do offline is learn about new confirmations, a chain reorganization, or any updated context, because that requires asking a Cardano explorer.

So a careful client keeps these states distinct:

cached, locally verified record data;
the last time each item synced;
confirmation depth as of the last sync;
records still pending or below the confirmation threshold;
records that need a fresh online re-check.

Offline display should be honest about freshness. It should never present last week's confirmation depth as if it were current.

How does offline inbox discovery work?

Your inbox is computed locally from two things: the record mirror and your unlocked identities. The gateway is deliberately recipient-blind — it has no idea which sealed records are "yours" — so finding your mail is a local job by design.

If the app has synced sealed records, it trial-decrypts them against your identities right on the device. For each sealed slot it attempts a decryption; the ones your keys can open are your messages. No server is asked who you are.

This is also why importing an old Identity Seed works cleanly offline. Because only the recipient key decides a match, the app re-scans the already-present local mirror for that identity and surfaces older sealed records that were addressed to it — a local pass, no re-download. (Your identity is just that seed; see your identity is a seed.)

If the mirror is incomplete, the inbox may be incomplete. When the network returns, the app syncs the missing records and continues discovery.

Why not keep everything only in the cloud?

Because the cloud should not be the root of trust. A hosted service is convenient — it can publish records, serve the feed, handle pricing, and make the interface easy. But a proof should outlive any one service account, and the whole point of Label 309 is that verification needs only public infrastructure: the transaction metadata, optionally the content bytes, and a public Cardano explorer. A local working copy of the records you care about is the practical expression of that independence.

That local copy earns its keep in exactly the situations where a single web session is too fragile: audits, incident response, legal holds, evidence review, journalism, research archives, regulated workflows, and long-term preservation.

How should a team use offline proofs?

Decide, ahead of time, what you may need to prove without a network — then sync and cache the verification material before the network is gone.

The shape of "what to cache" follows the work:

A legal team may want encrypted evidence packages cached on an approved machine.
A compliance team may want each day's proof records and inclusion proofs available during an audit.
A release or DevSecOps team may want build proofs and release manifests cached alongside the release archive.
An AI team may want dataset manifests and model-output commitments mirrored locally.

The rule is simple: if you might need to prove it offline, sync it and cache the material that proves it before the connection disappears. For sealed content, also confirm the relevant Identity Seed is backed up and available to the right people or devices under your policy — without it, the ciphertext stays closed.

What are the risks of holding proofs locally?

Offline access moves some responsibility onto the device, and it is worth being clear about that.

There is local-storage risk. If a device is stolen, its caches matter. Cached ciphertext is encrypted and cannot be opened without a key, but any decrypted files you chose to keep are sensitive, and the identity vault must be protected. The operating system, disk encryption, user account, passphrase, and general device security all become part of the trust story. CardanoWall Desktop reduces exposure with an encrypted vault, auto-lock, and best-effort zeroization of keys in memory, but it cannot defend a fully compromised, unlocked machine — and it says so plainly.

There is also freshness risk. A cached proof is valid as of its last sync, but the app cannot know the current chain state until it reconnects.

Good software makes these boundaries visible: it shows the last sync time, distinguishes cached verification from a fresh online check, and avoids silently writing decrypted plaintext to unsafe locations.

What should you keep for a long-term proof?

For proofs that matter for years, keep more than the transaction hash. Depending on the proof type, that means:

the transaction reference;
the Label 309 record bytes (or a verified export);
the original file or plaintext;
the ciphertext, for sealed records;
the Identity Seed or recipient secret needed to decrypt;
the Merkle leaves-list or inclusion proofs;
any signatures or public keys needed for attribution;
a short note on how the proof was created and which process it belongs to.

The blockchain supplies the public anchor — the fact that these exact bytes existed by a public block time. Your local archive preserves the context that makes the anchor useful later. (And remember what the anchor does and does not assert: see what a proof does not prove.)

The short version

Offline proof is not magic; it is preparation. If the record, the content, the ciphertext, the keys, and any inclusion proofs are local, the cryptographic checks all run locally. If something was never synced or cached, the app needs the network to fetch it — and it tells you so rather than pretending.

CardanoWall Desktop makes that local working copy normal: it syncs the records, discovers sealed inbox items on the device, caches encrypted files, verifies proofs, and keeps already-synced evidence useful even when the network is gone.