# Explorer FAQ and troubleshooting

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

Mobile wallet and browser help, exchange funding, recovery, and Mountaintops session history, address saves and wallet fees.

Answers for **Explorer 1.2.1**, checked October 26, 2026. For desktop behavior, use the [Client FAQ](https://docs.projectbabbage.com/docs/metanet-client/faq).

## Is Explorer a blockchain block explorer?

Here, Metanet Explorer is the **mobile browser and wallet**. These guides describe browsing websites and using wallet capabilities, not a site for searching arbitrary blocks and transactions.

## Why does a website work on desktop but not on my phone?

Open the site inside Explorer. A normal mobile Safari/Chrome tab does not automatically have Explorer's wallet bridge. Confirm your wallet is signed in, reopen the intended app tab and inspect any wallet prompt. Builders should test [SDK connection, origin and network](https://docs.projectbabbage.com/docs/metanet-client/developers) before investigating a paid action.

## How do I receive money from an exchange?

Open [mountaintops.net](https://mountaintops.net/) **inside Explorer**, choose **Connect wallet → Receive**, copy **Your receiving address** and use it for the exchange's BSV-network withdrawal. Return to **Payments to your addresses → Check payments → Move to wallet**. Do not paste your identity key into an exchange address field. Follow the [full funding walkthrough](https://docs.projectbabbage.com/docs/metanet-client/funding) for fees, timing, privacy and missing-funds checks.

## Does Explorer buy BSV for USD?

A USD display does not establish a card/bank purchase facility. Buy BSV with your chosen provider when needed, then withdraw and import it using the appropriate receive method. These guides do not promise an integrated fiat purchase or availability of a particular exchange.

## How do I send BSV back to an exchange?

Open Mountaintops inside Explorer with the intended sending profile. Get the exchange's BSV deposit address from your own exchange account, then use Mountaintops' **Send** view to enter the address and amount in BSV. Review the wallet prompt and follow the [exchange-deposit walkthrough](https://docs.projectbabbage.com/docs/metanet-client/funding#send-from-metanet-to-an-exchange). Check minimums, fees and confirmations, and retain the transaction ID. A sent transaction and a credited exchange balance are different milestones.

## Can I make it my default browser on iPhone?

The verified iOS 1.2.1 release lacks the required system default-browser entitlement. Open Explorer directly and enter the website URL there. A pending platform request or a later source change is not proof that the installed app supports the feature.

## Do I need to approve everything a site asks for?

No. Read the origin, capability, amount and scope. Decline requests that do not match your task. Manage the site's permissions through the wallet's permission controls. Changing an app origin or profile can change which grants apply; bypassing prompts is not a troubleshooting step.

## Why is a payment waiting in Receive?

Some identity-key payments need explicit receipt before they become spendable. Open Receive, inspect the sender/amount and choose **Receive**, or use **Receive All** for the waiting list. Explorer 1.2.1 also improves automatic receipt between your own profiles. Check the destination profile, Activity and incoming list before sending again.

## What if the app was backgrounded, closed or lost its connection?

Reopen it and check the relevant task state first. For recovery, finish any pending wallet-save/password stage. For a purchase, check Activity and the app's receipt. For a wallet-data import/export, inspect its saved job or file. Do not repeat a spend or delete app data just to clear an ambiguous status.

## Does exporting wallet data include my signing keys?

No. **Settings → Wallet data files** exports wallet history and records, separately from key recovery. Keep the account recovery material and encrypted-file passphrase too. A local file still inside the app is not an independent backup. Follow [backups and recovery](https://docs.projectbabbage.com/docs/metanet-client/backup-and-recovery) before reinstalling or replacing the phone.

## What should I send support?

Use [Babbage support](https://projectbabbage.com/contact) and include Explorer version, iOS/Android version, network, app URL, failing step and redacted error. Say whether the site was open inside Explorer and whether a transaction ID or pending receipt exists. Never send verification codes, passwords, recovery keys, private keys or full wallet-data files in a public conversation.

## 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.
