# Top up: Exchanges and Mountaintops

Canonical: https://docs.projectbabbage.com/docs/metanet-client/funding

Move BSV between Metanet and exchanges with Receive and Send. Check expiration, restore wallet records and review transfer and save costs.

**Use this guide to move BSV between Metanet and an exchange or traditional address wallet.** It applies to Client 0.8.11 and Explorer 1.2.1. Wallet releases were checked October 26, 2026. Mountaintops instructions match the [combined address-save and payment interface](https://github.com/p2ppsr/mountaintops/pull/8) and [wallet-input safeguards](https://github.com/p2ppsr/mountaintops/pull/9) deployed and validated that day. An exchange withdrawal **funds Metanet**; sending from Metanet to an exchange is an **exchange deposit**.

## Choose the receiving method

| Where the BSV is coming from | What to use |
| --- | --- |
| Another compatible Metanet wallet | Your receiving profile's identity key and [wallet-to-wallet payments](https://docs.projectbabbage.com/docs/metanet-client/payments) |
| An exchange or traditional wallet asking for a type-1 BSV address | The address shown by Mountaintops while connected to your intended Metanet wallet/profile |
| Sending from Metanet to your exchange account | The exchange's own BSV deposit address, entered in Client 0.8.11's **Send & Receive** or Mountaintops' **Send** view |
| You have USD or another fiat currency and have not bought BSV | First obtain BSV through a provider available to you; then use the appropriate receiving method above |

An identity key is **not** a traditional Bitcoin address. Do not convert it yourself or paste it into an exchange withdrawal form. Mountaintops derives its receiving key through your wallet's permissioned API; it does not require your private key or recovery key.

## Buy BSV versus top up Metanet

Buying BSV is the purchase step at your chosen provider. Withdrawing BSV moves it from that provider to a destination. Importing the received funds through Mountaintops makes those outputs available to your Metanet wallet.

These docs do not promise a built-in USD/card purchase flow, a particular exchange's availability, an exchange rate, a withdrawal minimum or a completion time. Check those details with your provider before paying. Select **BSV on the BSV network**; BTC and BCH are different assets/networks even when their address formats look similar.

## Receive through Mountaintops

1. **Connect the intended wallet.** On desktop, launch and unlock Client, open [mountaintops.net](https://mountaintops.net/) and choose **Connect wallet**. On mobile, open that URL **inside Explorer**. Review wallet permissions and confirm the profile and BSV network; an ordinary exchange withdrawal uses mainnet.
2. **Copy your receiving address.** Choose **Receive** and use **Your receiving address**. Read its expiration status, then choose **Copy address**. Never send to an **Expired** address. Use the address from your own connected wallet, not one supplied in a support message.
3. **Withdraw BSV from the exchange.** Select BSV on the BSV network, check the complete destination and provider minimum, then confirm once. When practical, use a small qualifying test first. Keep the withdrawal transaction ID. A mainnet type-1 address starts with `1`, but the prefix alone does not prove the asset, network or owner.
4. **Check and move the payment.** Return to **Receive** in the same wallet/profile. Under **Payments to your addresses**, choose **Check payments**. When verified coins are available, choose **Move to wallet** on the matching address row, review network and wallet/storage-service charges, and approve the wallet's prompts. Wait for the result and check wallet Activity and balance. Receipt at the address and movement into the wallet are separate steps; the final credit can be smaller because of fees.

The payment list covers your saved addresses independently of which one is selected for receiving. You do not need to switch addresses or pay a selection-record cost to move coins from another address. **Other addresses** also provides per-address checks; expired cards use **Check earlier payments** for historical coins. An exchange may still be processing its withdrawal, or the chain-data service may need time to show it. The first move into an empty wallet needs no prepaid action-status record; address/search saves are separate paid wallet writes.

**Arrival at the Mountaintops address and successful import are different milestones.** Do not make another exchange withdrawal merely because your Metanet balance has not changed yet.

## Privacy and permissions

Mountaintops deliberately uses a public traditional address. Its address activity can be linked and viewed on-chain; its own interface explicitly warns about this. Use wallet-native identity-key payments when the sender supports them and you do not need an address bridge.

The wallet authorizes the derived public key and signatures needed for import. Review the origin and action rather than granting unrelated requests. The **Send** view sends money outward to an address. To receive an exchange withdrawal, stay in **Receive** and use **Move to wallet** after checking for payments.

## Send from Metanet to an exchange

### Directly in Client 0.8.11

Client 0.8.11 supports **outgoing** payments to traditional type-1 addresses as well as identity keys. Open **Send & Receive**, choose the sending **Wallet profile**, select **Person or service**, and paste your exchange's BSV deposit address into **Recipient**. The wallet identifies a valid type-1 address and checks its checksum/network. Choose **Currency** explicitly, read **Amount (unit)** and the resulting satoshi amount, then review the payment before confirming. This does not make your receive identity key an exchange-compatible address; inbound funding still uses the receive/import path above.

Check your exchange's deposit minimum and confirmation policy first. Save the resulting transaction ID. If Client reports that the payment is queued for automatic retry, **do not send it again**; inspect Activity and the original payment. A network acknowledgement and a credit in your exchange account remain separate results.

### Through Mountaintops, including Explorer

1. **Get the destination from the exchange.** In your own exchange account, select **Deposit → BSV** and the BSV network. Check whether deposits are enabled, its minimum credit amount, required confirmations and supported address format. Copy the address shown there; do not use a Metanet identity key or an address someone sent in a support message.
2. **Connect the sending wallet.** Keep Client running and unlocked on desktop, or open Mountaintops inside Explorer. Choose **Connect wallet** and confirm the profile holding the spendable funds. If money is still at a receiving address, use **Receive → Move to wallet** first.
3. **Open Send.** Paste the exchange's address into **To** and enter **Amount in BSV**. The mainnet form expects a type-1 address beginning with `1`; do not alter an address to force a different format or network. Enter BSV with no more than eight decimal places. Leave enough for fees and the exchange's deposit minimum.
4. **Review and approve once.** Select **Send BSV** and review the wallet's destination, amount, network and fees. This is an outgoing payment. When practical, first send a small amount that meets the exchange's minimum.
5. **Track both sides.** Keep the submitted transaction ID and check native wallet Activity and the exchange's deposit history. **Activity this session** in Mountaintops is a temporary, collapsed list. Submission, confirmation and exchange credit are separate results; do not repeat a send because credit is delayed.

Sending BSV to an exchange is distinct from selling it for USD or withdrawing fiat to a bank. Those later steps, availability and charges belong to the exchange. The public-address privacy tradeoff applies to outbound payments too.

If a send times out, compare the retained transaction/Activity with the destination's deposit history before attempting another payment. For a confirmed transaction that the exchange has not credited, ask its support to reconcile the transaction ID and its deposit requirements. Never provide your wallet's recovery material.

## Address coverage changes

Mountaintops now applies the [BRC-234 coverage schedule](https://github.com/bsv-blockchain/BRCs/blob/master/opinions/0234.md). These are receiving and free-index coverage rules, not the destruction of coins or invalidation of otherwise valid transactions. Provider adoption is voluntary. A matching address does not guarantee that an exchange's funding transaction satisfies the separate TXID/version coverage rules; inspect **Address details**. A filtered index total is not a spendable balance.

Read the address card's current coverage and any pending sunset notice before every withdrawal. The card shows a short status such as **Expiration date not set yet**. Expand **Address details** for the stage through which its address filter passes and the next activation that expires it. At stage 27 it says **No expiration scheduled**; that does not guarantee every funding transaction is covered. The schedule anchors at **mainnet block 1,000,000**; calendar gates, volume and chain-time notice/activation rules all matter. There is no fixed calendar expiration date before that anchor is established. A pending chain-time deadline is not a guaranteed wall-clock time. Use **Other addresses → Refresh addresses** rather than guessing dates from an address prefix.

Once Mountaintops records an address as expired, receiving there is permanently disabled: **Copy address** and **Use for receiving** are unavailable, and Mountaintops blocks sends to expired destinations. It stops checking that address for new deposits. External senders can still create on-chain payments; Mountaintops cannot stop them or promise discovery of deposits sent after expiration. Replace saved exchange withdrawal addresses, whitelists and recurring payout instructions before the old address expires.

### Find longer coverage

In **Receive**, the **A longer-lasting address** section may offer **Use saved address** when the wallet already contains a suitable saved address. Switching still saves a paid receiving preference; review the fee request. Otherwise choose **Find an address**. Searching is free and runs in roughly 30-second work slices, with **Pause** and **Keep searching** controls. A work budget does not guarantee a match or permanent coverage.

When **New address found** appears, choose **Save & use address** and review the adjacent wallet-fee note and wallet request. This publishes the new address and selects it for receiving in **one encrypted 1-satoshi record**, plus network and any wallet-service fees; there is no separate switching record for that action. Wait for acknowledgement and verify **Your receiving address** before copying it for an exchange withdrawal. Switching to an already saved address with **Use for receiving** or **Use saved address** still writes its own paid preference record.

For manual targets or saved checkpoints, expand **Advanced search**. **Search target** offers the recommended estimate and all 27 stages; a target below the app's required stage is rejected. **Find another address** starts another search when a saved suggestion is shown. After pausing, **Save progress** writes a paid checkpoint; **Resume stage N** restores that saved search through the same wallet. Pausing alone does not save it. Unsaved work or a found-but-unsaved result can disappear on reload, and the same wallet can repeat the deterministic search for free. Keys are searched sequentially from key ID 1.

Changing the selected receiving address does not update an exchange's address book. Previous addresses remain under **Other addresses**, with their own coverage and historical funds. Mining an address also does not guarantee coverage of every transaction an external exchange creates.

## Wallet-backed recovery, including expired addresses

Restore the **same BRC-100 wallet account/profile and its supported wallet data/storage service**, then reopen Mountaintops and choose **Connect wallet**. Saved address publications, selections, explicit search checkpoints and permanent retirement history are encrypted on-chain PushDrop records in your wallet's basket. Deposit evidence is retained through the wallet too. Mountaintops is client-only; it does not keep a separate application-server registry or use certificate storage for these records. Recovery of saved records does not require the old browser's data, an open tab, the old device, exported Mountaintops files or manually remembered key IDs. Unsaved search work and the session transaction list are not restored. Keep the wallet's own account recovery and data backups available.

The original single-address scheme is retained as **Original address** (key ID 1, under **Other addresses** when it is not selected) and can be reconstructed from the same wallet without a metadata-save transaction. Do not discard old addresses when selecting a mined one. For an expired address, select **Check earlier payments**, then **Move to wallet** when verified historical coins are available. Expiration does not remove ownership or disable imports of coins received before sunset.

Historical checking uses wallet-retained evidence and exact known outputs. When needed, a first return can attempt a bounded confirmed-history lookup only through the last pre-expiration block. It depends on WhatsOnChain still serving the necessary history/proofs and current spend status; wallet-backed records cannot recreate provider data that is unavailable. Known pending transactions can be checked without reopening new-deposit discovery. An incomplete or failed check is **not** proof of a zero balance or lost coins. If an unfunded wallet cannot save the bounded-history completion marker, verified coins can still be imported; that bounded lookup may repeat until the marker can be saved.

If **Check your wallet before continuing** appears, inspect the retained transaction and the native wallet's Activity/history. **Check wallet result** must establish the original result before another payment. **Cancel unsent payment** applies only to a preparation the wallet can acknowledge canceling. A sending/unconfirmed or uncertain action is not permission to create another send, including after restoring on a new device.

Mountaintops has a collapsed **Activity this session** list, which clears when you reload or leave the page. This is a temporary display; the native wallet keeps its own action records, and saved addresses and coin recovery do not depend on the list. An empty list does not prove a payment never happened. Use wallet Activity and the retained transaction ID to reconcile earlier payments. Mountaintops does not offer a completed-history reload or create additional history tokens for this list.

## Fees and wallet approvals

| Operation | Cost and approval to expect |
| --- | --- |
| Find an address, Pause or Keep searching | Free browser computation; no automatic address or progress save |
| Save & use address | One encrypted publication/selection record with a **1-satoshi output plus network fees**; wallet-service charges may apply. No separate switching record for this action. |
| Use for receiving / Use saved address (existing addresses) | A separate preference save: a **1-satoshi output plus network fees**, with wallet approval |
| Save progress (Advanced search) | A **1-satoshi output plus network fees** for an explicit search checkpoint; resume it through the same wallet |
| Retirement or coverage metadata | Each encrypted PushDrop record creates a **1-satoshi output plus network fees**; one task can involve several records |
| Move to wallet / Send BSV | A real transaction with wallet/network fees and wallet approval; recipient amount, change and fees must be reviewed |
| Exchange purchase, withdrawal, deposit or fiat sale | The provider's own fees, minimums and confirmation rules; check them with that provider |

The 1-satoshi metadata output is not a fixed total fee or a fiat top-up price. Do not promise a universal fee; network and wallet service charges can apply, so inspect the actual wallet request. An empty wallet can move its first existing coins without a prepaid action-status record, but network and wallet/storage-service charges still apply. Compare the wallet’s total charge and net credit before approving; the 1-satoshi metadata output does not describe the total cost of moving coins. Publishing a new mined address or saving metadata requires enough wallet funds for those writes. If the wallet cannot save a record, do not share an unacknowledged address; fund it through a supported wallet-native payment or recover/import existing coins first. Do not delete or relinquish recovery outputs to avoid the cost.

Mountaintops checks the spend status of every selected input, including coins the wallet adds to pay fees, before signing and again before submission. These checks also apply to encrypted address and search-record saves. If an input is spent or its status cannot be verified, the preparation stops. A wallet balance or a valid signature alone does not prove those inputs are usable. Follow the [stopped-payment FAQ](https://docs.projectbabbage.com/docs/metanet-client/faq#why-does-mountaintops-say-the-wallet-chose-already-spent-coins); do not bypass the check or delete recovery records.

## If the money is not visible

| What you see | What to check next |
| --- | --- |
| No withdrawal transaction ID yet | Check the exchange/provider's withdrawal status. The provider may not have broadcast it. |
| A transaction ID but Check for payments shows zero | Verify BSV network, exact destination address and connected profile. Check whether the output was already spent/imported. Allow for data-service delay. |
| An expired address or restored device | Reconnect the same wallet/profile and restored wallet storage, use **Check earlier payments**, then import verified pre-expiration coins. Never reuse it for a new withdrawal. |
| Mountaintops shows BSV but Client/Explorer does not | The import step may still be required. Return to the same identity/profile and review the import prompt. |
| Import times out, reports an error or stays Pending | Keep the error and transaction IDs, inspect wallet Activity and check the original outcome with support before another move. A timeout does not prove nothing was broadcast; a Pending credit does not prove spendable funds or a transaction that can confirm. Do not delete the records. |
| An outbound exchange deposit is not credited | Verify its transaction ID, exact deposit address, asset/network, minimum amount and exchange confirmation policy. Check both wallet Activity and the exchange before sending again. |
| The wallet is not detected | Keep desktop Client running, or open Mountaintops inside Explorer on mobile. See the [connection FAQ](https://docs.projectbabbage.com/docs/metanet-client/faq). |
| A wallet permission request is waiting | Bring the wallet forward and review the requesting origin and expected basket/read scope. Denial or an incomplete coin read is not proof of a zero balance. |
| Activity this session is empty after a reload | Check native wallet Activity and the original transaction ID. The temporary list clears intentionally; do not repeat a payment on that basis. |

For help, contact [Babbage support](https://projectbabbage.com/contact) with your platform, app version, network, the step that failed and the exact error. Share a transaction ID privately when needed; it exposes public transaction history. Never send passwords, verification codes, recovery keys, private keys or wallet-data files in a public support thread.

## A support answer you can reuse

> Metanet normally receives payments using an identity key. If your exchange asks for a traditional BSV address, open mountaintops.net with Client running, or inside Metanet Explorer. Choose Connect wallet, open Receive, check Your receiving address and use Copy address for the exchange’s BSV-network withdrawal. Then use Payments to your addresses → Check payments and Move to wallet on the matching row. Never send to an expired address; Check earlier payments is for historical coins only. Receiving at the address and importing into Metanet are separate steps. Buying BSV happens with your chosen provider; this is the guide for getting it into your wallet.

Link customers directly to this page, then ask whether they are using desktop Client or mobile Explorer and which step they reached.

For the opposite direction, with a path that also works inside Explorer:

> To send BSV from Metanet into your exchange account, first copy your BSV deposit address from that exchange. Open mountaintops.net with Client running, or inside Explorer, and open Send, enter that destination in To and an Amount in BSV, then choose Send BSV. Review the wallet prompt, keep the transaction ID and allow for the exchange's deposit requirements. Sending BSV to an exchange, selling it and withdrawing USD are separate steps.