Watch-Only Portfolio Tracking: Full Visibility Without the Keys

The defining idea of watch-only tracking is a deliberate asymmetry: the tracker gets the power to see and never the power to spend. The inputs that achieve it are specific. A public address, a read-only exchange API key with no withdrawal permission, or, for a whole Bitcoin wallet, an extended public key (xpub or zpub) that derives every address an HD wallet will ever use without exposing a single private key. The distinct thing to get right here is the xpub mechanics, where the extended-key type has to match the wallet's address standard or you derive an empty address set, and where one key buys full read-only completeness at a real privacy cost. This article covers how watch-only works and the trade-offs it carries. It is a spoke of the multi-wallet aggregation pillar.

What watch-only means in practice

• Watch-only is visibility into balances and history with no spend capability, the correct default for tracking.
• The inputs are public addresses, read-only exchange API keys (no withdrawal), or a Bitcoin xpub/zpub.
• An xpub derives every address of an HD wallet but never a private key, giving full read-only completeness.
• xpub versus zpub matters: match the wallet's address type (BIP44-style legacy versus BIP84 native SegWit zpub) or you derive the wrong addresses.
• An xpub cannot spend but reveals the whole wallet's address history, which is a privacy trade.
• Never give a tracker a private key or seed phrase.

What watch-only is

A watch-only setup gives the tracker visibility without spending authority. It takes three forms:

• a public address, or several;
• a read-only exchange API key (balances and trades, no withdrawal);
• a Bitcoin extended public key (xpub/zpub).

None of these can move funds. That is the entire point: tracking needs to read, never to sign. A tool that asks for a private key or seed phrase to "track" is asking for far more than tracking requires.

The xpub: a whole wallet, read-only

A BIP32 HD wallet has an extended private key (xprv) that derives an extended public key (xpub). The xpub can derive every receive and change address the wallet uses, but it cannot derive the xprv or any private key, and hardened derivation specifically blocks a child-key-plus-parent-xpub path back to the parent private key. So importing an xpub gives a tracker complete, read-only visibility of the entire wallet, the completeness win, achieved without any spend risk.

HD wallet derivation paths explained

Bitcoin HD wallets use structured derivation paths that determine both the address type and the key hierarchy:

A watch-only tracker must derive addresses using the path that matches the wallet. Importing a zpub but deriving BIP44 addresses will produce a completely different (empty) address set. Most hardware wallets (Ledger, Trezor) export the xpub/zpub for the active account; confirm which account and path are being exported.

xpub vs zpub: match the address type

Extended public keys are address-type-specific:

A watch-only tracker must use the extended public key that matches the wallet's address type. Feed an xpub for a native-SegWit (zpub) wallet and it derives the wrong addresses, producing an empty or wrong balance. This is the watch-only analogue of using the wrong chain model.

Address gap limit and discovery

HD wallets use a gap limit (typically 20) to decide when to stop deriving new addresses: if 20 consecutive derived addresses have no transaction history, the wallet considers the end reached. A watch-only tracker that enforces the gap limit correctly will discover all used addresses without generating an infinite number. However, if the user generated addresses manually beyond the gap limit, the tracker may miss those. The standard approach: derive until 20+ consecutive unused addresses are found, then stop.

Can-spend vs can-see

The xpub property to internalise is that it is safe for spending and costly for privacy.

• It cannot spend, because no private key is reachable from it.
• It reveals the whole wallet: every address used and to be used, linkable together.

So an xpub is the right tool for read-only completeness and at the same time a deliberate privacy decision, handled fully in the privacy and watch-only trade-offs article.

Read-only on the exchange side

The exchange-side equivalent is a read-only API key: balances and trades, no withdrawal. It is the correct setting for a tracking integration, which never needs to move funds. Rotate keys periodically and never enable withdrawal for a tracker. This is the same least-authority principle as watch-only on-chain.

Exchange API key permissions to check

When creating a read-only API key for a tracking integration, confirm:

• Enabled: read account info, read trade history, read balances, read deposit/withdrawal history (read-only versions).
• Disabled: spot trading, margin trading, futures trading, withdrawals, transfers, sub-account management.

Some exchanges offer a dedicated "read-only" permission preset; others require manually unchecking each action permission. Never grant trading or withdrawal permissions to a tracking tool.

Step-by-step: setting up watch-only tracking

