If this instance disappears

The chain is the source of truth

Cachet is an interpretation layer over public chain data. Every asset, supply, issuer and event it shows is folded from blocks anyone can read, so the database is a cache: deleting it costs about a minute of resyncing, not a single fact. There is no ownership table, no private ledger, and nothing that exists only because this server says so.

The same rule holds when the chain itself changes under the registry. The public ZSA testnet is run by QEDIT, the team building ZSAs, not by this registry. A test network can be reset by its operators and start again from block zero; it happened on 10 September 2026, and on 25 September the testnet started again as a new network with a corrected Orchard circuit. Each time, everything issued before exists only on the abandoned chain, so this registry dropped its index and re-indexed the new chain from the start. What was never on the chain stays: the sealed bundles are still served, and an asset id is derived from the issuance key and the sealed description, never assigned by a chain. A re-mint under the same seed with the same name, text and image, byte for byte, is therefore the same asset id again, on the new chain; change any of them and it is a different asset. One trap: an image over about 180 KB is re-encoded by the browser before it is sealed, and another browser may not produce the same bytes. Re-mint with the sealed image this registry serves, which is kept as is, rather than with the original file. A registry that kept showing assets its node can no longer see would be lying.

Kept from before a reset

Sealed content this registry still holds for assets the chain no longer carries. Open one to mint it again: the page loads the sealed name, text and image as they are, and tells you whether your seed gives the same asset id before anything is signed.

Run it yourself

The whole thing is MIT licensed - console, indexer, API, browser mint engine and the metadata specification. Self-hosting is the documented path, not an afterthought: the deploy script is the same file this deployment runs, and it points at nobody's machine by default.

git clone https://github.com/cachet-zec/cachet && cd cachet
docker compose -f infra/docker-compose.yml up -d   # chain + Postgres
pnpm install
cargo run --manifest-path server/Cargo.toml --bin cachet-server   # API
pnpm dev                                                          # console

A fork is not a degraded copy. It indexes the same chain, verifies the same commitments, and signs its own snapshots under its own key.

Mirror it, and check the mirror

The registry exports itself as a deterministic snapshot - sorted, timestamp-free, so the same chain state always produces byte-identical bytes - sealed with an Ed25519 signature. A mirroring script ships in the repository. It uses only the Python standard library, re-derives the hash of every bundle it downloads, and exits non-zero if anything fails to verify.

python scripts/mirror.py                          # mirror this registry
python scripts/mirror.py --api https://your.instance --out ./mirror

A snapshot signed by any other key is not this registry, whatever a mirror claims. The key is also printed in the working paper, which is the durable anchor: verifying a mirror should never require trusting the mirror.

Give the copy back

A mirror is not an archive to look at: it rebuilds an instance. The second script sends a mirror to any running instance through the two routes that are open to everyone, and the instance checks every item against the chain itself. It needs no database access and no one's permission, this operator's included.

python scripts/restore.py --to https://api.new.instance --mirror ./mirror

Check the code this site runs

A browser mint keeps the seed in the page, so what matters is the code the page runs. The mint worker and the wasm engines are plain files committed to the repository, with their hashes in engine-manifest.json. From a checkout of the release you expect, one command downloads them from a live site and compares every byte:

python scripts/verify-site.py --site https://cachetzec.com

It covers the engine, where keys are derived and transactions signed. It does not cover the application code around it, which is not built reproducibly yet. Running the console from source covers both.

Already addressable on IPFS

The hash sealed into an asset is, byte for byte, the body of an IPFS content id: a CIDv1 for a raw block is a four-byte prefix followed by the SHA-256 of the data. So every bundle has an IPFS address that anyone can compute from its sealed description. Nothing had to be uploaded for that to be true, and nobody needs this registry's permission to host a bundle under it.

The mirroring script can publish what it verified to an IPFS node you run. It stores each bundle as a single block and refuses any whose address differs from the one derived from the sealed hash.

python scripts/mirror.py --ipfs                   # mirror, then pin to your local IPFS node

IPFS keeps data only while someone pins it, so this is a way for more people to hold the bytes, not a promise that they are held. This site does not read from IPFS gateways: a gateway is a third party that would see who is looking at what.

What would actually be lost

Three tables cannot be rebuilt from the chain, and saying so is more useful than claiming nothing would be lost:

• metadata_bundles - the descriptions and images minters sealed. The chain commits to their hash, never their bytes.
• asset_descriptions - the resolution journal. Re-derivable by anyone who knows a description, since resolution is permissionless and verified against the chain.
• moderation_hidden - what this operator chose to withhold. A mirror that disagrees simply does not have it.

What that costs is availability, never integrity: a bundle is verified against its on-chain hash in the reader's browser, so the store can be lost, mirrored or replaced - but never forged. Anyone holding a mirror holds those bytes too, which is the point of publishing the mirroring script rather than describing it.

What was never here

Most continuity risk comes from what a service holds hostage. Cachet holds nothing: no accounts, no custody at any phase, no allowlist, no ownership database, and no key that only the operator has. Assets are minted in the browser under the minter's own key, so nobody needs this instance to keep controlling what they issued. The mint page can hand over the signed transaction instead of relaying it, and any instance's relay, or any tool that assembles a block, can land it.

The honest remainder: this deployment's domain and its signing key belong to its operator. A successor cannot inherit them, and should not - they would publish their own key and let readers anchor it, exactly as this one does.