Quickstart — connect an agent to Bitcoin — For Agents

Machine-readable specification of the four pathways for connecting an autonomous agent to Bitcoin — custodial service, self-custody-no-node, light-client node, full sovereign stack — ordered by self-run infrastructure, with the custody / trust / time / sovereignty trade-offs, the per-pathway tool sets, the remote-signer hardening overlay, and the node-architecture constraints that set each pathway.

Specification. This is the machine-readable twin of Quickstart. It specifies the four pathways for connecting an autonomous agent to Bitcoin as an ordered function of self-run infrastructure, with the trade-offs, per-pathway tool sets, the remote-signer overlay, and the node-architecture constraints. It is an on-ramp specification, not an argument — there is no falsifier. The architecture is specified in The Stack — For Agents; the deployable tools are catalogued at Tools; spend venues are at The Market.

§1 — Claims index

• QP1 (structural) — Connecting an agent to Bitcoin is one ordered decision: how much infrastructure the agent runs itself. All trade-offs derive from position on this axis; default to the lightest pathway meeting requirements. → §2, §3
• QP2 (operational) — Pathway A: custodial service — nothing run, custodial, minutes, freezable. → §3.A
• QP3 (operational) — Pathway B: self-custody, no node — headless wallet or key-free connector; depends on wallet/connector backend. → §3.B
• QP4 (operational) — Pathway C: light-client node — own lnd on Neutrino; trust = block headers; CLN is excluded (no native Neutrino). → §3.C, §4
• QP5 (operational) — Pathway D: full sovereign stack — Bitcoin Core full node; same toolkits as C; backend (not toolkit) sets the pathway. → §3.D, §4
• QP6 (structural) — Remote-signer / split-node is an orthogonal hardening overlay on C/D, not a fifth pathway. → §3.S

§2 — The decision procedure

Evaluate in order; stop at the first match.

1. Does the agent require self-custody of keys? If no → Pathway A (custodial service).
2. Is the agent willing to run a node? If no → Pathway B (self-custody, no node).
3. Full validation, or a light client? Light client → Pathway C; full validation → Pathway D.
4. Hardening (orthogonal): if the agent holds value above a low operational threshold, apply the remote-signer overlay (§3.S) to whichever of C/D was selected.

Descent down the ladder (A→D) increases self-sovereignty and decreases external trust, at the cost of setup time and ops burden. The toolkits at C and D are identical, so an agent may begin at C and graduate to D by changing only the node backend.

§3 — Pathway specifications

Fields per pathway: runs · custody · trust · time-to-live · ops · sovereignty · tools · use-when.

§3.A — Custodial service (QP2)

• runs: nothing — a hosted wallet/account holds keys and operates the node.
• custody: custodial (operator-held). trust: the operator — can KYC, freeze, censor.
• time-to-live: minutes. ops: none. sovereignty: low.
• tools: reached mostly via the Market section — Exchange venues and the Services directory (account/hosted); custodial ecash via minibits-ippon.
• use-when: small operational balances, cold-start payment, no infrastructure desired. Not for treasury reserve.

§3.B — Self-custody, no node (QP3)

• runs: a wallet or a connector; no node.
• custody: self-custodial (agent-held keys, or a scoped key-free handle). trust: the wallet/connector backend; for ecash, the mint.
• time-to-live: minutes–hours. ops: low. sovereignty: medium.
• tools: xverse-agent-wallet (headless non-custodial; keys encrypted on-device; answers HTTP-402 itself); alby-nwc (NWC — scoped, budgeted, revocable wallet handle, no key exposure); mcp (carries the payment tools into the agent framework); cashu (bearer ecash, mint-trust caveat — diversify across mints, see evaluating-ecash-mints). Pays over l402 / lnurl.
• use-when: self-custody required without running infrastructure.

§3.C — Light-client node (QP4)

