Development blog · 059 · 20 Oct 2026

b-Aware: find a hole in bWalletX, get paid in BSV

bWalletX now has a responsible disclosure policy and a bug bounty, paid in BSV. Here is how it works, why the numbers are what they are, and what we did about today’s BRC-100 advisory.

bWalletX is a non-custodial wallet. If it signs something you did not approve, or lets someone read your keys, that is the worst thing it can do, and we would rather hear about it from a researcher than from a victim. So from today there is a page for that: bwalletx.com/b-Aware.

What it is

A responsible disclosure policy and a bug bounty, paid in BSV.

• Report by email to support@bwalletx.com with the subject b-Aware. We acknowledge within 2 working days, give you a severity and a fix plan within 7, and tell you when the fix ships. Never send a recovery phrase or key; use a throwaway wallet to show the problem.
• Rewards: Critical 10 BSV (take funds, extract keys, sign without approval), High 3 BSV (bypass an approval or permission, forge a pairing, drain through a dApp endpoint), Medium 0.5 BSV (leak private data, defeat the safety filter, lock a user out of their own wallet). Low findings get credit.
• Safe harbour. Good-faith research under the policy is authorised. We will not pursue legal action for it, and if someone else does, we will say publicly that you were acting under the policy.

The machine-readable version is at /.well-known/security.txt, and the policy lives in the open-source repository as SECURITY.md. Ordinary bugs still go to Bugs: tell b in the app.

Why the numbers look like this

We are a small company and we will not pretend otherwise. A flat “10 BSV per bug” would be the wrong shape now that AI-assisted scanning makes a plausible report nearly free to produce: it would pay a cosmetic finding the same as a key-extraction bug and it would be gamed within a week.

So the programme pays by impact on users’ money and keys, not by count. There is a pool of 20 BSV per calendar quarter; when it is spent, valid reports still earn credit and are paid from the next quarter, in triage order. First valid report of an issue wins. Duplicates, things we already know about and the published “known and accepted” list earn credit, not money. A working reproduction is required.

Ten criticals in a non-custodial wallet would be an existential finding whatever we paid for them. If they exist, we want to know. The pool keeps the spending from running ahead of our ability to fix.

Public responses to advisories

The page also carries our dated responses to published advisories that touch BRC-100 wallets and the BSV TypeScript stack, because “are we affected?” is the question every wallet user has and few wallets answer in writing.

Today’s entry is bsv-blockchain/bsv-desktop#135, a hardening of the reference desktop wallet’s manifest.json fetch against server-side request forgery. A BRC-100 wallet fetches an app’s manifest to show its declared permissions in one grouped prompt; in the Electron wallet that fetch ran in the privileged main process on a URL the renderer supplied.

bWalletX is not affected by the same mechanism. There is no page-to-wallet “fetch this URL” channel. The manifest fetch happens inside the wallet toolbox’s permissions manager, which builds the URL from the originator rather than accepting one, goes through the SDK’s public-HTTPS fetch (HTTPS only, no credentials, pinned to that origin), refuses redirects, caps the body and times out. And the originator is not the page’s to choose: the extension rejects any message whose originator does not match the browser-reported sender origin, and the mobile app derives it from the verified origin of each site’s endpoint. The only host a site can make the wallet contact is its own.

We also say what we share with upstream: in browser runtimes the wallet cannot pre-resolve DNS, so a site could rebind its own hostname to a private address. That is listed under “known and accepted” rather than hidden. The two earlier ts-stack advisories (September’s coordinated trust-boundary advisory and July’s createAction output-redirection issue) are patched by the SDK and toolbox versions we ship.

What we ask of you

Test against your own wallets and your own money. Do not touch anyone else’s data. Give us time to fix before you publish. In return you get a fast, written answer, a reward if it is real, and your name on the page if you want it there.

The credits section is empty today. Yours could be the first name on it.

Related: b-Aware · Bugs · Open source · Privacy