Skip to main content

Concepts & glossary

This page defines every core DIG Network entity once, in plain language, and links each to the doc that goes deep. It is the human-readable spine of the docs — and, because each term is also emitted as machine-readable structured data, the map an agent can scrape to learn the network's vocabulary. Skim it to orient; follow a link to go deep.

The capsule​

A capsule is one immutable store generation: the pair (storeId, rootHash), written canonically as storeId:rootHash. It is the network's atomic unit — of compilation (one fixed-size WASM module), pricing (a flat 100 DIG to mint or commit), retrieval (a URN names one capsule), caching, and provenance. A store is a sequence of capsules, one per commit. This definition is identical across DigStore, the dig RPC, and the DIG Browser. → The capsule, in full

Store​

A store is an identity plus its content and history: a sequence of capsules, one per commit. Its identity is a 64-hex store id, which is its on-chain Chia singleton launcher id — the chain singleton is the authority for the store's current root. A store is the DIG equivalent of a website. → Store structure

Generation​

A generation is a single committed state of a store, identified by a root hash (a Merkle root over the generation's per-resource leaves). Each commit seals the current content into a new, append-only generation — the same thing a capsule names. Generations grow monotonically, like Git history. → Generations & root hashes

URN​

A URN is DigStore's address and key in one string: urn:dig:chia:<storeId>[:<rootHash>][/<resource>]. It both locates a resource and derives the key that decrypts it — possessing the URN is necessary and sufficient to read a public resource. The browser-facing shorthand is the chia:// protocol. → URNs & Encryption

Retrieval key​

The retrieval key is SHA-256(canonical_urn) — the only address that ever leaves the client. It locates a resource's ciphertext without revealing its path or its URN. It is root-independent, so the same key finds a resource across generations; the served bytes are then Merkle-verified against the correct root. The separate decryption key is derived locally (HKDF) from the same URN and never sent. → Two values, one string

Merkle proof​

Each generation builds a Merkle tree with one leaf per resource, committing to the exact ciphertext bytes served. A single inclusion proof accompanies a served resource and proves those bytes belong to that exact root — so content is verified without ever being decrypted, and a node is never trusted to have returned genuine bytes. → Merkle proofs

On-chain anchoring​

Every store is a singleton on Chia mainnet. digstore init mints it (the launcher id becomes the store id) and every digstore commit anchors a new generation root on-chain as a CHIP-0035 singleton update. Both block until confirmed and spend real funds. The chain is the authority for a store's latest root. → On-chain anchoring

DIG payment​

DIG is the DIG Network token (a Chia CAT). Minting a capsule (init) or committing one costs a flat DIG fee, included atomically in the same on-chain spend as the anchor — there is no separate transaction, and the memo carries the store id. → Costs

DigStore CLI​

digstore is the command-line tool that creates, commits, shares, and reads stores — a Git-shaped workflow (init, add, commit, log, clone, push, pull) over the encrypted, on-chain store format. → Command reference · Quick start

dig.toml​

dig.toml is the committable project manifest at a project's root — store-id, output-dir, build-command, and other project config, shared by digstore dev, digstore deploy, and the scaffolding templates. It holds no secrets (those come from the environment), so it's safe to commit. → Project config & build-time values

create-dig-app​

create-dig-app (npm create dig-app) is the JS front door for starting a DIG project: it scaffolds a runnable starter — an app, a dig.toml, and (for the wallet templates) the DIG SDK wired in — from one of five templates (static, vite-react, next-static, nft-drop, dapp-window-chia). Scaffolding is free — no mint, no chain, no spend; you spend 100 DIG only when you publish a capsule. It is the npm-side companion to the Rust CLI's digstore new. → Scaffold an app

The GitHub deploy Action​

dig-network/deploy-action is the git-push-to-deploy GitHub Action: it installs the digstore CLI on the runner, runs digstore deploy to advance your store (never mints), and reports the published capsule + URLs + cost back as step outputs, a PR comment, a GitHub Deployment, and a commit status. With if-changed (default), a byte-identical build is a no-op — no spend. → Deploy from GitHub Actions

DIG SDK​

The DIG SDK (@dignetwork/dig-sdk) is the typed npm package for integrating developers: a ChiaProvider (prefers injected window.chia, falls back to WalletConnect → Sage), a DigClient (reads verified, encrypted content over the dig RPC), and the canonical CHIP-0035 spend builder re-exported at the /spend subpath. → Build a dapp on Chia

The dig RPC​

The dig RPC is the network-wide read interface: a JSON-RPC 2.0 service over HTTPS POST that every hosting node speaks identically. It serves ciphertext + inclusion proofs by retrieval key, whole capsules by (storeId, root), and discovery metadata — blind by construction, verified and decrypted client-side. It is the universal read path: every published capsule is readable here by its URN / dig:// address the moment it confirms on-chain — no registration and no payment beyond publishing the capsule. The optional, human-friendly *.on.dig.net handle is a front door on top of this; the dig RPC itself is always available. → What is the dig RPC?

The chia:// protocol​

chia:// is the DIG Browser's native content-address scheme — the typeable front end of the urn:dig: URN. Paste a chia://<storeId>/ link and the browser fetches the content straight from the network, content-addressed and cryptographically verified. → The chia:// protocol

window.chia​

window.chia is the Chia wallet provider the DIG Browser injects into every page. It speaks CHIP-0002, so a web app can request the user's address, signatures, and spends with no WalletConnect setup — a drop-in alternative for apps that already speak CHIP-0002. → Using window.chia · The window.chia provider spec (normative, versioned)

DIGHub​

DIGHub (hub.dig.net) is the web app for publishing and managing capsules without the CLI — create a capsule, deploy a frontend, and view your stores in the browser. It is also the gated control plane that budgets expensive ZK execution-proof jobs.

on.dig.net handle​

An on.dig.net handle is an optional, paid human-friendly web address for a store: <your-name>.on.dig.net. A store does not get one automatically — you register the handle (a paid CHIP-54 / on.dig.net registration in DIGHub) and that registration pins the store to the name. No registration means no *.on.dig.net address. It is purely a convenience front door: the store is already readable over the dig RPC by its URN / dig:// address whether or not a handle exists. (Account handles and store slugs are separate namespaces and do not auto-expose a subdomain.) → Can I get a *.on.dig.net address?

Whitepapers​

The three normative specifications behind the network — Consensus, DFSP, and Digstore — for protocol developers who want the full design. Most builders won't need them to ship. → Whitepapers

For agents & LLMs​

These docs are machine-extractable. Each page carries schema.org JSON-LD (this one as a DefinedTerm set), and two curated maps live at the site root: