Evaluation stack (Docker Compose)

Local / evaluation only. This is not a production setup. Everything here runs on one machine. Each OpenBao is a single node that unseals itself from a key on the same volume. The engine and the signer share a volume and a network. A production deployment runs the engine and the signer on separate hosts. It uses three-node OpenBao clusters with KMS auto-unseal, and the signer host accepts no inbound connections. See Production architecture.

Your keys never live on Citadel. Three components run on your infrastructure, and each one dials out to the platform. Nothing in the stack publishes a port.

Component	Holds	Job
`openbao` + `bao-init`	the wallet seed, born inside the vault	signs digests for the signer
`openbao-engine` + `bao-init-engine`	three ed25519 keys: `engine`, `request` (key A), `policy` (key B)	signs the engine’s verdicts and your policy document
`policy-engine`	your policy document and counters (`/state/journal.db`)	approves or refuses every keygen and sign request
`signer`	no keys; a pinned copy of the engine’s public key	checks each verdict, then asks OpenBao to sign

The commands and log lines below were captured on a test organization, Northwind Pay. Tokens and pairing codes are masked. Platform addresses are replaced with placeholders: https://api.citadel.example for the API and nats://… for NATS.

To have a coding agent do this bring-up, give it the merchant stack setup skill.

Start the stack

Fill .env and run docker compose up.

Confirm the engine's keys

TrustedKeys move from Pending to Confirmed.

Check the signer pairing

The signer pins the engine’s key.

Sign and publish the policy

Use key B, then run check-policy.

Derive the first wallet

This proves the whole path.

Before you start

Your organization exists and is provisioned: an owner has clicked Provision tenant in Settings → Signer onboarding → Connect the org, and the panel shows a Tenant account org-….
You have a join token. It is shown once and looks like ojt_…: either the one Citadel gave you with the organization, or one an owner minted with Mint join token in the same panel. A token can be redeemed once by the engine and once by the signer. It expires after 24 hours.
You have the platform’s API URL and NATS URL.
Docker with Compose v2.
The three images, all with the same <version> tag, pulled from the registry Citadel gives you: <registry>/citadel-openbao:<version> (OpenBao with the Citadel plugin), <registry>/citadel-policy-engine:<version> and <registry>/citadel-signer:<version>.
xxd and openssl, or python3, to hash the engine’s public keys in step 2.
On a machine that already runs another merchant stack, give this one its own Compose project name (-p merchant-<slug>) and its own .env. Two projects never share volumes.

This stack uses CITADEL_UNSEAL_MODE=demo: 1-of-1 unseal shares kept on the same volume, auto-unseal, no custodians, and a seed without break-glass shares. Anyone who reads the volume owns the seed. Never fund wallets you derive here with real money.

1. Start the stack

Create a directory for this merchant with an .env file:

.env

CITADEL_API=https://api.citadel.example
CITADEL_JOIN_TOKEN=ojt_…
# Set it when the NATS URL in the join response is not reachable from your containers.
NATS_URL=nats://…

Next to .env, put compose.yml and engine-policy.hcl from below. bao-init gives its token the policy in /openbao/signer-policy.hcl, which reaches only keys/org. On the engine’s OpenBao, engine-policy.hcl is mounted over that file so the engine’s token can create and use its three keys.

compose.yml — two OpenBao instances, engine keys in its own vault

compose.yml

# Paths are relative to this file, in the merchant directory next to .env.
name: merchant-northwind

x-openbao: &openbao
  image: <registry>/citadel-openbao:<version>

