Watch-Only Portfolio Tracking: Full Visibility Without the Keys

The right way to track a portfolio is to give the tracker the power to see and never the power to spend. Watch-only — public addresses, read-only API keys, an xpub — does exactly that. This guide is how watch-only works, why it is the correct default, and the xpub trade it carries.

TL;DR

• Watch-only = see balances/history, no spend capability. The correct default for tracking.
• Inputs: 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 — full read-only completeness.
• xpub vs zpub: match the wallet's address type (BIP44-style legacy vs BIP84 native SegWit zpub) or derive the wrong addresses.
• An xpub cannot spend but reveals the whole wallet's address history — 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. Three forms:

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

None 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 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.

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 → an empty or wrong balance. This is the watch-only analogue of using the wrong chain model.

Can-spend vs can-see

The xpub property to internalise: safe for spending, costly for privacy.

• It cannot spend — 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 a deliberate privacy decision — handled fully in the privacy & 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.

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 — it exposes the whole wallet's history.
6. Confirm any tax use of the tracked data with an adviser (per jurisdiction).

How vendor tools handle watch-only

Koinly and CoinTracker support public-address, xpub/zpub, and read-only API tracking. Confirm the tool accepts xpub/zpub matched to address type, requires only read-only exchange keys, and never requests private keys/seed phrases — anything asking to spend to "track" is the red flag.

How Wag3s helps

Wag3s Folio tracks watch-only by design — public addresses, address-type-matched xpub/zpub for full HD-wallet completeness, and read-only exchange keys — never requesting a private key or seed phrase, and treating 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

• BIP32 HD wallets — xprv derives xpub; xpub derives public addresses but not private keys; hardened derivation prevents child-key + parent-xpub → parent private key
• xpub (BIP44-style) vs zpub (BIP84 native SegWit, bc1q/Bech32, m/84'/0'/0'/0/0) — extended public key must match the wallet's address type
• Watch-only inputs (public address, read-only exchange API key with no withdrawal, xpub/zpub) cannot spend; an xpub exposes the wallet's full address history (privacy trade)