Command reference

Every dig-store command. Run dig-store <command> --help for full flags and examples. Every command below also works via digs, a first-class shorthand — digs and dig-store are the same program.

On-chain by default. init mints the store's singleton on Chia mainnet and commit anchors each new deployment root on-chain (both block until confirmed and spend real XCH). Each publishes one capsule and costs the uniform capsule price in $DIG (mint or commit) — paid to the DIG treasury in the same spend bundle (memo = store id). Both commands disclose the cost and check your balance before submitting; they block if the wallet is short on XCH or DIG. You need an unlocked wallet seed and a funded wallet first — see On-chain anchoring.

Start a store & preview — free, no spend

Try it before you pay. Scaffolding, previewing, and cost-previews cost nothing — $DIG is spent only when you publish (commit/deploy). Start here:

Command	What it does
digs new <template> [dir] [--force] [--list]	Scaffold a working project locally from a template — no wallet, no chain, no spend. Templates: static-site, vite-react, next-static, nft-drop, dapp-window-chia. Writes a dig.toml, a starter app, and (for the dapp/NFT templates) a window.chia usage example. --list prints the catalog.
digs dev [--dir <path>] [--build <cmd>] [--port <n>] [--open]	Local preview loop: builds on save and serves your project over the real chia:// read path (compile → verify → decrypt, exactly as a visitor's browser does) on http://127.0.0.1:<port>, with live reload and an injected dev window.chia shim. Free — no chain, no spend. Reads output-dir/build-command from dig.toml (flags override).
digs doctor [--json]	Pre-publish preflight: checks seed present/unlocked, wallet funds vs the capsule price in $DIG + XCH cost, dighub login, default remote reachable, and content dir present — printed pass/fail. Exits non-zero if a hard check fails. Reads only; never spends.
digs commit --dry-run [--json]	Preview the resulting version (root) and the exact DIG/XCH cost without spending, anchoring, or publishing anything.

The intended flow: digs new <template> → edit → digs dev (free preview) → digs doctor → digs commit / digs deploy (the only step that spends DIG).

Get set up & sign in

Command	What it does
digs setup (alias: auth)	One-shot onboarding: import/generate a seed, check funds, and (optionally) sign in to DIGHUb. Safe to re-run. --generate / --import, --no-login, --json.
digs link <storeID> [--output-dir <dir>] [--remote <url>]	Connect the current folder to an existing store — writes a dig.toml + remote so digs dev/deploy work here.
digs login	Sign in to your DIGHUb account via device pairing (no password).
digs whoami	Show the current DIGHUb login (handle / token presence).
digs logout	Sign out of DIGHUb (clear the stored session).

Wallet & on-chain anchoring

Command	What it does
digs seed import [--mnemonic <words>]	Import a BIP-39 mnemonic; encrypted to ~/.dig/seed.enc and unlocked for the session
digs seed generate [--words 12|15|18|21|24]	Generate a new mnemonic (shown once), encrypt, and unlock
digs seed status	Show whether a seed exists and is currently unlocked
digs lock	Lock the seed (clear the cached-unlock session)
digs balance [--json]	Show spendable XCH (mojos) and DIG (3-decimal display) + the wallet receive address (read-only)
digs anchor [--wait-timeout <secs>]	Resume a pending anchor: poll the chain and flip the store to confirmed
digs anchor status [--json]	Show the store's anchor state (network, launcher/store id, current coin, height) + the pointer embedded in the module
digs anchor inspect <module.dig> [--json]	Decode and print the on-chain pointer embedded in any compiled module file

Set the wallet passphrase non-interactively with DIGSTORE_PASSPHRASE. Global config lives in ~/.dig/config.toml (coinset_url, unlock_ttl, fee, node.url).

Configuration

Command	What it does
digs config node.url <url>	Persist a custom node endpoint for this machine (~/.dig/config.toml) — every subsequent command talks to this node first, ahead of the automatic dig.local → localhost → rpc.dig.net resolution below.
digs config node.url --local <url>	Persist a node endpoint for this project only (.dig/node.toml), so one project can use the public gateway while another uses your own node. Beats the machine-wide value.
digs config node.url [--local] --show	Print the current value for that scope.
digs config node.url [--local] --unset	Remove the stored override; resolution falls back to the automatic ladder.
digs config <key> [<value>]	Get or set any config key in ~/.dig/config.toml (coinset_url, unlock_ttl, fee, node.url). Omit <value> to print the current value.

Which node dig-store talks to

