A watch-only wallet gives you a live view of Bitcoin addresses without storing the private keys that authorize spending. That split is useful when you want to monitor balances, reconcile incoming payments or prepare unsigned transactions on an online machine while keeping signing keys elsewhere.
The phrase sounds safer than it is. Watch-only means the wallet cannot hold the relevant private keys. It does not make the machine private, stop address reuse or prove that the data you imported was correct.
What watch-only means
A Bitcoin wallet tracks scripts and transactions that belong to a set of addresses. A signing wallet also has the private-key material needed to authorize a spend. A watch-only wallet keeps the tracking side and leaves the signing authority out.
Bitcoin Core makes that boundary explicit. Its createwallet documentation says that disable_private_keys=true disables the possibility of private keys and allows only watch-only use. The getwalletinfo response reports private_keys_enabled: false for an enforced watch-only wallet.
That is stronger than merely deleting a seed phrase from a normal wallet file. The wallet is created in a mode that refuses private keys.
What it can do
Once the correct address information is imported and the node has scanned the relevant blockchain history, a watch-only wallet can show:
- transactions involving the watched scripts;
- received amounts and unspent outputs known to the wallet;
- confirmations and transaction history;
- the effect of a proposed spend before it is signed elsewhere.
This makes it useful for accounting and operational monitoring. A merchant can watch deposit addresses from an online system. A treasury team can keep a dashboard without placing signing keys on the same server. An individual can check a cold-storage balance without repeatedly connecting the signing device.
The wallet is not an independent source of truth about ownership. It shows activity for the descriptors or addresses you gave it. Import the wrong descriptor, omit a branch or choose an incorrect range, and the view can be incomplete.
Descriptors are the important input
Modern Bitcoin Core wallets use output descriptors. A descriptor states how a wallet derives scripts and addresses. For a deterministic wallet, it can describe a range of addresses instead of requiring a separate import for every address.
That matters for change. Watching only the addresses you have already displayed may miss funds returned to a change address after a spend. A complete setup needs the relevant external and internal descriptor branches, with appropriate ranges and next indexes.
Bitcoin Core’s importdescriptors documentation distinguishes external descriptors from internal ones. An internal descriptor marks matching outputs as not being incoming payments, such as change. The import can also mark a ranged descriptor active and set the next address index.
Treat the descriptor as sensitive operational data even when it contains no private key. An extended public key can reveal a stream of addresses and link activity that would otherwise look unrelated.
The timestamp controls the historical scan
A watch-only wallet cannot display old transactions until the node has looked far enough back.
When importing a descriptor, Bitcoin Core requires a timestamp. It uses that time to decide where the blockchain rescan should begin. The documentation says "now" bypasses historical scanning for outputs known never to have been used, while 0 scans the entire chain. Blocks up to two hours before the earliest supplied timestamp are included, along with the mempool.
An early timestamp is safer for completeness but slower. Bitcoin Core warns that the call can take more than an hour when the timestamp is far in the past. During the scan, the wallet may know that an address exists while related transactions are still missing.
Do not interpret a temporarily low balance as proof that funds are gone while scanning is active. The scanning field in getwalletinfo reports progress, and birthtime records the starting point used for block scanning.
Watch-only is not read-only privacy
Moving private keys off an internet-connected machine reduces one class of risk, but it does not make the monitoring system harmless.
A compromised observer can learn which addresses belong together, when payments arrive and how much a wallet holds. If the system exports data to analytics, alerts or accounting software, those destinations receive the same financial picture. An attacker may also alter what the interface shows, substitute a receiving address or trick an operator into approving a transaction on a separate signer.
Keep access to the monitoring system restricted: its financial data remains valuable even without signing keys.
This is also why a wallet signature should not be treated as a generic login token. Our guide to wallet signatures explains how a valid signature can authorize something different from what a person thinks they are approving.
A practical separation of duties
A simple setup has three distinct roles:
- Observer: an online watch-only wallet tracks deposits, balances and transaction status.
- Coordinator: software constructs a proposed transaction or PSBT and passes it to the signer.
- Signer: an offline device or hardware wallet verifies the destination, amount and fee, then signs.
The observer should never be trusted to state the final destination on its own. The signer must show enough transaction detail for a human to compare it with an independent payment instruction.
For shared control, the signing layer can use more than one approver. Multisig and MPC wallets place the threshold in different parts of the system, but either approach still benefits from a monitoring layer that cannot sign.
Setup checklist
Before treating a watch-only wallet as reliable, check the following:
- Create a keyless wallet deliberately. In Bitcoin Core, use the private-key-disabled mode instead of converting an ordinary hot wallet informally.
- Verify the descriptor source. Export it from the intended signing wallet and compare it through a trusted channel.
- Include external and internal branches. Missing change descriptors can produce an incomplete balance.
- Choose a conservative timestamp. Use the earliest plausible activity date, accepting that the rescan may take time.
- Wait for scanning to finish. Confirm the reported scan state before reconciling balances.
- Test with a small known transaction. Confirm that the observer detects both the receive and, if applicable, the change output.
- Protect the observer’s data. Restrict access, backups and exports because the wallet reveals financial activity.
- Verify on the signer. Compare recipient, amount and fee on the signing device before approval.
- Back up after descriptor changes. Bitcoin Core explicitly says an import requires a new wallet backup.
When a block explorer is not enough
A public block explorer can check one address quickly, but it is a poor substitute for a wallet view when you have many derived addresses or need consistent internal accounting. Repeatedly pasting addresses into a third-party service also discloses which addresses you care about.
A self-hosted watch-only wallet keeps the address set and labeling under your control, though it still inherits the availability and security requirements of the node and its host. Compare the trust, privacy and maintenance costs before choosing the monitoring setup.
The point of watch-only is narrow and useful: observe without giving the observer the keys. Keep that boundary explicit, then design the scan, descriptor handling and signing checks around it.
