# Client FAQ and troubleshooting

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

Answers about exchange funding, identity keys, wallet connections, permissions, recovery and Mountaintops session history and save fees.

Answers for **Metanet Client 0.8.11**, checked October 26, 2026. Mobile users should also read the [Explorer FAQ](https://docs.projectbabbage.com/docs/metanet-explorer/faq).

## How do I top up from an exchange?

An exchange commonly needs a traditional type-1 BSV address, while Metanet's native receive flow uses an identity key. Open [Mountaintops](https://mountaintops.net/) with Client connected, choose **Connect wallet → Receive**, copy **Your receiving address**, withdraw BSV there, then use **Payments to your addresses → Check payments → Move to wallet**. Follow the complete [funding guide](https://docs.projectbabbage.com/docs/metanet-client/funding), including network, fees and privacy checks. Arrival at the address is not the same as import into your wallet.

## Can I buy BSV with USD inside Client?

Do not assume that a USD amount or a funding prompt is a fiat purchase facility. Buy BSV through your chosen provider if needed, then follow [the receiving/import steps](https://docs.projectbabbage.com/docs/metanet-client/funding). Provider access, limits, fees and settlement times vary; these docs do not promise a built-in card or bank purchase.

## How do I withdraw from Metanet to an exchange?

Get your **BSV deposit address** from your own exchange account. In Client 0.8.11, open **Send & Receive → Person or service** and paste a valid type-1 address into **Recipient**. Choose the sending profile, currency and amount, then review the payment. Mountaintops' **Send** view is another route, including inside Explorer. Follow the [outbound walkthrough](https://docs.projectbabbage.com/docs/metanet-client/funding#send-from-metanet-to-an-exchange). Check deposit minimums, network, fees and confirmation requirements. Save the transaction ID and do not send twice because exchange credit is delayed or Client reports an automatic retry. Depositing BSV is separate from selling it or withdrawing fiat.

## Is my identity key a Bitcoin address or a recovery key?

Neither. It is a public key used to identify your wallet/profile to compatible apps and payments. An exchange address is a different input. Your recovery key is secret account-recovery material and must never be shared with a sender, website or support agent.

## Why does a website say no wallet is installed?

Check that Client is running and unlocked, that no other BRC-100 desktop wallet owns the bridge, and that the website is open on the same computer. Bring Client forward and inspect any permission prompt. Browser local-network/security restrictions can affect localhost connections; record the actual error rather than disabling browser protection. Builders can use the [connection-only example](https://docs.projectbabbage.com/docs/metanet-client/developers) to isolate transport from payment failures.

## Why does Client say another wallet is running?

The binary, JSON and HTTPS bridges share ports 3301, 3321 and 2121 with other desktop wallets. Quit the competing wallet rather than launching more copies. Client owns the set together so an app is not accidentally connected to different wallets on different bridge ports.

## Why does a prompt appear for each app?

Permissions are tied to the requesting origin and capability. A different site, protocol, basket, certificate request or spending scope can need a separate decision. Read the origin and limits. Manage or revoke access in Client's app/permission controls; blanket approval is not a connection fix. The app should recover cleanly when you deny a request.

## My send timed out. Should I send again?

First inspect Activity, the pending payment and the recipient's Receive screen. A signed/broadcast payment may exist despite an interrupted acknowledgement. Client preserves signed payments for recovery. Reuse the retained payment workflow; do not create another send until you know what happened to the first one.

## I moved money to my own profile. Why is its balance unchanged?

In Client, choose the destination profile in **Send & Receive**, open Receive and use **Accept saved payment**. A local saved payment remains on the sending device until acceptance, so do not clear that app's data. See [payments and profiles](https://docs.projectbabbage.com/docs/metanet-client/payments). Explorer's own-profile receipt behavior differs; do not assume every product has the same buttons.

## I paid an app, but my purchase is missing. What now?

Check wallet Activity and the app's purchase history or receipt. Save the transaction ID and any error. Ask the app's support to reconcile the payment with the entitlement before paying again. A wallet debit, delivery acknowledgement and purchased content becoming available are distinct events.

## Why is my balance smaller than the amount I sent?

Check the selected profile and network, exact BSV/satoshi amount, exchange withdrawal charge, Move to wallet network and wallet/storage-service charges, and any separately disclosed wallet-account update. A currency preference changes the display. It does not turn BSV into a USD deposit. Use the transaction details to distinguish fees from funds waiting to be imported or received.

## Is saving a recovery key enough to back up everything?

Keep recovery material and wallet-data backups separately. A same-device copy is not protection against losing the device. Transaction history, certificates, local pending payments and application files may need their own durable copies. Follow [backups and recovery](https://docs.projectbabbage.com/docs/metanet-client/backup-and-recovery) before reinstalling or changing devices.

## How do I get useful help?

Contact [Babbage support](https://projectbabbage.com/contact). Include Client version, operating system, mainnet/testnet, the app URL and exact failing step/error. Say whether funds have a transaction ID and whether Activity or Receive shows them. Share identifying details privately and redact screenshots. Never send passwords, SMS codes, recovery keys, private keys or full wallet-data archives.

## Does a Mountaintops address expire? Are my coins lost?

Receiving and free-index coverage can expire under BRC-234. Read the address card and use
**Other addresses → Refresh addresses** before a withdrawal. Expand **Address details**
for its passing stage and next expiration activation. Stage 27 has no later cutoff
scheduled. Transaction eligibility still matters. There is no fixed date before the mainnet
block-1,000,000 anchor and later chain/volume/notice conditions. Once retired, the
address is permanently blocked for new receiving in Mountaintops. Replace it in saved
exchange and recurring-payout instructions. Coins received before expiration remain
yours: use **Check earlier payments → Move to wallet**. Do not assume new deposits sent
after expiration will be discovered. See [address coverage](https://docs.projectbabbage.com/docs/metanet-client/funding#address-coverage-changes).

## Can I recover Mountaintops without the old browser or device?

Yes, with the same restored BRC-100 wallet account/profile and its supported wallet
data/storage service. **Connect wallet** reloads encrypted PushDrop records and
wallet-retained evidence. The original address remains derivable as well. No old
browser data, Mountaintops export or manually remembered key ID is required. Keep the
wallet's own backups; provider history/proofs and spend-status availability still
matter. A failed historical check is not proof that funds are gone. Follow
[wallet-backed recovery](https://docs.projectbabbage.com/docs/metanet-client/funding#wallet-backed-recovery-including-expired-addresses).

## Why does finding or selecting an address ask for a payment or permission?

**Find an address**, **Pause** and **Keep searching** are free. **Save & use address**
publishes and selects a new address in one encrypted **1-satoshi record plus network
fees**, with no separate switching record. Switching to an existing address with
**Use for receiving** / **Use saved address**, or choosing **Advanced search → Save progress**,
each writes its own record. Wallet-service fees may also apply; review the actual request.
**Move to wallet** and **Send BSV** have their own network and wallet/storage-service fees. The first move into
an empty wallet needs no extra prepaid action-status record.

Pausing keeps progress only in this page. Save a checkpoint explicitly to use
**Advanced search → Resume stage N** on another device, or repeat the search for free.
Do not delete recovery outputs or share a new address until its save is acknowledged.
See the [fee table](https://docs.projectbabbage.com/docs/metanet-client/funding#fees-and-wallet-approvals).

## Why did Mountaintops transaction history disappear after reloading?

Expand **Activity this session** for a temporary display that clears when you reload or
leave the page. Your native wallet retains its own Activity/action records, saved
addresses and coin evidence. Native unfinished-action checks still protect against
repeating an uncertain payment. An empty session list is not proof that a payment
failed: check wallet Activity, the transaction ID and the recipient before sending again.

## What if the buttons do not match these instructions?

An older open tab may retain the earlier interface. Check any unfinished payment in
your wallet first, then reload Mountaintops. The current interface uses **Connect wallet**,
**Receive** and **Send**. Reloading clears the temporary activity list; an empty list is
not evidence that a payment failed. Do not clear wallet data to refresh the website.

## Must I select an old address to move its payments?

No. In **Receive**, use **Payments to your addresses → Check payments**. Each address
with verified coins has its own **Move to wallet** row. This works independently of
the address selected for new receiving, so do not switch merely to access earlier funds.
The move still has its own wallet fees and approval. Expired addresses remain limited
to historical recovery; their appearance here does not reopen new receiving.

## The wallet shows Pending after Move to wallet. Should I try again?

No. A recorded wallet credit or valid signatures do not prove that a transaction was
broadcast, can confirm, or has spendable outputs. Pending can also reflect an invalid
transaction, such as one using inputs already spent elsewhere; waiting alone will not
repair it. Treat an unresolved Pending credit as unavailable.

Check native wallet Activity, the retained transaction ID and any **Check wallet result**
control. A data service not finding the transaction does not prove it was never
submitted. Keep the original records and contact support privately with the error and
transaction ID. Reconcile that outcome before another move or payment; do not resend,
delete wallet records or clear wallet data to make Pending disappear.

## Why does Mountaintops say the wallet chose already-spent coins?

The wallet can select fee inputs that were spent by another transaction. Mountaintops
checks every input before signing and again before submission, including for address
and search-record saves. If it finds a spent input, it stops; an unavailable spend-status
check also stops the preparation rather than treating the coins as usable.

Keep the error and any existing transaction ID. Review wallet Activity and ask support
to reconcile the original action and the wallet's coin state before trying again.
A displayed balance does not override the check. Do not delete wallet records, clear
wallet data or repeatedly approve new payments to work around the error. If the spend
status is unknown, wait for a successful check; do not assume it means zero funds.