Every command that reaches a node (clone, pull, push, reads, serve peers, etc.) resolves the endpoint in this fixed order, using the first that responds:

1. An explicit override — the --node <url> global flag, then the $DIG_NODE_URL environment variable, then this project's node.url (.dig/node.toml, set via digs config node.url --local <url>), then the machine-wide node.url in ~/.dig/config.toml. Any of these always wins over the steps below.
2. dig.local — your installed local dig-node, on https://dig.local then http://dig.local.
3. localhost — a dig-node on the loopback address, http://localhost:9778 (or $DIG_NODE_PORT).
4. rpc.dig.net — the public gateway, the final fallback when no local node answers.

Your own node comes first: rpc.dig.net is an ordinary node that happens to be well known, not a privileged one, and it is only used when nothing local answers.

Each tier is a cheap health probe with a short timeout, so dig-store never hangs waiting on an unreachable local node.

Today every tier is reached over plain HTTPS (loopback tiers over plain HTTP), with each request carrying your signed identity headers — that signature, not the transport, is what authenticates you. Mutual TLS with a client certificate derived from your identity key is specified for node-class clients but is not yet wired; when it lands, it will be layered under the same signed requests rather than replacing them. See Point a consumer at your node for the same ladder as it applies to the DIG Browser and extension.

Setting a node per project

--local writes .dig/node.toml in the current project, so the setting travels with the project rather than the machine:

# this project reads through the public gateway…
digs config node.url --local https://rpc.dig.net

# …while every other project keeps using your own node
cd ../other-project && digs config node.url --local --unset

Because .dig/node.toml can be committed and therefore arrives with a repository you clone, digs does not use a node.url it did not see you set. The first time an unfamiliar project asks for a node, digs shows you the URL and asks; if it cannot ask — a script, CI, or --json — it ignores the value and uses the normal ladder. Approving one project does not approve another, and if a project later changes its node.url, digs asks again. This matters because digs signs every request it sends to a node with your identity key.

When no local node is running

Reading still works. pull, clone, and cat fall back to rpc.dig.net and tell you that the read left your machine.

Publishing does not. push and revoke sign every request with your identity key, so rather than send your content and your signatures to a server you never chose, they stop with NO_LOCAL_NODE (exit 19) and tell you how to check your node and where to install one:

dig-node status   # exit 0 = serving, 1 = not serving
dig-node start    # if it is installed but stopped

No node yet? See Run a node — or, if you deliberately want a remote one for this project, digs config node.url --local https://rpc.dig.net.

Stores & workspace

A single workspace (.dig/) can hold many stores. The commands below create and switch between the stores in your workspace.

Command	What it does
digs init [name] [--dir <path>] [--private] [--wait-timeout <secs>]	Initialize a store (default name default); --dir sets its content root. Mints the store singleton on Chia mainnet — the launcher id becomes the store id — and blocks until confirmed (--wait-timeout, default 300s). Costs the uniform capsule price in $DIG + an XCH fee (paid atomically in the same bundle; cost is disclosed before submission). Requires an unlocked seed, XCH, and DIG; on a confirmation timeout the store is kept pending and resumable with digs anchor. Interactive when flags are omitted.
digs stores	List stores with the active marker, root, content root, and capacity
digs use <name>	Set the active store
digs dir [<path>]	Show or set the active store's content root

Back-compat aliases. digs projects (for digs stores) and the --project flag are kept only as hidden aliases for older scripts; new usage should say stores / store.

Staging & commits

Command	What it does
digs add <path…> [-A] [--key <name>]	Stage files (-A = the whole content root)
digs staged	List the staging area
digs unstage	Clear the staging area
digs commit [-m <msg>] [--wait-timeout <secs>]	Seal a new deployment: anchor the new deployment root on Chia mainnet and block until confirmed (--wait-timeout, default 300s), then compile the module + write the URN manifest. Publishes a new capsule for the uniform capsule price in $DIG + an XCH fee (paid atomically in the same bundle; cost is disclosed before submission). On failure/timeout the local deployment is not finalized (re-run to resume).
digs commit --dry-run [--json]	Preview the resulting version (root) + the exact DIG/XCH cost without spending or publishing anything.
digs status	Show staged / modified / untracked + remaining capacity

History

Command	What it does
digs log [--limit N]	List deployments (each root hash is a commit)
digs diff <a> <b>	Compare two deployments

Reading content