services:
  # the wallet seed
  openbao:
    <<: *openbao
    restart: unless-stopped
    command: ["server"]
    cap_add: [IPC_LOCK]
    volumes: [openbao-data:/openbao/data]
    healthcheck:
      test: ["CMD", "bao", "status", "-address=http://openbao:8200"]
      interval: 5s
      timeout: 3s
      retries: 60
      start_period: 5s

  bao-init:
    <<: *openbao
    restart: unless-stopped
    user: root
    entrypoint: ["/bin/sh", "/usr/local/bin/bao-init.sh"]
    environment:
      BAO_ADDR: http://openbao:8200
      STATE_DIR: /state
      CITADEL_UNSEAL_MODE: demo
    volumes: [merchant-state:/state]
    depends_on: { openbao: { condition: service_started } }
    healthcheck:
      test: ["CMD", "test", "-f", "/state/bao.token"]
      interval: 3s
      timeout: 2s
      retries: 100
      start_period: 5s

  # the engine's keys: engine (verdicts), request (A), policy (B)
  openbao-engine:
    <<: *openbao
    restart: unless-stopped
    command: ["server"]
    cap_add: [IPC_LOCK]
    volumes: [openbao-engine-data:/openbao/data]
    healthcheck:
      test: ["CMD", "bao", "status", "-address=http://openbao-engine:8200"]
      interval: 5s
      timeout: 3s
      retries: 60
      start_period: 5s

  bao-init-engine:
    <<: *openbao
    restart: unless-stopped
    user: root
    entrypoint: ["/bin/sh", "/usr/local/bin/bao-init.sh"]
    environment:
      BAO_ADDR: http://openbao-engine:8200
      STATE_DIR: /engine
      CITADEL_UNSEAL_MODE: demo
    volumes:
      - engine-state:/engine
      # the engine's token policy replaces the signer's on THIS vault
      - ./engine-policy.hcl:/openbao/signer-policy.hcl:ro
    depends_on: { openbao-engine: { condition: service_started } }
    healthcheck:
      test: ["CMD", "test", "-f", "/engine/bao.token"]
      interval: 3s
      timeout: 2s
      retries: 100
      start_period: 5s

  policy-engine:
    image: <registry>/citadel-policy-engine:<version>
    restart: unless-stopped
    environment:
      CITADEL_API: ${CITADEL_API:?set CITADEL_API in .env}
      CITADEL_JOIN_TOKEN: ${CITADEL_JOIN_TOKEN:?set CITADEL_JOIN_TOKEN in .env}
      ENGINE_STATE_DIR: /state
      PAIRING_CODE_FILE: /state/pairing-code
      ENGINE_HTTP_ADDR: ":9800"
      ENGINE_PUBLIC_URL: http://policy-engine:9800
      NATS_URL: ${NATS_URL:-}
      BAO_ADDR: http://openbao-engine:8200
      BAO_TOKEN_FILE: /engine/bao.token
      POLICY_JOURNAL: /state/journal.db
    volumes:
      - merchant-state:/state
      - engine-state:/engine:ro
    depends_on:
      bao-init-engine: { condition: service_healthy }
      bao-init: { condition: service_healthy }

  signer:
    image: <registry>/citadel-signer:<version>
    restart: unless-stopped
    command: ["up"]
    environment:
      CITADEL_API: ${CITADEL_API:?set CITADEL_API in .env}
      CITADEL_JOIN_TOKEN: ${CITADEL_JOIN_TOKEN:?set CITADEL_JOIN_TOKEN in .env}
      ENGINE_URL: http://policy-engine:9800
      PAIRING_CODE_FILE: /state/pairing-code
      BAO_ADDR: http://openbao:8200
      BAO_TOKEN_FILE: /state/bao.token
      SIGNER_STATE_DIR: /state/signer
      NATS_URL: ${NATS_URL:-}
    volumes: [merchant-state:/state]
    depends_on:
      openbao: { condition: service_healthy }
      bao-init: { condition: service_healthy }
      policy-engine: { condition: service_started }

volumes:
  merchant-state:
  openbao-data:
  openbao-engine-data:
  engine-state:

engine-policy.hcl

# The policy engine's token on ITS OpenBao: create and use its three ed25519 keys
# (engine = verdicts, request = key A, policy = key B). Nothing else.
path "multichainsign/keys/engine"         { capabilities = ["create", "update", "read"] }
path "multichainsign/keys/request"        { capabilities = ["create", "update", "read"] }
path "multichainsign/keys/policy"         { capabilities = ["create", "update", "read"] }
path "multichainsign/keys/+/pubkey"       { capabilities = ["update"] }
path "multichainsign/keys/+/sign"         { capabilities = ["update"] }

Every Compose command for this merchant carries the same project name, env file and compose file. Run them from the merchant directory:

