Launch or import a token — launch into a pool, create and expand tokens, discover and reclaim registrations, estimate pricing, manage the token page (discover, reclaim, estimate, create, clone, launchpad, profile, wallet, listings, status, embed).
Reach holders — airdrops (airdrop …).
Apps — scaffold, build, sign, and submit .capp packages (app …, developer …, oauth …). See App publishing below.
Creator store — items, orders and rewards for your token (iap …).

Every command takes the global --json (machine-readable output) and --non-interactive (never prompt) flags, and is designed for humans and agents (Claude Code, CI, scripted pipelines).

Installation

Requires Node 20 or later.

npm install -g @chaindaddy/cli@beta
chaindaddy --version

Each release is built from its public source, opencrown/chaindaddy-cli, and published with npm provenance. Verify with npm audit signatures in a project that installs it (npm does not check global installs).

Authentication & environment

The ChainDaddy public API puts a project-wide gate in front of every non-public route: a request must carry either an allowed browser Origin header or a valid X-API-Key: cd_live_… header. A non-browser caller (this CLI, an agent, CI) has no Origin, so every API call needs a cd_live_ API key — get one at https://chaindaddy.io/_plans. Note that a cd_live_ key sent only as Authorization: Bearer … does not satisfy the gate; the CLI sends it in X-API-Key automatically.

Variable	Purpose	Alias
`CROWN_API_KEY`	`cd_live_…` key. Used as the gate's `X-API-Key` on every call and as the route-level bearer / `.capp` signing secret.	`CHAINDADDY_API_KEY`
`CROWN_API_URL`	API base URL (default `https://api.chaindaddy.io`).	`CHAINDADDY_API_URL`
`CROWN_DEV_TOKEN`	Optional explicit developer bearer token (rarely needed; the API key covers the common case).	—
`CHAINDADDY_IAP_KEY`	A store key (`cd_iap_…`, one store, scoped) for `chaindaddy iap` store-scoped commands, e.g. on your app's server. Sent alone: store routes need no `cd_live_` key. `--key` overrides it.	—

Either name works; set whichever your environment already uses.

export CROWN_API_KEY=cd_live_your_key_here   # or CHAINDADDY_API_KEY
chaindaddy estimate --symbol DOGE --chains arbitrum

On-chain registry actions additionally use a local keystore — see chaindaddy wallet --help (keys never leave your machine).

Commands

Symbol registry

Command	Description
`estimate`	Estimate pricing for token creation and crown claiming
`create`	Create a new token (interactive wizard or flags; `--batch` for bulk)
`clone`	Expand an existing token to additional chains
`discover`	Discover inactive crowns available for reclaim
`reclaim`	Reclaim an inactive crown (heartbeat below threshold)
`profile set`	Set up or update a crown profile
`wallet`	Manage the local wallet keystore
`status`	Heartbeat health — one token (`--symbol --chain`/`--crown`), a `--wallet` batch, or an `--at-risk` scan
`listings platforms`	List the aggregator platforms and their real submission URLs
`listings readiness`	Show how submission-ready a token is for a platform (score + missing fields)
`listings export`	Build a submission template (real URL + auto-filled crown metadata) for a platform

chaindaddy estimate --symbol DOGE --chains arbitrum,base
chaindaddy discover --limit 20 --json
chaindaddy reclaim --crown 42 --wallet 0xYourAddress --yes
chaindaddy create --symbol DOGE --name "Doge" --chains arbitrum --yes
chaindaddy status --symbol DOGE --chain arbitrum
chaindaddy status --wallet 0xYourAddress
chaindaddy status --at-risk --limit 100 --json
chaindaddy listings platforms
chaindaddy listings readiness --symbol DOGE --platform cmc
chaindaddy listings export --symbol DOGE --platform cmc --out cmc.json

status is wired against the live heartbeat endpoints (EVM-only — Solana crowns have no heartbeat score). listings is wired against the live listing API: readiness scores filled-vs-required fields, and export auto-fills the crown's real metadata (name, website, socials, contract, chain) into the submission template. Fields the protocol doesn't capture yet (circulating- supply URL, LP-lock status) stay blank for you to complete by hand.

App publishing (`chaindaddy app …`)

Build an app for token pages: a widget (a React component the page renders), a headless runner (a web service that receives signed events), or both.

chaindaddy login                                # once per computer, in your browser; no API key to create
chaindaddy app init widget my-widget            # widget | headless | full | godot | unity | web
cd my-widget
npm install                                     # a widget or runner; an engine project has nothing to install
chaindaddy app dev                              # see it on a token page on your own machine
chaindaddy app build                            # a widget; an engine project is the engine's own export
chaindaddy app scan && chaindaddy app pack && chaindaddy app sign --in-place && chaindaddy app submit --watch
chaindaddy app request-publish <submission id>  # once the automatic checks pass

The commands are the same in every kind of project. app init godot and app init unity write the manifest's engine block, the files that let the game talk to the page (godot/chaindaddy.gd, godot/saves.gd; unity/Assets/Plugins/WebGL/ChainDaddy.jslib, unity/Assets/ChainDaddy.cs) and the export settings to use; --build <folder> copies an export you already have into engine/.

app init names the app after the directory: with the developer id stored at login (or --developer-id), the manifest id is <developer id>/my-widget and the display name My Widget, so --non-interactive needs no other flags. The scaffold installs from public npm packages only.