Command	What it does
digs urn [PATHS…] [--root <hex>]	Preview the URN(s) and retrieval key(s) files will have
digs keys [--root <hex>]	List the retrieval key + URN for every committed resource
digs cat <urn-or-retrieval-key> [--out <file>] [--salt <hex>] [--verify-proof]	Stream a resource out — by URN (decrypted) or retrieval key (encrypted)
digs checkout <root> --out <dir> [--salt <hex>]	Write a whole deployment to a directory

Remotes & sharing

Command	What it does
digs remote add|list|remove …	Manage remotes
digs clone <url>	Clone a store from a remote. Verified: module identity + signed head + the served root is checked against the store's current on-chain singleton root (fails closed)
digs push [remote]	Push the local store's content + signed head
digs pull [remote]	Pull the latest content + signed head. Verified, including the on-chain root check
digs revoke [--root <hex>|--all] [--reason <r>]	Revoke a published root or the whole store with a signed tombstone
digs serve [--bind <addr:port>] [--store <name>]	Run a dig:// remote node for the active store — serves clone/pull/push over the §21 protocol (the same one rpc.dig.net speaks), so anyone can host an origin. Each request is authenticated by a signed message from the caller's identity key.

CI deploy

Command	What it does
digs deploy [--store-id <hex>] [--output-dir <dir>] [--build-command <cmd>] [-m <msg>] [--remote <url>] [--writer-key <hex>] [--preview] [--if-changed]	Advance an existing store from a fresh checkout (CI): reconstruct it locally, stage the output dir, commit + push a new capsule. Reads dig.toml. Never mints. --writer-key advances the root with a revocable writer-delegated key (no owner seed); --preview produces a free, no-spend content-addressed build; --if-changed makes a byte-identical build a no-op.
digs deploy-key export [--out <file>]	Export the store's §21 publisher deploy key (64-hex) to store as a CI secret
digs authorize-origin-as-writer <origin> [--pubkey <hex>] [--dry-run] [--fee <mojos>]	Discover ORIGIN's DIG pubkey at https://<origin>/.well-known/dig/pubkey and add it as a CHIP-0035 writer delegate on the active store — authorizes a website/hub's own identity directly, with no key to copy or hub-managed secret. --pubkey skips discovery for a caller that already has the key. Idempotent: re-authorizing an already-authorized pubkey is a no-op.

See Deploy from GitHub Actions for the full workflow.

Assets — NFTs, collections, DIDs, offers

Build the spend with the canonical CHIP-0035 builders, sign with your wallet, and push via coinset — every command is --json / --dry-run CI-safe.

Command	What it does
digs nft mint|bulk|transfer|list …	Mint an NFT (media stored permanently in a DIG capsule), bulk-mint, transfer, or list the NFTs the wallet owns.
digs collection create|mint|show|list …	Define a collection (shared id/name/royalty) and bulk-mint its items from a traits manifest, attributed to a creator DID. Large collections are auto-split into cost-bounded on-chain batches (so no bundle exceeds Chia's per-block cost limit) and the mint is resumable — re-run to continue after an interruption, skipping already-minted batches. collection mint --batch-size <n> forces a smaller batch than the cost-model default.
digs did create …	Create a creator-identity DID (decentralized identifier) owned by the wallet.
digs offer make|take|show …	Make, take, and inspect Chia offers (XCH / CAT trades).

Maintenance

Command	What it does
digs update [--check] [--yes]	Update dig-store to the latest release
digs compile [--metadata]	Compile the active store to its self-serving .dig WASM module (used internally by the publish flow).
digs completion <shell>	Print a shell completion script (bash, zsh, fish, powershell, elvish).

Global flags

Flag	Effect
--node <url>	Use this node for the command, ahead of the automatic dig.local → localhost → rpc.dig.net resolution. Same precedence tier as $DIG_NODE_URL and the stored node.url config (flag wins if more than one is set) — see Which node dig-store talks to.
--store <name>	Operate on a specific store (overrides the active store). --project is a hidden back-compat alias.
-C, --cwd <path>	Operating directory for this command (overrides the content root)
--dig-dir <path>	Workspace location
--json	Machine-readable output
--quiet	Suppress progress and hints
--verbose	Verbose (debug-level) logging
--color <auto|always|never>	Color output mode

Related

• CLI tutorial — the most common commands in order
• On-chain anchoring — wallet, costs, and the init/commit flow
• Sharing over a remote — remote, clone, push, pull, revoke
• Streaming & retrieval keys — cat, keys, checkout
• Deploy from GitHub Actions — deploy, deploy-key
• Point a consumer at your node — the same node-resolution ladder for the DIG Browser and extension
• Concepts & glossary — the entities these commands operate on