Qbit Wallet 1.0.6

Tagged 2026-10-30. Notes for every release are in docs/releases/release-notes.md.

Install Qbit Wallet from the Chrome Web Store. The files attached here are for verifying the build, not for installing.

Sending and fees

• A send whose broadcast outcome is unknown no longer keeps its funds unavailable, or blocks Speed up, until the browser restarts. Once the wallet finds the transaction pending, or you leave the recovery screen, Speed up works. The funds come back once it finds the transaction gone, and the balance card and the send screen now agree on what is available.
• A send whose broadcast hits a transient error (a gateway error, a timeout after sending, or a reply that is not the transaction's identifier) is no longer left as "outcome unknown" at once. Once a lookup shows the network does not have it, the wallet sends the same signed transaction again, at most twice, and starts no re-send more than 30 seconds after the first attempt. This applies to website broadcasts too.
• A fee bump is checked again, right before it is broadcast, for payments that spend the original transaction, including one made from another device or by a recipient while the confirmation screen was open, and when it is retried after the wallet restarts in the background. Such a bump is refused instead of cancelling that payment.
• A send that would spend the change of a large unconfirmed send together with many other inputs is refused before signing, with a message to wait for the earlier send to confirm or send less. qbit nodes reject a chain of unconfirmed transactions over 404 kB, so such a send used to be signed and then rejected. The wallet now spends that change only in a send small enough to fit.

Balance

• When the explorer cannot be reached, the balance card says so instead of showing a balance of 0. If no balance has loaded, the card turns grey and says the balance could not be loaded, with Try again. If a later refresh fails, the card keeps the last balance and says it may be out of date. Try again fetches at once, and the warning clears on the next refresh that succeeds. A refresh that finishes late no longer replaces the balance or error of a newer one. The card's label now reads "Wallet Balance". Until the first balance arrives, the card shows it as loading instead of 0, or keeps it masked while the balance is hidden. If the explorer does not answer at all, the error appears after about 45 seconds.

Accounts with many outputs

• The balance card of an address holding more outputs than the explorer will list shows its Available and Unavailable amounts as unknown (--) instead of 0 and the whole total, with a line saying why, as the send screen does. The total still comes from the address statistics.
• Switching accounts while the send screen is still reading the outputs of an account with many outputs no longer leaves the next account's send screen showing 0 available. Each account's outputs are kept for that account only, a slow read that lands late no longer replaces them, and opening Send again while a read for the same address state is running joins it instead of starting another.
• Consolidation now finds an account's mature outputs when a full page of its transactions is still pending, instead of saying nothing is ready.
• Large history pages and transactions now load on slow connections. The explorer must still start answering within 15 s, and a download that stops sending data for 15 s is still cut off and retried. One that keeps arriving may take up to 5 minutes per try instead of failing after 15 s. A read is tried up to three times, so a page that arrives too slowly can take about 15 minutes to fail, and a screen that waits for it, such as Prepare on the consolidation screen, waits as long.

Websites and approvals

• A website broadcast through pushTx or pushPsbt whose result is unknown is looked up instead of reported as failed: the website gets the transaction's identifier when it is found, or a distinct "outcome unknown" error naming the transaction to check before retrying. The inputs of a transaction the user approved signing for a website stay reserved until the result is known.
• Transaction approvals and the send screen show the amount leaving the wallet, fee included, ahead of the transaction details, and warn when the fee is far above the recommended rate, at least 100 times the network minimum, or a large share of the amount sent. Outputs to addresses the wallet does not recognise are marked. Signing an abnormal fee, or an output beside the recipient a request names, needs an explicit confirmation.
• Account and network events reach only the websites they concern. Switching networks no longer tells every connected website it lost access. A website connected on the new network receives its account, and a website that asked for the switch stays connected. Turning on quick multi-sign for one website no longer sends a network change to every website. Websites built with the wallet-connect React library no longer revoke their own access when the wallet reports no account.
• Signing several transactions at once with quick multi-sign now checks each one for an abnormal fee and for outputs to addresses the wallet does not recognise, as a single approval does. The flagged transactions are named, and none of the batch is signed until you confirm their risks.
• A website transaction that lists the account's spending script more than once on an input, or with a Merkle proof that does not match the coin it spends, is refused before the approval opens. It used to fail only after the user approved it, using up one post-quantum signature.

Phishing protection

• A page on the phishing denylist now shows the wallet's warning, with Proceed, however the tab got there: through a redirect, a link wrapper such as t.co or a mail safe-link, a typed URL or a bookmark. Before, only a link the wallet saw first led to the warning, and everything else ended on the browser's "blocked by an extension" page. The extension now asks for access to the denylisted sites, which adds no new install warning. If you restrict the wallet's site access in Chrome, you get the browser's blocked page as before. If the wallet cannot remove its redirect rule, a denylisted page can load until it does.
• If the phishing block rule fails to install when the wallet starts, the wallet now retries it, removes the unused redirect rules of 1.0.4, and reports the rule's state to its diagnostics. Until the rule is in place, the wallet stops a page on its phishing denylist before the page's own script can run, and shows its warning instead. This needs the wallet's site access in Chrome: with "On click" or "On specific sites", a denylisted page can load until the rule is installed.

Keys and vault

• Locking and unlocking the wallet while a signature or account change is waiting no longer loses it: the signature is refused instead of being released without its post-quantum signing count saved, and an account change reports an error instead of success. Retry it once the wallet is unlocked.

Restoring a wallet

• A restored wallet whose address has too long a history to read in full (over 6,400 transactions, or more pending transactions than an Esplora explorer lists) is no longer sign-locked for good. Its signature-counter floor comes from the explorer's address statistics, the same count the full read checks against, and the restore report names the accounts read that way.
• A recovery migration no longer stalls on an account with more than 10,000 transactions. The other accounts move as usual, the migration screen names that account, and it can consolidate its outputs during the migration so that a later pass moves them. One case still stops the whole pass: on a mempool-qbit explorer, an account over the explorer's output limit whose pending transactions fill whole history pages (a multiple of 50) cannot be read until one of them confirms or another arrives.

Settings and contacts

• Changes to sign-data requests, the auto-lock time and replace-by-fee are saved before the setting reports success, so quitting the browser or reloading the extension straight afterwards no longer restores the old value.
• If the wallet cannot read its stored settings when it starts, it no longer replaces them with defaults.
• Default wallet and account names are saved, and a contact edit that cannot be saved shows an error instead of disappearing after a restart.

Repository and release

• The extension ZIP no longer depends on the directory it is built in. Earlier builds embedded the builder's checkout path in background.js, so an independent rebuild matched the CI artifact only from the same path. Packaging now fails when packaged text contains a file:/// URL or a path inside the builder's checkout or home directory.

Known limitations

• For a transaction a website asks the wallet to sign that also spends coins not held at the wallet's own addresses, the fee rate is an estimate and can be shown lower than it is, so the fee warning and its confirmation may not appear. The fee and the amount leaving the wallet, shown first, are exact.
• If the wallet's site access in Chrome is set to "On click" or "On specific sites", a denylisted page can load while the wallet's phishing block rule is not installed, or while the wallet cannot remove its redirect rule.

Verifying this release

• Commit: 40911767b5188f16e43c946ad5cb75206079366b. The tag v1.0.6 is signed with OpenPGP key 05A1 4A41 5C26 F421 6DC2 54FE 52D5 CC55 7D76 4586.
• qbit-chrome-mv3-v1.0.6.zip was built from that commit by CI run 41099884517, which also checked that two clean builds are byte-identical. Its SHA-256 is eef162762ab6b7ba04899da09dd6b209164d7cb96dfff315e5430d4110d4a30e.
• qbit-chrome-mv3-v1.0.6.zip.manifest.json lists the size and SHA-256 of every file in the ZIP.

Unlike 1.0.5, the 1.0.6 build no longer depends on the directory it was built in, so a rebuild in any directory produces the same files.

To rebuild with Node.js 22.22.3 (from .nvmrc), Corepack and unzip:

git clone --branch v1.0.6 https://github.com/Qbit-Org/qbit-wallet.git
cd qbit-wallet
corepack pnpm install --frozen-lockfile
corepack pnpm build:repro:extension

In apps/extension/dist/, the entries of the rebuilt qbit-chrome-mv3-v1.0.6.zip.manifest.json should match the one attached here. See docs/reproducible-builds.md.