1. For each EVM chain address: copy the 0x... public address directly into the tracker. No key derivation needed for EVM addresses.
2. For Bitcoin/Taproot wallets: export the xpub/ypub/zpub from the hardware wallet or software wallet for the relevant account (typically Account 0). In Ledger Live: Settings → Advanced → Export logs / Derivation path shows the xpub. In Trezor Suite: Account → Show public key.
3. Match the extended key type to the address format. If the wallet uses bc1q addresses, use the zpub. If it uses bc1p (Taproot), check if the wallet exports an xpub under the BIP86 path — not all trackers support Taproot watch-only yet.
4. Configure the gap limit. Set gap limit to at least 20 (the BIP32 standard). For older wallets with heavy use, consider 50 to avoid missing addresses.
5. For exchange accounts: generate a new API key with read-only permissions only. Copy the API key and secret immediately (most exchanges show the secret only once). Paste into the tracker's exchange integration. Verify by checking that no trading or withdrawal permissions appear.
6. Confirm balances match. Cross-reference the tracker's reported balance against the wallet software or exchange balance for at least the three largest positions. A mismatch usually indicates a wrong extended key type or derivation path.
7. Rotate exchange API keys periodically (every 90 days is a reasonable default). Generate the new key before revoking the old one to avoid a tracking gap.

Common errors and how to fix them

Error 1 — Using xpub for a zpub (native SegWit) wallet. The most common Bitcoin watch-only error: the tracker derives P2PKH addresses from an xpub while the wallet uses P2WPKH (bc1q). The derived addresses are different from the actual wallet addresses, so the tracker shows zero balance. Fix: export the zpub (not xpub) for BIP84 wallets; match the extended key to the address type.

Error 2 — Not scanning change addresses. HD wallets use two address chains: external (receive addresses, index 0) and internal (change addresses, index 1, path m/.../1/n). A tracker that only scans external addresses misses all change outputs and under-counts the balance. Fix: confirm the tracker scans both the 0 (external) and 1 (internal) chains for BIP32 wallets.

Error 3 — Granting trading permissions to a read-only exchange key. Some trackers request a "full" API key by default without explaining why. Granting trading or withdrawal permissions to a tracker exposes the account to risk if the tracker is compromised. Fix: create exchange API keys with only read permissions enabled; decline any tracker that requires trading or withdrawal access.

Error 4 — Forgetting sub-accounts on exchanges. Many exchange accounts have sub-accounts (spot, futures, staking, savings) that hold separate balances. An API key configured only for the main spot account misses sub-account balances. Fix: check whether the exchange's API provides a unified-account endpoint or requires separate API calls per sub-account type.

Practical guidance

1. Default to watch-only: public addresses, xpub/zpub, read-only API keys.
2. Never share a private key or seed phrase with a tracker.
3. Match xpub/zpub to the wallet's address type or balances will be wrong.
4. Use read-only (no-withdrawal) exchange API keys; rotate them.
5. Treat an xpub as a privacy decision, since it exposes the whole wallet's history.
6. Confirm any tax use of the tracked data with an adviser (per jurisdiction).

Configuring a tool for watch-only

Koinly and CoinTracker all support public-address, xpub/zpub, and read-only API tracking, but the watch-only-specific points to confirm are:

• it accepts the extended public key matched to the wallet's address type (xpub, ypub or zpub), so a native-SegWit wallet is not derived as legacy and shown empty;
• it scans both the external (receive) and internal (change) address chains, or it under-counts the balance;
• it honours the gap limit so it discovers all used addresses, and lets you raise it for heavily-used wallets;
• it requires only read-only exchange keys with no trading or withdrawal scope, and supports per-sub-account balances;
• it never requests a private key or seed phrase.

Anything that asks for spend capability in order to "track" is the red flag.

How Wag3s handles watch-only

Wag3s Folio tracks watch-only by design: public addresses, address-type-matched xpub/zpub for full HD-wallet completeness across both address chains, and read-only exchange keys. It never requests a private key or seed phrase, and treats xpub import as an explicit privacy choice. See the Folio product page.

Further reading

• Multi-Wallet Aggregation
• Crypto Portfolio Privacy & Watch-Only Trade-offs
• Multi-Chain Portfolio Aggregation Beyond EVM
• Internal Transfer vs Disposal in Crypto
• Entity vs Personal Wallet Separation
• Crypto Cost Basis Methods 2026

Sources

• Bitcoin — BIP32: Hierarchical Deterministic Wallets: an xprv derives an xpub; an xpub derives public addresses but not private keys, and a wallet can be shared with or without the ability to spend.
• Bitcoin — BIP84: Derivation scheme for P2WPKH: the native-SegWit (zpub, bc1q) standard whose m/84'/... path must match the extended key used.
• IRS — Digital assets for any tax use of the tracked data, which is jurisdiction-specific and unrelated to the watch-only mechanism.