Glossary · Infrastructure

What is xpub?

An extended public key is the watch-only half of a hierarchical wallet: from one xpub, a merchant derives unlimited receive addresses without ever exposing a key that can spend. The checkout generates a fresh address per invoice; the spending keys never left cold storage.

The pattern buys privacy, no address reuse, no change clustering, and security, the surface that watches cannot move funds. It is how serious Bitcoin acceptance has worked since the early blocks.

How xpub works

An extended public key, xpub, is the read-only half of a hierarchical wallet: it derives the full tree of receiving addresses without exposing any spending power. Share an xpub and a service can watch every address in the sequence, see every payment, and compute balances, while signing remains impossible without the private keys that never left your wallet.

The power for payments is delegation without custody transfer. A checkout platform given an xpub generates fresh addresses per order, observes each payment on-chain, and reconciles automatically, yet can never move a unit. The merchant's keys stay cold; the service stays useful.

The risks are privacy and derivation discipline: an xpub exposes the transaction history of its whole branch to whoever holds it, and address reuse across services links activity. Scoped derivations per integration keep the visibility bounded. The security property, no spending capability, is structural.

xpub in practice

A store's checkout generates a fresh receive address from its xpub for every order, watches the chain for the payment, marks the invoice paid on confirmation, and cannot sign a single outgoing transaction. Reconciliation runs itself against the observed flows. The audit trail this produces is unusually clean: every order's address, payment, and confirmation is public record keyed to that one integration's derivation, so month-end is a join rather than an investigation.

xpub on U.CASH

Bitcoin checkouts on U.CASH can settle to an xpub: every invoice gets its own derived address, and the merchant's spending keys stay wherever the merchant keeps them.

This is how non-custodial checkout scales: pay-ins without ever handing over keys. U.CASH accepts xpub-based receiving for exactly this pattern, and merchants auditing their exposure can verify the platform holds watch-only material. One integration note: rotate scope deliberately. A new derivation per storefront or per platform integration keeps each surface's visibility bounded and makes offboarding clean: revoke the integration's knowledge by pointing business elsewhere, and the old branch simply stops being watched. Nothing about that ceremony touches the keys. Ask for the watch-only pattern by name when evaluating any checkout provider.

Related infrastructure terms

DEX routingCross-chain swapGas fees

See also

UTXOCold wallet

xpub: FAQ

Is sharing an xpub safe?
For receiving, yes: an xpub derives addresses but cannot sign. Sharing it trades a little privacy, the derived chain is visible, for a lot of operational safety.
Do chains other than Bitcoin have xpubs?
The hierarchical derivation pattern (BIP-32 style) runs across the Bitcoin family; account-model chains get the same effect differently, fresh deposit addresses per account, no key exposure.
Can an xpub spend my funds?
No. It derives addresses and observes payments only; spending requires the private keys, which an xpub mathematically does not contain.
What does an xpub reveal?
The full transaction history of its derived addresses, which is a privacy consideration. Scope a separate derivation per integration to bound visibility.
Why does checkout generate a new address each time?
Fresh addresses per order improve privacy and make reconciliation unambiguous: each invoice maps to exactly one on-chain flow.
Keep reading

The glossary, A to Z

Every term behind the rails, the assets, and the settlement.