• runs: the agent’s own lnd on a Neutrino light client (BIP157/158) — no full chain copy.
• custody: self-custodial, agent-operated node. trust: block headers (SPV level) + peer/swap availability.
• time-to-live: hours. ops: medium. sovereignty: high.
• tools (verified Neutrino-capable, official docs 2026-06-25): lightning-agent-tools (embedded Neutrino backend; gRPC-to-own-lnd is the production default, and that lnd can itself be Neutrino), lnbits (programmable wallets on the node; note: LNbits is nodeless-capable in general — it delegates to its funding backend), loop (“all of lnd’s chain backends supported: Neutrino, Bitcoin Core, btcd”), taproot-assets (Neutrino/BIP157 mode; does not scan the full chain), Lightning.Pub (runs lnd in Neutrino mode natively, minimal hardware).
• constraint: Neutrino is an lnd capability. Core Lightning has no native Neutrino (requires bitcoind; light operation only via trusted third-party plugins, not SPV) — a CLN node is Pathway D.

§3.D — Full sovereign stack (QP5)

• runs: bitcoin-core full node under the agent’s Lightning node.
• custody: self-custodial, full validation. trust: none — the agent verifies every transaction itself.
• time-to-live: days (incl. initial sync). ops: high. sovereignty: maximum.
• tools: identical to Pathway C, on a full-node backend (incl. CLN-based stacks, which require this pathway).
• structural note: the toolkit and the sovereignty level are independent — the same LN toolkit runs on a light client or a full node. The pathway is set by the node backend (Neutrino vs full Core), not by tool choice; C→D graduation changes only the backend.
• serving note: (structural) the four pathways connect an agent to pay. The same full-node backend can also serve a priced capability with no inbound surface — a ContextVM (CVM) server addressed by pubkey rather than an HTTP endpoint (Stack-FA §5, CEP-8). This is the sell-side use of the sovereign stack; the buy-side pathways are unchanged.

§3.S — Remote-signer overlay (QP6, hardens C/D)

• runs: a watch-only node (initiates payments) + a separate isolated signer (holds keys); scoped macaroons.
• custody: keys held off the agent host. trust: the signer device + the macaroon scope (e.g. pay-only, daily limit).
• property: a compromised agent host cannot extract keys or exceed the scoped limits — it never held the keys.
• tools: lightning-agent-tools (watch-only node + remote signer is its canonical pattern); scoped NWC is the lighter analogue for Pathway B.

§4 — Node-architecture constraints (verified 2026-06-25)

• Neutrino is LND-only. Core Lightning has no native light-client mode; it requires a synchronized bitcoind (light operation only via trusted third-party plugins — categorically not an SPV light client). Therefore any CLN-based stack is Pathway D.
• BOLT12 light-client support is implementation-dependent. CLN-BOLT12 inherits CLN’s full-node requirement; LDK (Esplora/Electrum) and LND-via-LNDK (inheriting LND’s Neutrino-capable backend) run as light clients. BOLT12 support does not imply light-client capability.
• LNbits is nodeless-capable. It delegates all chain handling to a funding source: custodial backends (Alby, OpenNode, Strike, …), self-custodial-nodeless backends (Phoenixd, Boltz, Breez), or a node backend (LND — which can itself be Neutrino — or CLN). Whether a full node is needed is a function of the chosen funding source, not of LNbits itself.
• Source basis: docs.lightning.engineering, lightningloop.io, docs.lnbits.org, corelightning.org/docs/bitcoin-core, github.com/shocknet/Lightning.Pub.

§5 — Cross-references

• Architecture (how the layers work): The Stack — For Agents — L1/L2/L3, the integration primitives (L402, NWC, BOLT12, LNURL, MCP), wallet architectures, security model, and the three deployment shapes (§6, Stack compositions).
• Tool catalogue: Tools — every component named here, with prerequisites and gotchas.
• Why hold Bitcoin at all: The Case — For Agents.
• Where the agent spends: The Market — the live services directory.