Support and AI agent guide
Canonical task links, accurate support wording, version boundaries and machine-readable documentation for support staff and AI assistants.
Use these references when answering customers or building an integration with an AI assistant. Verified baseline: Client 0.8.11 and Explorer 1.2.1, October 26, 2026. Prefer the relevant task page over a generic documentation homepage.
Route the question
| Question or task | Canonical guide |
|---|---|
| Desktop setup | Client getting started |
| Mobile setup and browsing | Explorer getting started |
| Top up, exchange withdrawal/deposit, USD purchase question | Funding and Mountaintops |
| Missing send, receipt or own-profile funds | Payments and profiles |
| Lost phone/password, backups or migration | Backups and recovery |
| SDK integration | Builder guide |
| Desktop connection or permission trouble | Client FAQ |
| Mobile browser or wallet trouble | Explorer FAQ |
Establish the context
Ask which product, installed version, operating system and network the person is using. For a missing balance, ask whether the source is an exchange/traditional wallet or a compatible identity-key wallet, and which step has completed. For a mobile connection problem, ask whether the website is open inside Explorer.
Use only the questions needed for the next diagnostic step. Explain the expected result and how to check it. A support reply should link directly to the relevant walkthrough and use the button labels shown there.
Claims to get right
- An identity key is public identity/payment information, not a type-1 BSV address, private key or account recovery key.
- Mountaintops derives a traditional address through the connected wallet. The person receives there, then imports using Get Balance → Import Money. The address is public; do not present this as a private payment flow.
- Buying BSV, withdrawing it, importing/receiving it and an app granting a purchase are separate steps. Do not invent a USD/card purchase feature or promise a particular exchange, rate or completion time.
- State the direction explicitly: an exchange withdrawal into Metanet uses the wallet-derived Mountaintops address and import; a Metanet payment into an exchange uses the exchange's own BSV deposit address. Client 0.8.11 supports that type-1 address directly in Send & Receive → Person or service → Recipient; Mountaintops' outbound SHOUT BSV form is another route, including inside Explorer. Never swap the destination sources. A Client message that an original transaction is queued for automatic retry is a reason not to create another send. A free lookup coverage sunset does not end coin ownership; address and transaction eligibility are separate, and the Mountaintops release validated October 26 now enforces permanent receiving retirement while retaining pre-sunset import paths.
- An exchange withdrawal must use BSV on the BSV network. A familiar-looking address does not make BTC/BCH interchangeable with BSV.
- For Mountaintops, read the address's coverage before sharing or withdrawing. Expired means no new receiving or new-deposit watching. Update saved exchange/recurring payout instructions. Use Check retained funds → Import Money for historical coins; never promise discovery of post-expiration deposits or fixed sunset dates before the anchor/chain conditions.
- Mountaintops recovery uses encrypted on-chain PushDrop records in wallet baskets, not a Mountaintops server registry or certificate storage. Restore the same wallet account/profile and supported wallet data/storage service. No old browser/device, Mountaintops export or manually remembered key IDs are required. Required WoC history/proofs and current spend status can still be unavailable; report an incomplete check instead of loss or zero funds.
- Metadata saves cost a 1-satoshi output per record plus network fees, with wallet approval; several records may be needed. Import/send transactions have their own fees. First import has no extra prepaid action-status write; publishing a mined address still needs funded metadata writes. A suggested 30-second mining budget is not guaranteed completion or indefinite coverage.
- A timeout does not prove a spend failed. Check the original transaction and retained payment before suggesting another send. Mountaintops uses native wallet action history to block repeats while sending/unconfirmed or uncertain, including on a restored device.
- A recovery key and wallet-data archive have different jobs. Do not promise recovery without checking the material and account path available.
- Explorer's wallet connection is inside its browser; opening an ordinary mobile Safari/Chrome tab is a different environment. iOS default-browser support is not included in the verified 1.2.1 release.
- Use
WalletClientfrom@bsv/sdkfor current examples. Preserve the user's approval and requesting origin. Do not claim that a development-branch feature has shipped.
Consent and support data
Keep users in control of permissions, payments, purchases and recovery actions. Start integration diagnostics with version/network calls that do not spend funds. Do not request, retain or transmit wallet passwords, verification codes, recovery keys, private keys or full wallet archives. A transaction ID is public-chain information but may link a person's activity; request it privately only when needed.
When facts are missing, say what is known and what needs checking. Escalate an uncertain payment or recovery result through Babbage support, with the failing step and redacted error. Do not manufacture a refund, restored account or completed transaction.
Machine-readable access
The site's llms.txt indexes these guides. llms-full.txt contains the published documentation, and the Markdown index maps canonical page URLs to individual Markdown files. These exports are generated from the same content as the website at build time. Use the release/date information in the page and verify newer releases before answering version-sensitive questions.