dc() { docker compose -p merchant-northwind --env-file .env -f compose.yml "$@"; }
dc up -d

 Container merchant-northwind-bao-init-engine-1  Healthy
 Container merchant-northwind-bao-init-1  Healthy
 Container merchant-northwind-policy-engine-1  Started
 Container merchant-northwind-openbao-1  Healthy
 Container merchant-northwind-signer-1  Started

On first boot, with no operator involved:

bao-init and bao-init-engine each initialize and unseal their OpenBao, mount multichainsign, and write a token: /state/bao.token for the signer and /engine/bao.token for the engine. bao-init also creates the seed key org.
policy-engine creates engine, request and policy inside openbao-engine. It then redeems the join token with the three public halves and writes /state/state.json and the pairing code.
signer redeems the join token, waits for the pairing code, pins the engine key, checks that multichainsign/keys/org exists, and starts serving on NATS.

The engine’s log shows the join and the three public keys:

dc logs policy-engine

{"level":"INFO","msg":"joining the platform","api":"https://api.citadel.example","engine_url":"http://policy-engine:9800"}
{"level":"INFO","msg":"joined","org":"org-1f34b7e2fb96","org_id":"1f34b7e2-fb96-4bae-b685-0d153e4c6a71","nats_url":"nats://…","creds":false,"state":"/state/state.json"}
{"level":"INFO","msg":"engine verification key (signer pins this)","pub":"6313b9fab7ab5de7b9e88b1313a748ab7b11b477d6c4addc21b87f74dabf2731","fingerprint":"0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72"}
{"level":"INFO","msg":"request key A (the backend signs intents with it; platform registered)","pub":"207a6f4b9b910913b1d37dc1356641142fdf16d4b943a74c2157ef5358b778d0"}
{"level":"INFO","msg":"policy key B (signs the policy document; platform registered)","pub":"8db738ffad2cb5f04f0664f51b94488cc7e080b0e6d6cbdee7da44ebe3fde595"}
{"level":"INFO","msg":"pairing code: ••••••••••••••••••••","valid_for":"15m0s","endpoint":"http://policy-engine:9800/pairing/verification-key","file":"/state/pairing-code"}
{"level":"WARN","msg":"no policy document yet — every payout will be refused until the console publishes one"}
{"level":"INFO","msg":"policy engine ready","chains":["solana/v1","tron/v1","evm/v1","ton/v1","ton/v2"],"org":"org-1f34b7e2fb96", …}

The WARN line is expected. The engine refuses everything until step 4.

2. Confirm the engine’s keys

After the join, Settings → Signer onboarding marks Run the policy engine and Connect the org as done. Settings → Policy engine lists three trust anchors as Pending: the engine’s verification key, request key A and policy key B. Check each fingerprint against the engine’s log before you confirm it. The fingerprint is the SHA-256 of the 32 raw key bytes, in groups of four hex characters. The engine, the signer and the console print the same string. For the engine’s verification key, compare the console with the fingerprint field of the engine verification key line above: 0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72. The engine logs keys A and B as hex only. Hash their raw bytes:

fp() { printf '%s' "$1" | xxd -r -p | openssl dgst -sha256 -r | cut -c1-64 | sed 's/..../& /g; s/ $//'; }
# without xxd/openssl:
# fp() { python3 -c 'import sys,hashlib;h=hashlib.sha256(bytes.fromhex(sys.argv[1])).hexdigest();print(" ".join(h[i:i+4] for i in range(0,64,4)))' "$1"; }
fp 207a6f4b9b910913b1d37dc1356641142fdf16d4b943a74c2157ef5358b778d0   # key A
fp 8db738ffad2cb5f04f0664f51b94488cc7e080b0e6d6cbdee7da44ebe3fde595   # key B

24f6 e7dc 2e4c ebff b597 312f a815 d4e4 fd3b e377 7bf5 9918 023a 739f 12cb 8c6d
b0af 9544 a96f 2e5e 29eb 8f10 1091 063b 1cab cd2e 86c3 0cfc 2569 b2fc bb63 be5e

These match 0601 cde4 …, 24f6 e7dc … and b0af 9544 … in the console. Click Confirm on each key. The page then reads 3 of 3 confirmed.

