Receive Descriptors and Extended Public Keys
Manatee can derive a fresh receiving address for each payment from read-only wallet data. This is usually better than reusing one Bitcoin address for many orders. If you are unfamiliar with the custody boundary, start with Custodial vs. Non-Custodial Bitcoin Payments.
Why fresh addresses matter
Fresh addresses improve order reconciliation and on-chain privacy. Each payment gets its own address, so your backend can connect a blockchain transaction to one payment request without guessing from amount and timing alone.
Bitcoin receive descriptors
A Bitcoin receive descriptor is explicit wallet data that describes how receiving addresses should be derived. If your wallet can export a ranged receive descriptor, that is usually the cleanest format because it contains both the public key material and address type.
Extended public keys
Some wallets expose account-level public keys instead. On mainnet you may see xpub, ypub, or zpub; on testnet/Testnet4 you may see tpub, upub, or vpub.
Extended public keys are read-only. They cannot spend Bitcoin or reveal private keys. They can, however, reveal receiving addresses and incoming transaction history for the wallet account, so treat them as sensitive.
Bitcoin Cash account xpubs
BCH receive configuration is available for both Testnet and Mainnet in Wallet Settings. Use a wallet account and extended public key that match the selected network.
For BCH, Manatee uses an account-level extended public key instead of a Bitcoin output descriptor. Export the public key from the BIP44 account path:
m/44'/145'/account'
Most wallets use account 0', resulting in m/44'/145'/0'. The exported key must be an account-level public key at depth 3 with a hardened account child. Manatee then derives payment addresses from the external receive branch:
/0/index
The BCH integration supports P2PKH receive-address derivation. Derived and supplied addresses are normalized to network-specific, prefixed CashAddr:
| Network | Canonical prefix |
|---|---|
| Mainnet | bitcoincash: |
| Testnet | bchtest: |
| Regtest | bchreg: |
Use a mainnet xpub only for BCH mainnet and a testnet tpub for BCH testnet or regtest. Private extended keys and alternative Bitcoin serializations such as ypub, zpub, upub, and vpub are rejected. Bitcoin SegWit address types and BTC receive descriptors are not valid BCH receive configurations.
Prefixed and prefixless P2PKH and P2SH CashAddr inputs are supported for manual destination addresses. Compatible legacy P2PKH and P2SH addresses are accepted and returned as canonical CashAddr. Account-xpub derivation itself produces P2PKH. Token-aware CashAddr, CashToken-bearing outputs, and other BCH address types are outside the supported payment scope.
An extended public key does not encode its complete ancestor derivation path. Manatee can validate its network, depth, and account-level structure, but cannot prove from the key alone that it originated at coin type 145' rather than another BIP44 coin type. Always export it from a dedicated Bitcoin Cash account and verify the displayed source path in your wallet.
Production recommendation
Use a dedicated wallet account for Manatee payments. Do not export public wallet data from a personal wallet or treasury account. A dedicated payment account keeps the visible transaction history scoped to your checkout activity.
Manual destination addresses
For simple tests, your backend can create a payment with destination_address if your API key allows customer-provided addresses. For production checkout, descriptor-backed or extended-public-key-backed address derivation is usually safer and easier to reconcile.