Watch-only is a capability boundary, not a custody model: the wallet knows public keys, scripts or output descriptors but has no signing secret for them. It may calculate balances and construct a PSBT, yet a separate signer must authorize every spend. Removing keys from the online coordinator limits remote theft; it does not make its balances, addresses, fee choices or transaction proposals trustworthy.
A watch-only wallet can recognize outputs matching scripts it knows, follow confirmations, calculate a wallet-relative balance and assemble transactions from those UTXOs. It cannot demonstrate that its operator controls the corresponding private keys, sign a spend or guarantee that its backend reports the best valid chain. “Balance” therefore means the sum found for the imported watch set at the coordinator’s current chain tip; it is not proof of solvency or custody. A single-address explorer and a descriptor wallet are both watch-only in a broad sense, but they provide radically different coverage. [Bitcoin Core RPC — createwallet] [Bitcoin Core RPC — importdescriptors]
Importing one address watches exactly that script and cannot derive the next receive address or the wallet’s change. Importing a bare public key may cover several encodings only if software explicitly expands them. An account xpub can derive non-hardened descendants, but it does not by itself state whether the wallet uses P2PKH, nested SegWit, native SegWit or Taproot, which branch is change, or which multisig threshold applies. A descriptor encodes that missing policy. Export watch data from the signer’s documented account, network and script type; do not reconstruct it by guessing a derivation path. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 380 — Output Script Descriptors] [Bitcoin Core — Output Descriptors]
BIP380 defines descriptors as a language for sets of output scripts. A form such as wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum names the script template, master fingerprint, origin path, public account key, external branch, wildcard and checksum. Taproot uses tr() under BIP386; multipath expressions under BIP389 can express receive and change alternatives. The checksum detects transcription errors but does not authenticate who supplied the descriptor. A descriptor containing only public keys remains watch-only; one containing an xprv is not and must never be placed on the online coordinator. [BIP 380 — Output Script Descriptors] [BIP 386 — tr() Output Script Descriptors] [BIP 389 — Multipath Descriptor Key Expressions] [Bitcoin Core — Output Descriptors]
HD wallets normally separate external receive addresses from internal change, commonly branches /0/* and /1/*. If the watch-only copy lacks the internal descriptor, a spend can appear to lose its change; if next_index or the derivation range lags behind the signer, new deposits can disappear from the displayed balance. Conversely, letting two coordinators hand out addresses without sharing index state can cause reuse and confusing histories. Keep the active descriptors, range and next index aligned, and verify every receiving address on the signing device because malware can replace an address while still showing a plausible wallet balance. [BIP 389 — Multipath Descriptor Key Expressions] [Bitcoin Core RPC — importdescriptors]
Bitcoin Core importdescriptors requires a timestamp that controls where rescanning starts; “now” skips old history, while 0 requests a scan from genesis. Ranged descriptors also need sufficient range and an active/internal role. A timestamp that is too recent, an exhausted range, an omitted change branch or unavailable historical blocks on a pruned backend can yield an incomplete wallet without any key loss. Rescanning is discovery, not recovery of secrets. Record the wallet’s creation height or earliest-use date and validate restoration against known transactions and addresses rather than trusting a zero balance. [Bitcoin Core RPC — importdescriptors] [Bitcoin Core — Offline Signing Tutorial]
The coordinator selects UTXOs, destinations, fee rate and change, then packages the proposal as a PSBT. BIP174 carries previous outputs, scripts and derivation metadata so an offline or hardware signer can verify and sign without its own UTXO database. This division does not entitle the coordinator to be trusted: before signing, inspect each destination, amount, fee, sighash and change on the signer’s trusted display. After signatures return, the coordinator can finalize and broadcast, but should first ensure the extracted transaction matches the reviewed proposal and policy. [BIP 174 — Partially Signed Bitcoin Transaction Format] [Bitcoin Core — Offline Signing Tutorial]
An xpub cannot normally sign, but it can reveal every non-hardened public descendant in its branch. Anyone who receives it—portfolio service, merchant server, coordinator, cloud backup or attacker—may cluster past and future addresses, balances, payment timing and change. Querying a third-party server can disclose the same watch set even without uploading the xpub. Prefer your own full node or privacy-preserving connection, segregate accounts before export, minimize copies and treat descriptors and wallet labels as sensitive operational data rather than harmless public information. [BIP 32 — Hierarchical Deterministic Wallets] [Bitcoin Optech — Output Script Descriptors] [Sparrow Wallet — Quick Start Guide]
BIP32 permits public derivation only for non-hardened children. It also states a critical exception: a parent extended public key plus any descendant non-hardened private key is enough to recover the parent private key, compromising that entire branch. This is not an attack from the xpub alone, but it makes mixtures of exported xpubs and individually leaked child secrets dangerous. Hardened derivation above the exported account boundary limits the damage to that account. Never import an xprv into a watcher, and do not use a watch-only database as a casual store for seed, private-key or PSBT secrets. [BIP 32 — Hierarchical Deterministic Wallets]
For multisig, the watcher needs the threshold, script type, every cosigner xpub, key origins, ordering and receive/change derivation—not merely the local signer’s xpub. Bitcoin Core’s multisig tutorial constructs a watch-only descriptor wallet from the cosigners and uses it to create PSBTs. Losing the descriptor can leave all seeds intact yet make reconstruction error-prone; a wrong key order or script wrapper derives different addresses. Verify the registered policy and a sample address on every signer, retain a checksummed descriptor or standardized wallet configuration, and remember that the public configuration exposes all cosigners’ transaction graph. [BIP 380 — Output Script Descriptors] [Bitcoin Core — Multisig Tutorial]
Back up the receive and change descriptors, origin information, network, birthday/height, range state, labels and multisig policy separately from private keys. BIP329 can transfer labels, but labels do not replace descriptors or transaction history. Perform a restoration drill on an isolated profile or test network: import public configuration, rescan from the recorded point, match several old receive and change addresses, reproduce the expected UTXO set, create a PSBT, sign it on the real signer and verify the final transaction before broadcast. Reconcile periodically; a watch-only wallet is an observability and coordination tool, not the ultimate source of spend authority. [BIP 329 — Wallet Labels Export Format] [Bitcoin Core RPC — importdescriptors] [Electrum — Cold Storage]
For the clearest picture, read this entry together with Extended Public Key (xpub), Bitcoin wallet, Cold Storage, Output Descriptor, PSBT, Bitcoin. The reverse links also lead from HD Wallet, Cold Storage, Extended Public Key (xpub), Output Descriptor.