Command	What it does
`init <widget\|headless\|full\|godot\|unity\|web> [dir]`	Scaffold a project (`--id`, `--name`, `--developer-id`, `--description`, `--category`, `--license`; `--build <folder>` with `godot`, `unity` or `web`)
`validate [dir]`	Check `capp.json` against the manifest schema
`build [dir]`	Bundle `src/index.tsx` into `dist/bundle.js`: one ES module, react and react-dom left to the host
`scan [target]`	Run the server's bundle checks locally (a bundle or a package)
`pack [dir]`	Write `dist/<name>-<version>.capp`
`sign [package]`	Sign a package as your developer account; `--in-place`, else writes `<name>.signed.capp`. After `chaindaddy login` there is no key to create: the first run makes this computer's own
`inspect <package>` / `verify <package>`	Show or check a package's contents and signature
`submit [package]`	Upload a signed package; `--watch` waits for the automatic checks, `--request-review` then sends it to review
`status <id>` / `logs <id>`	A submission's status (`--watch`) or its check log (`--follow`)
`request-publish <id>`	Send a build whose checks passed to review
`list [apps\|submissions]`	Your apps, or every submission across them
`login` / `whoami`	Sign in through the browser, the same as `chaindaddy login` (`--token cd_live_…` stores a key, for CI); show your plan, the program agreement, your developer id and whether this computer can publish, each with its next step
`key create\|list\|rotate\|revoke`	Manage API keys; `rotate` and `revoke` take a key id or prefix, `revoke --force` removes your last key

sign and submit with no path use the newest .capp in ./dist. Every command that reads a package also accepts the older .crown extension.

submit --watch and status --watch exit 0 when the checks pass (or a reviewer approves) and 3 when they fail (or a reviewer rejects).

Test a widget before you submit it: open https://chaindaddy.io/_dev/widgets, choose "Test your own bundle" and load dist/bundle.js. After approval, install the app from the Apps tab on your token page.

Run chaindaddy app <command> --help for every flag.

Creator store (`chaindaddy iap …`)

Sell items for your token, give rewards and manage what users hold. A Developer plan (or the Developer Beta program) is required.

chaindaddy iap store open --page FLUXGP          # the token page: its symbol or its address (or --chain base --crown 8)
chaindaddy iap sku create <store> --file badge-gold.json
chaindaddy iap key create <store> --name app-server --scope orders:write entitlements:write
chaindaddy iap order create <store> --sku badge.gold --wallet 0x… --key cd_iap_…
chaindaddy iap consume <store> --wallet 0x… --sku credits --qty 1 --idempotency-key job-7-credit
chaindaddy iap events <store> --follow --json
chaindaddy iap webhook set <store> --url https://app.example/hooks/store --event order.confirmed
chaindaddy iap webhook show <store>

iap webhook {set|show|test|rotate|delete} manages the one HTTPS endpoint a store sends its events to. set prints a new webhook's whsec_… secret once; each delivery carries X-Webhook-Signature, the hex HMAC-SHA256 of the raw body keyed with it. show lists the last 20 deliveries.

Your server needs only its store key (CHAINDADDY_IAP_KEY or --key): store routes do not use the cd_live_ gate key. Every POST sends an Idempotency-Key (--idempotency-key, or generated and printed as idempotencyKey with --json), so a retry never grants or sells twice. Guide: https://docs.chaindaddy.io/developer/store-and-rewards.

Token prizes (`chaindaddy airdrop …`)

A prize pool funded from your own wallet that your game server pays winners from, in your token. The winner signs nothing.

chaindaddy airdrop create --chain base --crown 8 --name "Season 1" --budget-tokens 10000 --max-award-tokens 500 --max-awards 100 --daily-max-tokens 2000
chaindaddy airdrop key create --campaign <id>   # the one store key that may award from it (secret printed once)
chaindaddy airdrop fund <id>                    # prints the approve to send from your wallet; never signs or sends
chaindaddy airdrop status <id> active
chaindaddy airdrop award <id> --store <store> --wallet 0x… --amount-tokens 500 --idempotency-key race-42:place-1 --wait
chaindaddy airdrop awards <id> --idempotency-key race-42:place-1

award runs on your server with the pinned store key (CHAINDADDY_IAP_KEY). The same --idempotency-key and body replays the award instead of paying twice; a failed award keeps its key, so retry it with a new one. --wait exits 0 once confirmed, 5 if it failed, 2 if it is still going when --timeout ends. Every amount flag takes base units, or whole tokens with its -tokens twin.

Agent / CI usage

Pass --json for machine-readable output and --non-interactive to fail fast instead of prompting.
Authenticate entirely from the environment (CROWN_API_KEY / CHAINDADDY_API_KEY) — no stdin, no login step required.
API errors surface as { code, message, status, requestId } with deterministic exit codes (see src/lib/exitcodes.ts).
Anything that needs a wallet takes --signer walletconnect|browser|ledger|trezor|keystore|external (or the default chaindaddy signer use remembered). Unattended, each signer prints one {"sign_request": {...}} line on stderr for the agent to pass to its human, and waits up to --sign-timeout seconds. See "Signing" in the CLI docs.

Development

npm install        # install deps (Node 20+)
npm run build      # tsc → dist/ (+ copy schema)
npm run typecheck  # tsc --noEmit
npm test           # build + package round-trip tests
npm link           # symlink the `chaindaddy` bin for local use