3. Check the signer pairing

The signer gets the pairing code through the shared /state volume, fetches the engine’s key from http://policy-engine:9800, and pins it once:

dc logs signer

level=INFO msg=connected org=org-1f34b7e2fb96 org_id=1f34b7e2-fb96-4bae-b685-0d153e4c6a71 nats_url=nats://… engine_url="" nats_creds=false
level=INFO msg="waiting for pairing code" file=/state/pairing-code
level=INFO msg="engine key pinned" fingerprint="0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72" engine_url=http://policy-engine:9800
level=INFO msg="bao key present" mount=multichainsign key=org
level=INFO msg=serving org=org-1f34b7e2fb96 sign=citadel.org-1f34b7e2fb96.signer.sign derive=citadel.org-1f34b7e2fb96.signer.derive engine_key="0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72" nats=nats://…
level=INFO msg="nats connected" server=nats://…

Pairing over the shared volume and the engine’s HTTP port is an evaluation shortcut. The signer can also pin the engine’s key directly: start it with --pe-public-key <hex> (or PE_PUBLIC_KEY), the hex key the engine logs on first boot. No pairing code is needed then. In production the signer never talks to the engine and pins only that way. See Pairing without a connection.

The fingerprint the signer pinned must be the engine key’s fingerprint from the engine’s log and from Settings → Policy engine. Any other value means the signer pinned a key that is not your engine’s. Stop and see Re-pair the signer with a new engine key.

The platform sees the pairing only after the first wallet

Pairing happens between your engine and your signer, inside your network. The platform has no direct signal for it. It learns of the pairing from the first derived wallet, because the signer derives nothing until it has pinned the engine key. Until step 5:

Settings → Signer onboarding → Pair signer with engine reads on your side. Run the signer reads Next and Derive the first wallet reads waiting: the platform sees the signer only through the first wallet too. Onboarding reads 2 of 5, the engine and the org connection.
Settings → Policy engine → Signer → Engine key reads pinned on your side.

After the first wallet in step 5, the step reads Done, Onboarding reads 5 of 5, and the engine key row reads pinned. The panel shows citadel-signer pair --engine … --code <pairing-code>. With this compose file you do not run it: the signer reads the code from /state/pairing-code and pairs on its own. Check the pairing on your side, in the signer’s log. One of these lines with a fingerprint means the signer is paired:

dc logs signer | grep -E 'engine key (already )?pinned'

signer-1  | level=INFO msg="engine key pinned" fingerprint="0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72" engine_url=http://policy-engine:9800
signer-1  | level=INFO msg="engine key already pinned" fingerprint="0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72"

engine key pinned appears once, on the first boot. Every later boot prints engine key already pinned. If neither line is there, see Troubleshooting, Signer stuck on waiting for pairing code. A wallet issued in step 5 also proves the pairing: the signer starts serving signer.derive only after it has pinned the engine key.

4. Sign and publish the policy

The engine refuses every payout until a policy document signed by key B is in force. Open Settings → Policy document. Add rules for at least one network. Here, TRON recognises its native coin TRX/6 with a ceiling of 100 TRX per transaction. Click Save draft v1, then v1.yaml to download policy-v1.yaml:

policy-v1.yaml

---
ceiling:
  TRX/6: '100000000'
chains:
  tron:
    assets:
      native: TRX/6
    chain_module_version: 1
    wallets: {}
    whitelist: []
references: {}
version: 1

Sign it with key B inside openbao-engine. The key never leaves the vault. Flags come before the file name; with the file first, the command only prints its usage line.

dc cp policy-v1.yaml policy-engine:/state/policy-v1.yaml
dc exec policy-engine /citadel policy-engine sign-policy \
  --bao-addr http://openbao-engine:8200 --bao-token-file /engine/bao.token /state/policy-v1.yaml

signed /state/policy-v1.yaml with policy key B 8db738ffad2cb5f0…
signature (paste into Console → Policies → Publish):
6c7bd04216ff22add7129ab66f02d9ed4892ba9a8999abbb40f4306ecb77b21f46a9f948b016fde9e03eaba1bbe74407b81212648f3289add154720a3c020a0c
bootstrap wrapper written: /state/policy-v1.signed.json

