# Top up: Exchanges and Mountaintops

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

Move BSV between Metanet and exchanges. Check address expiration, restore saved wallet records and review import and save fees.

**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 [compatibility and explicit-save release](https://github.com/p2ppsr/mountaintops/pull/6) 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' outbound **SHOUT BSV** form |
| 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. **Choose the destination wallet and profile.** On desktop, launch and unlock Client, then open [mountaintops.net](https://mountaintops.net/) in your browser. On mobile, open that exact URL **inside Metanet Explorer**. Safari or Chrome on the phone does not automatically use Explorer's wallet.
2. **Select Show My BSV Address.** Review the wallet permission request. Confirm you are connected to the intended profile and network. For an ordinary exchange withdrawal, use your mainnet wallet. Use the **Receiving** address card, read its coverage warning and choose **Copy address**. Never use an address marked **Expired — do not send coins to this address**. Copy the address shown by your own connected wallet; a mainnet type-1 address starts with `1`. The prefix alone does not prove that the asset, network or owner is correct.
3. **Withdraw BSV to that address.** Check the entire address in the provider's confirmation screen. When practical, first use a small amount that exceeds the provider's withdrawal minimum and leaves room for transaction fees. Keep the withdrawal transaction ID. Never send to an address supplied in a support message instead of the address your own connected wallet produced.
4. **Return to the same wallet/profile and Mountaintops.** Select **Get Balance** on the address you used. Mountaintops verifies unspent outputs and retains deposit evidence in your wallet. An expired address instead has **Check retained funds** for historical coins. A provider may still be processing its withdrawal, or its transaction may need time to appear in the transaction-data service.
5. **Select Import Money.** Review and approve the wallet's import/signing prompts. This spends the received address outputs into your wallet's managed funds. The import transaction pays network fees, so the final wallet credit can be smaller. Importing your first coins does not require a prepaid action-status record. Saving address/search metadata is a separate wallet action with its own costs, described below. Wait for the import result, then check your wallet balance and Activity.

**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 separate **SHOUT BSV** form sends money outward to an address; it is not the button for receiving or importing your withdrawal.

## 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. **Open Mountaintops with the sending wallet.** Keep Client running and unlocked on desktop, or open Mountaintops inside Explorer on mobile. Select the profile whose spendable funds you intend to use. If money is still at your Mountaintops receiving address, finish **Import Money** first.
3. **Use the outbound form.** In **SHOUT BSV Across To Someone**, paste the exchange's address into **Recipient Address** and enter a positive amount in **Amount (BSV)**. The current mainnet form expects a type-1 address beginning with `1`; a different network/format is not a reason to alter the address. Enter BSV, not USD or a raw satoshi count, and use no more than eight decimal places. Leave enough in the wallet for fees and enough at the destination to meet the exchange's minimum.
4. **Review and approve once.** Select **SHOUT BSV**, then check the wallet's destination, amount, network and fees before approving the transaction. This is a real outgoing payment. When practical, send a small qualifying test deposit before a larger amount.
5. **Track both sides.** Save the transaction ID shown by Mountaintops and review wallet Activity. Check the exchange's deposit history and confirmation policy. Broadcast success does not prove that the exchange has credited your trading balance. Do not repeat the send merely because the exchange has not credited it yet.

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. Before a calendar date is known, the card states the stage through which its address filter passes and the next stage activation that expires it. At stage 27 it states that no later free-coverage cutoff is 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 **Refresh coverage** rather than guessing dates from an address prefix.

Once Mountaintops records an address as expired, receiving there is permanently disabled: **Copy address** and **Use this address** 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

Under **Find longer coverage**, choose a **Search target** and select **Find longer-coverage address**. All 27 stage targets are listed; a target below the app's required stage is rejected. The suggested target estimates about **30 seconds** of browser work; it is a work budget, not a guaranteed completion time or permanent coverage. Search derives keys deterministically with sequential key IDs starting at 1.

**Searching, Pause search and Continue search are free browser computation.** Pausing keeps progress in the current page; it does not automatically save a checkpoint to the wallet. To resume on another device, choose **Save progress to wallet · fees apply**, review the wallet request and wait for acknowledgement. This creates a 1-satoshi encrypted record plus network fees. On reconnecting the same wallet, use **Resume saved stage N search**. Unsaved progress or a found-but-unsaved result can be lost when the page reloads; the same wallet can repeat the deterministic search.

When **Match found · not saved yet** appears, the result is not published, displayed as a usable address or selected for receiving. Choose **Save address to wallet · fees apply** and review the wallet's record and network fees. After the save and readback succeed, review **Found and saved. Review before switching**, then choose **Use this address**. Selection saves a separate preference record, also a 1-satoshi output plus network fees. Wait for the **Receiving** badge before copying the address for a withdrawal.

Changing the selected receiving address does not update an exchange's address book. Previous addresses remain under **Previous and saved 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 **Show My BSV Address**. 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) 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 retained funds**, then **Import Money** 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 **Review unfinished wallet actions** appears, inspect the retained transaction and the native wallet's Activity/history. **Check wallet outcome** must establish the original result before another payment. **Cancel unsubmitted preparation** 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 shows **Transactions this session**, 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 |
| --- | --- |
| Search, pause or continue in the current page | Free browser computation; no automatic address or progress save |
| Save address to wallet · fees apply | A **1-satoshi output plus network fees** for the encrypted address record; wait for save acknowledgement before using or sharing |
| Use this address | A separate preference save: a **1-satoshi output plus network fees**, with wallet approval |
| Save progress to wallet · fees apply | 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 |
| Import received coins or SHOUT 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 network fee; inspect the wallet's actual request. An empty wallet can import its first existing coins without first paying for an extra action-status record, but the import still pays its network fee. 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.

## 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 Get Balance 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 retained funds**, 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 or reports an error | Record the error and transaction IDs, then inspect wallet Activity and refresh the address balance before retrying. A timeout does not prove that nothing was broadcast. |
| 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. |
| Transactions 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 Show My BSV Address, check that the selected address is eligible for receiving, use Copy address and withdraw BSV on the BSV network there. Then return to Get Balance and Import Money. Never send to an expired address; use Check retained funds only for historical coins. 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 use the SHOUT BSV form with that destination and an amount in 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.