Paste the signature and click Publish v1. The console checks it against the confirmed key B and sends the document to the engine. The page then reads v1 in force. The engine logs {"level":"INFO","msg":"policy document accepted","org":"org-1f34b7e2fb96"}. Read back what is in force:

dc exec policy-engine /citadel policy-engine check-policy --engine http://policy-engine:9800

POLICY DOCUMENT  version 1
  request signing   required   (key A required for external destinations)
  chains ruled      tron
  owned wallets     0 (from keygen)
  unregistered refs false

NATIVE COINS
  tron                                           TRX/6

ASSETS  (contract → limit key)
  —

WHITELIST  (external recipients allowed without key A)
  — none: every external destination needs a merchant-signed request

CEILING  (per transaction, base units)
  TRX/6                                          100000000

WALLET LIMITS  (max / window)
  —

REFERENCE LIMITS  (max / window)
  —

5. Derive the first wallet

In the header, select the network your policy covers. Open Vaults and wallets → Issue wallet → New vault and create Payouts (Hot). The dialog returns to Issue wallet. Pick the vault Payouts, the network TRON, fill Identifier (payouts-tron) and End user (treasury), and click Issue. Issue stays disabled until a vault is picked and both fields are filled. The request travels from the console to the engine (policy.keygen) and then to the signer (signer.derive). OpenBao derives the address from the seed, and the engine records the wallet as owned:

policy-engine-1  | {"level":"INFO","msg":"authorized and forwarded","org":"org-1f34b7e2fb96","kind":"keygen","subject":"citadel.org-1f34b7e2fb96.signer.derive"}
signer-1         | level=INFO msg="signer.derive derived" correlation_id=derive:1c36605b-… wallet_id=1c36605b-af95-42b0-8141-968327a400ba
policy-engine-1  | {"level":"INFO","msg":"derived and registered","org":"org-1f34b7e2fb96","wallet_id":"1c36605b-af95-42b0-8141-968327a400ba","family":"tron","address":"TFX5DeqTsNNHgi17GvrWjmkUA2yxcLRG8D"}

The wallet appears in the Payouts vault. Onboarding reads 5 of 5: the derived wallet marks Pair signer with engine as done, and Settings → Policy engine → Signer → Engine key reads pinned. See step 3.

Check that everything works

Check	Where	Expected
All containers up	`dc ps`	`openbao`, `openbao-engine`, `bao-init*` healthy; `policy-engine`, `signer` up, not restarting
Engine joined	`dc logs policy-engine`	`joined` once, then `tenant from join state` on every later boot
Keys trusted	Settings → Policy engine	3 of 3 confirmed, fingerprints match the engine log and the hashes in step 2
Signer paired	`dc logs signer`, Onboarding	`engine key pinned` once, then `engine key already pinned`, then `serving`, with the engine key’s fingerprint; Onboarding 5 of 5 after the first wallet
Policy in force	`check-policy`, Settings → Policy document	version N, `v1 in force`
Path works	Vaults and wallets	a wallet issued, `derived and registered` in the engine log

Restarting is safe

A restart never joins, pairs or creates keys again:

dc restart policy-engine signer
dc logs --since 10s policy-engine signer

signer-1         | level=INFO msg="already connected" org=org-1f34b7e2fb96
signer-1         | level=INFO msg="engine key already pinned" fingerprint="0601 cde4 4039 95e2 e3d2 cb84 5cd4 8918 df78 073c 3003 5f64 076a 04f4 ba4f 0d72"
signer-1         | level=INFO msg="bao key present" mount=multichainsign key=org
policy-engine-1  | {"level":"INFO","msg":"tenant from join state","org":"org-1f34b7e2fb96","org_id":"1f34b7e2-fb96-4bae-b685-0d153e4c6a71"}
policy-engine-1  | {"level":"INFO","msg":"owned wallets loaded","count":1}
policy-engine-1  | {"level":"INFO","msg":"policy document loaded","version":1,"source":"journal"}

The join token in .env is not used again once /state/state.json and /state/signer/state.json exist.

What lives where

Volume	Path	Contents
`openbao-data`	`/openbao/data`	the wallet seed, barrier-encrypted
`openbao-engine-data`	`/openbao/data`	the engine’s keys: verification, A, B
`engine-state`	`/engine/bao.token`, `/engine/openbao.json`	the engine’s OpenBao token, plus the demo unseal key
`merchant-state`	`/state/openbao.json`, `/state/bao.token`	the seed vault’s demo unseal key and root token; the signer’s scoped token
	`/state/state.json`, `/state/journal.db`	engine join state; the policy in force, counters, owned wallets
	`/state/pairing-code`	one-time code, engine → signer, valid 15 minutes
	`/state/signer/state.json`, `/state/signer/engine-key.json`	signer join state; the pinned engine key

Troubleshooting

policy-engine restarts with ensure key engine: bao 403 permission denied

The engine’s token carries the signer’s policy, which allows only keys/org. Mount engine-policy.hcl over /openbao/signer-policy.hcl in bao-init-engine, then run dc up -d bao-init-engine. The sidecar rewrites the policy on start, the existing token picks it up, and the engine recovers on its next restart. No join is spent on this failure, because the keys are checked before the join.

Engine log: join token unknown, expired, or already used by this engine

One of two causes:

the token is older than 24 hours;
an engine has already redeemed it.

Mint a new token in Onboarding → Connect the org, put it in .env, and run dc up -d. A component with saved state never reads the token again.

Engine log: answered 422: not_provisioned; signer: discovery: http 422

The organization has no tenant account yet. Both containers restart in a loop:

policy-engine-1  | {"level":"ERROR","msg":"tenant","err":"join: https://api.citadel.example/join/engine answered 422: {\"error\":\"not_provisioned\"}"}
signer-1         | level=ERROR msg="discovery: http 422 (token spent or expired?)"

The refusal does not spend the token: Onboarding → Connect the org still shows it as token live. Click Provision tenant there. Both containers join with the same token on their next restart; nothing in .env changes.

Signer stuck on waiting for pairing code

The engine has not written /state/pairing-code. Check dc logs policy-engine. The code is valid for 15 minutes from the engine’s boot. If it expired, run dc restart policy-engine to print a fresh code.

Signer: nats connect fails

The join response carries a NATS URL your containers cannot reach. Set NATS_URL in .env to the NATS address you were given, then dc up -d.

Engine refuses every payout: no policy document

Nothing is in force. Sign and publish as in step 4. Then run check-policy.

Re-pair the signer with a new engine key

pair refuses a key different from the pinned one. Delete /state/signer/engine-key.json by hand, then restart the signer within 15 minutes of an engine boot. If more time has passed, restart the engine as well. Re-check the fingerprint.

Start over

To throw this merchant away, drop every volume of this project. That deletes both vaults: the seed and the engine’s keys.

docker volume ls --filter label=com.docker.compose.project=merchant-northwind --format '{{.Name}}'

merchant-northwind_engine-state
merchant-northwind_merchant-state
merchant-northwind_openbao-data
merchant-northwind_openbao-engine-data

dc down -v

Then start again from step 1 with a new join token. A down without -v keeps the state. The next up then rejoins nothing. That is the restart path, not a new merchant.

down -v destroys the seed. There is no import and no recovery from words. In demo mode there are no break-glass shares either.

Get started

Merchant stack

Conventions

Notifications

Policy

Evaluation stack (Docker Compose)

Before you start

1. Start the stack

2. Confirm the engine’s keys

3. Check the signer pairing

The platform sees the pairing only after the first wallet

4. Sign and publish the policy

5. Derive the first wallet

Check that everything works

Restarting is safe

What lives where

Troubleshooting

Start over

​Before you start

​1. Start the stack

​2. Confirm the engine’s keys

​3. Check the signer pairing

​The platform sees the pairing only after the first wallet

​4. Sign and publish the policy

​5. Derive the first wallet

​Check that everything works

​Restarting is safe

​What lives where

​Troubleshooting

​Start over

Before you start

1. Start the stack

2. Confirm the engine’s keys

3. Check the signer pairing

The platform sees the pairing only after the first wallet

4. Sign and publish the policy

5. Derive the first wallet

Check that everything works

Restarting is safe

What lives where

Troubleshooting

Start over