0.30.0 is on the update channel and bundled in Theseus 0.3.75 with a Tron
decoder that a hostile site can use to show one transfer and sign another.
This is 0.30.0 plus that fix only; 0.31.0 is still under review.
The decoder read the first copy of a singular protobuf field; java-tron
keeps the last. Any.value is opaque bytes, so a TransferContract carrying
two recipients and two amounts hashes to the same txid either way: the
overlay showed "1 TRX to X" while the chain would move 999 TRX to
another address. It also defeated the plan-time and sign-time draft checks
against a hostile node. A repeated singular field, or a known field with
the wrong wire type, now refuses the transaction.
WalletKeys.entry() built a bech32 p2wpkh address whatever the account
path's purpose, so picking Legacy (D...), Wrapped SegWit (S...) or
Taproot (dgb1p...) in Settings showed a dgb1q address from the BIP44/
49/86 key tree, one no other wallet restoring that path would find.
Each family now derives its own address and script, and spending
supplies what its inputs need (previous tx for P2PKH, redeem script for
P2SH-P2WPKH, tap-tweaked key for Taproot, which is active on DigiByte),
with per-family fee sizes. Unknown purposes are refused instead of
falling back to BIP84.
Also: inputs were signed in selection order but the PSBT orders them by
BIP69, so a spend from two addresses tried to sign each input with the
other's key. They are now signed in the PSBT's order.
approvalRequest passed approve/reject keys the host overlay does not
know, so it showed a lone "OK" button whose id never equalled
"approve": every WizardConnect signing request was refused, and the
HTML body was shown as literal markup. It now passes a Sign action and
plain rows: wallet, input count, each output decoded to a cashaddr on
the wallet's network (or OP_RETURN / raw script), total, and who
broadcasts.
lib/dgb/deps.js is ESM, but in a dev checkout the nearest package.json
is TheseusNavigator's, which says "type": "commonjs"; the import threw
and DigiByte was silently unavailable whenever Theseus ran from the
repo. Shipped installs have no package.json above the add-on, so they
were unaffected. lib/dgb/core and lib/dgb/psbt already carry the same
marker.
The isolated-world relay accepted any postMessage carrying the fixed
tag "aegis-aegis", including one from a cross-origin iframe (an ad,
an embed), and attributed it to the top-level origin and its grants.
The tag now carries a per-load random nonce that only the injected
main-world bridge knows, and both listeners drop events whose source
is not this window. The document_start install path is unchanged.
The overlay for tronWeb-built transactions was built from the dapp's
raw_data JSON, which need not match raw_data_hex: a site could show
"1 TRX to X" and get a signature over anything. lib/tron-decode.js
decodes Transaction.raw from raw_data_hex (contract type, owner, to,
amount, TRC-20 transfer/approve calldata, fee limit, memo); the txID
must match the bytes, every contract's owner must be this wallet, and
unlimited approvals or permission/resource delegation get a danger
action.
sendRawTransaction relayed any signed transaction a site handed it;
it now broadcasts only txids Aegis itself signed.
- signAndSendTransaction signed String(Uint8Array) ("1,2,3,..."), so
every dapp transaction got an invalid signature. Adapters gain
signBytes(), which signs the exact message bytes.
- v0 (VersionedTransaction) messages were parsed with the version byte
as the header; the shared parser handles legacy and v0.
- window.solana.signTransaction went through signMessage and its
"moves no SOL" overlay. It now has its own handler and overlay, and
signMessage refuses bytes that parse as a transaction (Phantom's rule),
since such a signature is a valid transaction signature.
- Overlays decode System transfers and SPL transfer / approve /
set-authority, and list everything else as not decoded.
- eth_sendTransaction dropped the calldata, gas and fee fields, so an
ERC-20 transfer went out as a 0-value send to the token contract and
any contract call was broadcast as something else. plan() now carries
data/gas/fee caps/nonce, estimates gas for calls, and the overlay
decodes transfer/approve/permit/setApprovalForAll, flags unlimited
approvals and calldata to a non-contract, and shows estimated vs max
fee.
- personal_sign signed the hex string ethers/viem send as literal text;
it now signs the decoded bytes.
- wallet_switchEthereumChain flipped the global selected wallet, so any
site could move every connected dapp to another chain. Chain is now
per origin; the sidebar selection no longer redirects a dapp.
- wallet_addEthereumChain silently persisted a connection for chains
Aegis already had, handing the address to any site. Adding a chain
no longer grants anything, and RPC URLs must be https.
- eth_sign (blind hash signing) is disabled, as in MetaMask.
Connecting without ticking "Always allow" stored nothing, so the
site's very next call (personal_sign, signTransaction, ...) failed with
"not connected". Plain Connect now grants the origin in memory until
Theseus restarts; "Always allow" still persists. Every bridge (BCH,
Tron, EVM, Solana) checks grants the same way, revoke clears both, and
the connected-sites list shows EVM/Solana grants and which ones are
session-only.
The 2026-09-13 audit of the dapp bridges found real signing bugs whose
fixes were never committed; 0.30.0 carries them, ported onto the current
add-on.
Aegis was most of what was left of launch cost: its crypto and
WizardConnect deps block the main thread for ~0.6 s right after the first
frame. It now declares its panel and "activation": "on-demand"; the
dapp bridges are still on every page from the start, and the first page
call, panel open or wiz:// link starts it.
activate() returns a promise the host waits on, so the call that woke
Aegis finds WizardConnect and the mounted wallets. With a locked vault it
does not wait for the mount (derive blocks until unlock), so the page gets
the usual locked answer in ~0.7 s instead of after the host's 5 s limit.
Two things only work while Aegis runs: a live WizardConnect pairing (no one
else listens on its relays) and "stay unlocked" (which also opens
Settings > Passwords). While either is on, Aegis asks the host to start it
at launch, and withdraws the request when both are off. Pairings left
behind by a removed wallet do not count.
Boot trace, same profile, 3 warm runs: main thread blocked in the first
6 s 970-1040 ms -> 300-320 ms, longest block 605-667 ms -> 227-244 ms,
toolbar 1.34-1.61 s -> 0.83-0.87 s.
The main-world bridge is appended at document_start, which often runs
before the page has an <html> element. The append threw on null, and the
catch marked the origin as Trusted-Types-blocked in localStorage, so every
later visit skipped window.ethereum, window.solana and the EIP-6963
announcement on that site. On example.com it failed on 6 of 6 loads.
Wait for <html> with a MutationObserver (it fires at the microtask
checkpoint before the first parser-inserted script, so the bridge is still
first), remember only real Trusted Types refusals, and use a new key so the
origins wrongly marked by the old one get the bridge back.
panel.html loaded lib/jsqr.js synchronously: 257 KB and 10,105 lines of
vendored decoder parsed on every panel open, so on every hide/show, for a
feature most sessions never touch. It is now fetched the first time someone
imports a QR image, with concurrent callers sharing one load and a failed
load retryable rather than cached as a permanent rejection.
qr.js and panel.js get `defer`, so the browser can paint the (already dark)
document before executing 300 KB of panel.js. Order is preserved, so qr.js
is still defined before panel.js runs.
Parsed on open: 650 KB -> 399 KB.
This shortens the blank window but does not remove it. The white box itself
is Theseus-side: the sidebar panel's view is built as
new WebContentsView({ webPreferences: { preload: "sidebar-preload.js" } })
with no backgroundColor, and Electron defaults a view's background to white —
so white shows from view-attach until the page paints. Every other view in
the app passes a colour, and registerSidebarPanel takes only
{id, title, icon, page}, so an add-on cannot declare one. Not fixed here:
main.js belongs to the Theseus work in flight.
Second half of the Theseus-lag investigation. 0.27.1 removed the 7.4 MB
store; this removes the two things that produced it and the latency that
came with it.
Measured on this profile's own cache: 6,981 transactions, 7.38 MB, and one
consolidation with 400 inputs (median 2).
- loadHistory() awaited getTx() per displayed transaction and then again per
INPUT, strictly one at a time. The 400-input row alone cost 400 serial
round trips. Both waves are now prefetched with bounded parallelism
(getTxMany, 12 at a time). Against a simulated 10 ms link the same 473
fetches take 771 ms instead of ~4,730 ms; on a real 30-50 ms link the
serial version was 15-25 seconds per refresh, per wallet.
- Parent transactions were persisted forever. They exist only to compute a
delta for the 25 rows on screen, and keeping every one ever seen is what
grew the file. Only the displayed window is written now — 25 entries,
16.4 KB in the harness — while parents stay in a process-lifetime map
bounded at 20,000, seeded from the window so a restart does not refetch
what is already visible. A second refresh issues zero fetches.
TX_CACHE_VERSION 4 discards v3 caches. The v3 cap of 400 was also exactly
the wrong number for this data: a 400-input transaction needs 401 entries,
so it would have evicted and refetched on every single refresh.
Ported from Digibyte.X/dgb-wallet @ 989a2696.
BIP32 builds the master key as HMAC-SHA512("Bitcoin seed", seed). DigiByte's
official 2018-19 Android/iOS wallets were BreadWallet forks and used
"DigiByte seed" as the HMAC key instead, so the same twelve words produce a
completely different key tree — every address differs, and a standard scan
finds nothing at all. Anyone importing one of those seeds into Aegis got a
valid, empty address and a zero balance with no way to tell why. Same shape
as the Bitcoin.com coin-type-0 problem.
- rootFromSeed() in the vendored lib/dgb/core/hd.js takes an optional HMAC
key, matching upstream, and exports HMAC_BITCOIN_SEED /
HMAC_DIGIBYTE_SEED.
- lib/import-derive.js grows the same option, since that is what actually
derives the address on an import, and importWallet records the variant on
the spec so the entry says which tree its stored address came from.
- The path scanner added in 0.24.0 now covers DigiByte: all four purposes
under the standard key, plus m/0' and BIP44 under the legacy one. So the
answer to "which tree holds my coins" is a scan rather than a guess, and
the Use button carries the key along with the path.
Verified against an independent HMAC-SHA512 computation, and end to end: the
same mnemonic gives DG1Khh…N1i under the standard key and DMWQ1g…PHse under
the DigiByte key, both valid, with m/0' deriving DGAf4M…Wyn.
Also fixes a coupling this exposed: lib/import-derive.js derives taproot
addresses but never called initEccLib, relying on chain-btc.js (and formerly
lib/dgb/core/address.js, before it went lazy here) doing it at load time. It
now installs the schnorr backend itself, once, so its taproot output no
longer depends on an unrelated module's import order.
The gap-limit change in 0a5d7ade (scan gap 200/100 for DigiScope parity) is
upstream-only for now — Aegis's imported DGB adapter watches a single stored
address rather than scanning a gap.
Reported as "the Aegis DigiByte import error". The vendored @dgb-wallet/core
modules under lib/dgb/ imported "bitcoinjs-lib", "bip32", "ecpair",
"bip39" and "@bitcoinerlab/secp256k1" as bare specifiers. Node's ESM resolver
walks up from the importing file, so that resolves in a dev checkout — where
Theseus's node_modules sits above the add-on — and resolves nowhere once
Aegis is running from <userData>/extensions/aegis/, which is every OTA
install. The import threw, index.js caught it and set dgbCore = null, and any
DigiByte import then died in digibyteNetwork() with "DGB adapter not
available".
So DigiByte worked on a fresh install and disappeared after the first update.
Confirmed on this machine: the only node_modules reachable from the installed
extension carries bip39 and none of the other four.
lib/dgb/deps.js now holds the dependencies, injected by index.js from
api.require (which resolves against the app tree) before anything under
lib/dgb/ is imported — the same pattern every other lib/*.js in Aegis already
uses, and the reason that pattern exists. Consumers read them through
accessors rather than capturing them at module scope, so import order is no
longer load-bearing: hd.js builds its bip32 on first use and the two
initEccLib callers go through a once-only ensureEcc(). Using a DGB module
without injection now throws a named error instead of a resolver failure
swallowed into a null.
Verified by loading the modules from a directory with no reachable
node_modules and deriving real addresses: BIP44 D…, BIP49 S… with its legacy
3… pair, BIP84 dgb1q…, BIP86 dgb1p… taproot, plus a WIF round-trip and the
non-DGB WIF rejection.
Reported as "opening Aegis makes Theseus get stuck / not responding", and it
was Aegis's fault.
The host's add-on store is ONE JSON file per add-on, and storage.get() does a
readFileSync plus a JSON.parse of the whole thing on every call —
synchronously, on the Electron main thread, the thread that drives the entire
browser. storage.set() additionally stringifies and writes all of it.
That store had grown to 7.4 MB, 99.9% of it one wallet's txCache: getTx()
kept every transaction it ever fetched, with full vin/vout arrays, and a busy
chipnet test wallet had thousands. Measured on the real file: parse 59 ms,
stringify 39 ms. So one storage.get blocked the UI for ~60 ms, one set for
~99 ms, and fullState() — which reads the store seven times over
selectedWalletId, walletRoles, walletEntries, snapshotForSelected and the
server list — cost ~420 ms. emitState() runs on every adapter change, across
nine wallets, so the main thread was never given back.
Three changes:
- txCache is capped at 400 entries, pruned newest-first by block time
(unconfirmed entries sort as newest — they are the current ones). Worst
case ~0.3 MB per wallet instead of unbounded.
- TX_CACHE_VERSION 3, so existing oversized caches are discarded on first
load rather than needing a manual clear.
- loadHistory() only persists when something actually changed; an idle wallet
was rewriting the whole file on every poll for nothing.
- api.storage gains a write-through read cache, so repeated gets cost one
parse per process instead of one per call. Writes still go to the host
unchanged. Safe because this process is the only writer — Aegis's panel
talks over addon messages and never touches addon storage; if that changes,
the cache has to go.
window.bitcoincash was gated on a ".x" hostname in both the preload and the
host handlers — inherited from the pre-multi-wallet build, when every dapp
Aegis knew about was a Silent Mode one. It was never a security boundary: the
TRX / ETH / SOL bridges have always injected everywhere, and every BCH call
still crosses into main, raises an approval overlay and honours per-origin
permissions. The preload cannot read an address or sign anything by itself.
What the gate actually cost was Cauldron, bch.guru and our own dapps on other
TLDs (potidaea.asm) seeing no BCH provider at all, on a wallet whose entire
subject is BCH. WizardConnect was never gated this way, so the two halves of
the same bridge disagreed about who could talk to it.
isBchOrigin becomes isDappOrigin and now only keeps non-web schemes out —
file://, chrome://, data:, javascript: and anything unparseable.
Separately: page-inject declared https://*/* only, so a dapp served from
http://127.0.0.1 got no preload at all, which is a different cause from the
.x gate and would have survived removing it. localhost, 127.0.0.1 and [::1]
are now matched over http as well (the host's compiler makes the port
optional, so :3000 and :5173 are covered). Plain http on any other host stays
out, since an http page is tamperable in transit and only local development
needs the exception.
Two regressions in 0.26.0.
The PIN was still asked after the wallet had painted. pinGateOnLoad() ran
after render() and was not awaited, so the interface appeared — balances and
all — and the pad then opened on top of a panel the user could already read.
It is now awaited before the first render, and `pinGateBlocked` keeps the
chrome hidden for as long as the PIN is owed: render() returns early into a
closed door, state pushes cannot paint around it, and Settings is covered too
(unlike the vault lock, where Settings must stay reachable to create a PIN in
the first place, here it would just be a way around the gate). Cancelling
leaves the door shut with a retry rather than falling through to an open
wallet.
The pad threw digits away mid-entry. render() fires on every state push —
balance polls fire it every couple of seconds — and renderLockScreen()
rebuilt body.innerHTML unconditionally, replacing the pad and its buffer
under the user's fingers. The reset was timed to the poll, not to the
keypress count, which is why it looked like "after two digits". All three
branches are now keyed on body.dataset.mode and rebuild only when the mode
actually changes; the master-password and first-run forms had the same defect
and were erasing half-typed input the same way.
Also: every pad was wired through getElementById, so two pads alive at once
(a load gate plus a transaction gate) were duplicate ids and the second
setupPinPad bound the first pad's buttons. All four are now scoped to their
own container, only one PIN prompt can be open at a time, and setupPinPad
carries a note saying why it must never be handed a global lookup.
Reported: after a restart Aegis opens without asking for a PIN, then demands
one as soon as you click something. That came from the only control being
requirePinForSending — safeStorage remembers the master password, so the
wallet reopens unlocked, and the PIN prompt then ambushes the first action.
Asking at the door is coherent. Asking nothing is coherent. Asking once the
user is already inside is not.
"Ask for PIN" is now four independent triggers, because wanting one at
startup and again per transaction is a normal combination:
- On each browser restart (compares a per-process boot id; a timestamp
cannot tell a restart from a long idle)
- On each wallet launch (hide/show — one panel load is one launch)
- Every 6 hours
- Each transaction
With none ticked, an open wallet is never interrupted again. The decision is
made host-side: the panel reloads on every hide/show and must not be the
thing that remembers a gate was cleared. A clearance is only recorded after
the panel has actually decrypted the PIN blob, which is proof rather than a
claim, and ticking a trigger does not fire it retroactively.
restart defaults ON for a wallet that otherwise reopens fully unlocked, and
transaction inherits the old requirePinForSending so nobody loses a gate they
had chosen. Removing the PIN clears every trigger and the clearance record.
Every history row and Explorer button on an imported chipnet wallet opened
https://chipnet.imaginary.cash/tx/… , whose web interface has been returning
502 for weeks. chain-bch.js was moved to our own explorer and this adapter
was missed — which is most chipnet wallets in practice, since a keystore bulk
import produces imported ones.
Points at https://aegis.x/explorer/chipnet/ like the HD adapter. The host's
Electrum endpoint on :50004 is a separate thing and is still in use.
Three separate reasons the Refresh button looked dead:
- wallet.js refresh() returned immediately when state.scanning was set, so a
manual press during a background poll did nothing at all. A forced refresh
now awaits the in-flight pass and then does real work; background polls
still yield. scanning is only ever written inside doRefresh, which only
refresh() calls, so scanning implies a pending inflight to wait on.
- The adapters catch their own fetch failures onto state.error instead of
rejecting, so awaiting refresh() proved nothing and refreshChain reported
ok:true for a wallet that had just failed against a dead server. It now
reads the snapshot back.
- Success changed only a tooltip. Balances that were already current left the
screen identical, which is indistinguishable from a broken button. It now
flashes a result and says how many wallets were refreshed, or how many
failed and why.
Version bumped once for this batch; not published yet.
The coin drilldown header carried "← Back" on its left and ✕ on its right.
They were bound to the same handler and carried the same tooltip, so the row
spent its left edge on a duplicate of the control at its right edge. ✕ stays;
the title now starts at the left edge, which .wctitle already handled via
flex: 1.
Switching network on the new header chips moved the selected wallet but left
the list below it alone. In the addresses drilldown stripView.groupKey pins
"<chain>:<network>", so the header read chipnet while the rows underneath
were still mainnet addresses.
The chip now retargets that groupKey when the drilldown belongs to the chain
being switched, and leaves a drilldown on any other chain alone. The coins
view already keyed off activeNetworkByChain and needed nothing.
Switching also lands on whichever wallet that network was last left on
instead of the first in list order, which means row clicks have to record
that — otherwise picking a wallet, leaving the network and coming back
returned somewhere else.
The header read bottom-up. The balance sat under a row of connection detail,
and the network you were on was reported in that status row while the control
that could actually change it was a chip row buried in the picker's coin
drilldown — two places for one idea, with the useful half two clicks deep and
only reachable from inside a wallet list.
Reordered to match what people open the panel for:
1. wallet label
2. balance and portfolio
3. network selector
4. connection status and the per-wallet verbs (Explorer, Faucet)
The selector and the indicator are now the same control: a chip per network
this coin has wallets on, the active one marked, always present while a
wallet is selected. Switching picks a wallet on that network and keeps the
picker's per-chain network memory in step, so the two views cannot disagree.
A single-network chain still renders its one chip. It is the indicator the
status row used to carry, and hiding it would make the header height jump as
you move between chains. A testnet whose label already says so (Chipnet
testnet) no longer also gets a TEST tag; Nile and Sepolia still do.
A seed import offered exactly one prefilled path and no alternatives, so a
seed from a wallet on a different path derived a valid but empty address and
reported a 0 balance. Nothing distinguished "wrong path" from "empty wallet",
which is why repeated imports of a funded wallet all looked identical.
Both real cases hit it. Bitcoin.com derives mainnet BCH from coin type 0' —
its Copay lineage predates the 145' split — while Aegis prefilled
m/44'/145'/0'/0/0. And chipnet tooling derives from 145', while Aegis
prefilled BIP44's testnet 1'.
- A preset dropdown per coin and network, each entry naming the wallets that
path belongs to, with the free-text field kept for anything unlisted.
- "Check which path has my funds" derives each candidate and asks Electrum
for balance and history, five addresses deep per candidate so a wallet
whose first address is spent clean is still found. Results are listed with
balances and a one-click Use; when nothing matches, it says so instead of
implying the wallet is empty.
- The chipnet IMPORT prefill becomes 145'. The vault-derived chipnet account
path stays m/44'/1'/0' — changing that would move the addresses of wallets
that already exist.
The scan derives, queries and returns counts; it stores nothing, and the
mnemonic crosses the same boundary importWallet already uses.
Reported as "WizardConnect pairing is done only via Mainnet, chipnet is not
available on UI". Chipnet pairing works and is not filtered anywhere: the
Connect pane reads state.wallets unfiltered, wcPairableWallets() keys only on
chain/phase/eligibility, and startForWallet registers every BCH wallet
whatever its network. The profile even holds a live wc:// URI against
bch-chipnet-0, so a chipnet wallet has already paired.
What it actually was: the picker listed wallets in registry order, and a bulk
keystore import put fifteen unpairable chipnet WIF wallets ahead of the two
chipnet HD wallets that pair fine. Every visible row was a greyed-out
"can't pair" testnet entry, so the list read as "chipnet is unsupported"
while the working options sat at positions 17 and 19 of 19.
Group the select instead: "Can pair" first, "Cannot pair" after. The reasons
stay visible — they were asked for, and a wallet greyed out with no
explanation reads as broken — but they no longer hide the wallets that work.
Only a WIF import is ineligible, because hdwalletv1 hands the dapp an xpub
and one key is not a key tree. Promote to HD (0.11.0) remains the fix for
those.
Getting a key back out of Aegis only worked for wallets it derived itself.
Every imported adapter's recovery() returned xprv:null with "Recovery lives
in the source of the import", so the wallets most likely to need exporting
were the ones that refused, and the vault-derived ones handed over an xprv
behind nothing but an approval click.
There is one gate now, and it is enforced in the host. revealSecret takes the
master password and verifies it with vault.lifecycle.unlock before it reads
anything; the panel obtains that password either by decrypting the PIN blob,
which wraps exactly it, or by asking. Both routes end at the same proof, so
the host never takes the panel's word for authorisation. The old
recovery({reveal:true}) path is gone and all six Settings buttons route here.
Three wrong PINs switch to the master password rather than dead-ending, and
those attempts still count toward the existing 15-minute lockout, so a
fumbled PIN costs nothing and a guessed one gains nothing. Being locked out
of the PIN also falls through to the password: the lockout exists to stop PIN
guessing, not to lock an owner out of their own key.
"Use PIN to show secret keys" defaults ON, unlike the send flag — a send is
already fronted by an approval overlay, whereas a revealed key is
irreversible the moment it is on screen. Turning it off moves the prompt to
the master password. There is deliberately no setting that reveals a key
without asking for anything.
It is NOT called a recovery phrase, because Aegis has none to show. An import
stores mnemonicToSeedHex(words) and discards the words, vault wallets are
HKDF(vault root, purpose) and never had words, and password-vault.js is
explicit that the seed is never persisted. So each form names itself — WIF,
private key (hex), wallet seed (hex), wallet key (hex) — and says where it
can actually be restored. Someone who writes down what this shows believing
it is twelve words has backed up nothing, which is the one outcome this
screen has to prevent.
A WizardConnect pairing could land on an address the user had never seen.
Pairing took the selected wallet when it qualified and otherwise the first
pairable one in list order, so with the selected wallet ineligible (a WIF
import has no xpub) it silently fell through to whichever wallet happened to
be first. The approval named that wallet by label only, which does not help
when the label is one Aegis generated.
Three changes, one idea: the wallet a purpose uses should be something you
said, not something that fell out of list order.
- Roles. A wallet can be nominated for payments and/or for WizardConnect,
set from its manage modal and badged on its row. A role that points at a
removed wallet reads back as null instead of being trusted, so a stale
pointer can never quietly redirect a payment.
- The pairing approval asks. With more than one candidate it offers a
dropdown of them, each labelled with its own short address; with only one
it shows that wallet's full address. The rows are static, so naming a
wallet above a select the user can change would contradict itself — hence
one or the other, never both. The panel's own Connect pane now follows the
same precedence, because two rules for "which wallet" is how a pairing
surprises someone.
- Send gets a From row listing the wallets on this coin and network, with
balances. It switches the panel selection rather than carrying a separate
source: planSend and send resolve the wallet host-side from that, and a
second notion of "current" would let the form and the approval disagree.
Payments also becomes the opening selection when nothing has been picked yet,
which is what nominating it is for.
No Theseus release needed — approvalModal has supported a select row all
along, and the pick comes back as "allow+wallet=<id>", validated against the
options offered.
Went looking for a performance fix and found a correctness bug underneath it.
getTx() slims each transaction on the way into the cache, and the slim shape
kept only { value, scriptHex } — dropping vout.tokenData. That field is where
the server reports CashTokens. It is NOT in scriptPubKey.hex, which Fulcrum
returns with the token prefix already stripped. So the classify pass fetched
one transaction per UTXO, looked for a prefix that was never there, and
concluded "no token" every single time.
Measured against a real chipnet wallet (130 UTXOs, 91 of them token-bearing):
the old pass cost 54 requests for that address and found 0 tokens; sampling
12 of those transactions, exactly 0 had a scriptPubKey starting with the
token prefix. On the faucet-fed address with 28,289 UTXOs it was ~28k
requests, still finding nothing — which is what made the wallet look hung.
So HD BCH wallets have never shown CashTokens. 0.15.0 fixed the imported
adapter, which reads token_data off listunspent, and I took the HD path's
silence for an empty wallet.
Now: when the server negotiated protocol >= 1.5, listunspent carries
token_data and a UTXO WITHOUT it is definitively not token-bearing, so the
whole set is classified from the one call we already make — 1 request instead
of 28,289. Below 1.5 the fallback fetches parents as before but reads
vout.tokenData (present even at 1.4) and only decodes a prefix as a last
resort, so it is correct now too.
Both routes are reconciled onto one shape. They speak different dialects:
the decoder yields a numeric capability (0/1/2) labelled
immutable/mutable/minting, while Electrum sends a string and calls 0 "none".
Left alone, an identical UTXO would have described itself differently
depending on which server answered. The decoder's vocabulary wins, and the
Certificates pane treats immutable as the quiet default so only capabilities
that change what the holder can do get a tag.
txCache is versioned and dropped once: entries written by the old shape carry
no token information, and an absent field cannot be told apart from "no
token", so a warm cache on a pre-1.5 server would have reported a token
wallet as empty.
Verified against the live wallet: one request, 91 token UTXOs, 46 categories,
17 assets, 51 certificates — matching what the panel reports — with
capability labels normalised (5 immutable, 28 mutable, 18 minting).
Assets was one list holding two different kinds of thing. A fungible balance
answers "how much do I have"; a non-fungible one answers "which ones do I
hold", and they want different rows — an amount against a symbol, versus a
commitment and a capability. On a real chipnet wallet that meant 46 rows
where 32 of them were only ever going to say "1 NFT".
Split by what each category actually holds, so a category carrying both
appears in both — which is honest, because it really does hold both. Assets
counts categories; Certificates counts individual certificates, since "3"
should mean three things you hold rather than three groups.
Certificate rows carry the commitment, because it is the only thing that
distinguishes two certificates of the same category, and a MINTING or MUTABLE
tag, because "can still issue others" versus "is fixed" is worth seeing
without opening anything. A `none` capability is left unlabelled rather than
adding noise to every row.
"Certificates", not "NFTs": these are membership, licence and record tokens,
and NFT carries collectible-market baggage that misdescribes them. Ids and
data keys stay `nft` — that is the CashTokens protocol field, so it is
protocol name inside and product name on screen.
Two things caught while building it. `draw({})` was overwriting the "no
assets" empty state with an empty string, which is now the common case since
purely-non-fungible categories no longer appear there. And certificate rows
printed the category twice, as the title and again on the right — the right
column now only carries it when the row has a real name to lead with.
Metadata is looked up for every category, not just the fungible ones, so
naming a token also names its certificates.
The Receive tab carried two stacked toggle rows: Receive/Consolidate above
Address & QR/Assets. That is a lot of chrome for a 380px panel, and the two
rows were not the same kind of thing — Address and Assets are views of the
wallet, while consolidating is an action on its UTXO set. Consolidate now
sits with the other address actions, beside "Next unused address", with the
sibling count on the button.
The old toggle was also the only way out of the consolidate view, so that
view gains its own "← Back to address". Entering still resets the inline host
so the preview is costed fresh, which is what the toggle did.
The Send tab keeps its Send/Consolidate toggle: there, consolidating really
is an alternative way to send, so a toggle is the right shape.
Removed the two now-dead [data-rcv-mode] blocks rather than leaving selectors
that match nothing.
Verified by real visibility rather than the hidden attribute — a child of a
hidden parent keeps hidden=false, which made a first check look like both
panes were showing at once. rcvNormal and the address pane go away while the
consolidate pane shows, and Back restores them.
Assets listed but every row read as a hex string. Three separate reasons.
**Both default registries were dead.** Checked 2026-09-29:
raw.githubusercontent.com/cashonize/registry/main/bcmr.json returns 404, and
bcmr.salemkode.com does not resolve. So no token resolved a name on any
chain, mainnet included — and the panel's `.catch(() => {})` meant the
failure was completely silent, indistinguishable from a token nobody has
registered. Replaced with OpenTokenRegistry, which answers and carries
chipnet identities. A dead registry is now reported instead of swallowed:
the reply says whether any registry answered, and the hint says so.
**The tokens in question publish no metadata at all.** Not a wallet problem
and not fixable by any registry list: their genesis transactions carry no
OP_RETURN whatsoever, so there is no BCMR authchain to follow and no
registry entry to find. Their names exist only inside the app that minted
them. So a token can now be named locally, per category, stored under
bcmr/local/<cat> and taking precedence over any registry — with a YOURS tag
so a self-assigned name is never mistaken for a published one. Clearing both
fields removes it and lets a registry entry show through again. Optional
decimals, because a raw fungible amount with no scale is its own kind of
wrong: 15000 became "150 GMX" once told there were two.
**The unnamed row printed the category twice**, once as the name fallback and
once as the sub-line. Unnamed rows now show the category as the identity and
"unnamed token · N UTXOs" beneath it.
The header comment also promised a bundled static registry fallback for
well-known tokens. There is no such directory and no load path for one; the
comment is gone rather than left to mislead.
Verified against the real module: local names beat registry entries, a
category with only a local name resolves instead of returning null, clearing
restores the registry value, out-of-range decimals are dropped, and the new
default registry resolves a real chipnet identity (OTRC, 6 decimals). In the
panel: naming a token repaints it with the tag and rescales the amount, and a
non-numeric decimals entry is refused with the modal left open.
Two changes to the same idea: one way to do each thing, and the same shape
for every coin.
**Assets is no longer buried under the QR.** The Receive body stacked
address → QR → assets in one column, so in a 380px panel the token list sat
permanently below the fold behind 200px of QR — and a coin holding no tokens
simply lost a section, which made every coin look structurally different.
Address & QR and Assets are now peers behind a persistent chip row. The count
rides on the chip, and a wallet with nothing says "No assets held by this
wallet" instead of the section vanishing. That mattered more than it sounds:
a chipnet wallet with 46 CashToken categories was indistinguishable from an
empty one until 0.15.0, because the only signal was an absent card.
The choice persists across re-renders and wallet switches — comparing token
balances between wallets should not throw you back to the QR on every click.
Switching back to Address redraws the QR, since a canvas sized while hidden
comes out blank and renderReceive only repaints when the address changes.
**The coin row's ▾ network dropdown is gone.** The coin view already carries
real network chips (data-browse-net: they filter the wallet list and show a
per-network count), so the popover was a second control for one job — and the
only one that hid its options behind a click. Chips are the single network
control now and the ticker is plain text again.
Verified in the panel: chips switch panes and track their own state, the
count shows, the empty state reads correctly, the QR survives the round trip,
and no .wchev / .wcname.wswitchable remain in the DOM.
Aegis negotiated a flat protocol "1.4". Measured against Fulcrum 2.1.0 on
chipnet, for a wallet holding CashTokens:
asked "1.4" -> negotiated 1.4 -> 39 utxos, 0 with token_data
asked ["1.4","1.5.3"] -> negotiated 1.5.3 -> 130 utxos, 91 with token_data
So 1.4 did not merely omit the `token_data` field — Fulcrum left the
token-bearing outputs out of listunspent altogether. Ninety-one UTXOs were
invisible to the wallet, along with the BCH sitting in them. That is a
balance-correctness bug, not only a missing Assets card, and it applied to
the HD path too, since lib/wallet.js reads the same listunspent.
Now a [min, max] range: a modern server picks 1.5.3, an older one still
settles on 1.4, so nothing that worked before stops working. The negotiated
version is recorded on the client for diagnosis.
Second half: the imported BCH adapter had no CashToken code at all — it never
set tokenBalances and snapshot() never exposed it, so the panel's Assets card
was hidden for every WIF import however many tokens the address held. A
chipnet test wallet with 46 categories showed nothing. It now aggregates from
the server's own token_data, which costs one call for the whole set rather
than the per-UTXO transaction fetch the HD path uses, and emits the same
serialised shape the panel already reads. Verified against that wallet: 130
UTXOs, 46 categories, 17 fungible, 32 with NFTs, JSON-clean.
Found because the user said their asset "uses a different asset category" and
suggested checking with the explorer. It is ordinary CashTokens; the wallet
simply could not see them. My earlier conclusion that the empty Assets card
was correct came from probing a single address that genuinely holds no tokens
and generalising from it.
Importing a Bitcoin.com seed showed a balance of zero. Two causes, one mine.
Mine: a Copay / Bitcoin.com backup QR is "1|<words>|<network>|<ACCOUNT
path>|…", and 0.13.2 dropped that path straight into a box whose contents are
derived as a LEAF. Deriving the account node itself yields an address the
wallet has never used — for the standard BIP39 vector,
qr96x72dpwrjmg8gtmfemmdhn6u8aqdgnvn4fp2906 instead of
qqyx49mu0kkn9ftfj6hje6g2wfer34yfnq5tahq3q6. An address with no history, so:
zero. An account path now extends to /0/0 instead of being derived in place.
The deeper one: a seed import mounted on the single-address adapter, which
watches exactly one scripthash. Bitcoin.com, Electron Cash and the rest
spread funds across a whole BIP44 account, so even with the right leaf the
balance only shows if it all happens to sit on the first receive address.
A seed import is an HD wallet and now mounts as one — the same BchWallet the
vault-derived wallets use, whose WalletKeys walks receive AND change to a gap
limit of 20. That is what actually finds the money, and it brings real spend
support to seed imports as a side effect.
WIF imports are unchanged: one key is one address, nothing to scan.
Existing seed imports are picked up without re-importing. accountPath is
stored in either shape — older imports kept the full leaf, the QR carries the
account — and the mount trims both to the last hardened element before
handing it to WalletKeys. The stale display address stored at import time is
irrelevant, since the panel reads the address off the adapter's snapshot.
Mounting now reads the signer up front to decide which adapter to use. A
locked vault still mounts watch-only from the stored address rather than
failing, and the WC manager gets its own copy of the root because it keeps a
live reference for the per-URI relay-identity HKDF.
A real export read "1|buffalo body coyote poem …" and was rejected: the
classifier only accepted a bare phrase, so a version marker in front of the
words was enough to make a valid seed look like junk.
Wallets wrap the phrase in their own envelope — a version number, sometimes
a derivation path, pipe- or comma-separated, sometimes JSON. Rather than
guess which wallet produced it, the payload is now split on every run of
non-letters (spaces survive, since they separate the words) and any
BIP39-shaped run in the pieces is taken as the phrase. A derivation path
found anywhere in the original string is carried over too.
Being tolerant of the wrapper does not loosen what counts as a phrase: the
pieces must still be 12/15/18/21/24 words of 3-8 lowercase letters, so a URL
or an address breaks into single-word pieces and matches nothing. Verified
that the phishing-URL and address cases still fill no field.
The path only lands in the box when the box is empty. That field is
prefilled with the coin's default and may have been edited, and silently
changing which addresses get derived is what lost funds look like; if a path
is already there and differs, the message names both and leaves the choice
to the user. The unrecognised-payload preview also grew to 90 characters,
since 48 truncated the evidence needed to tell what a rejected QR actually
contained.
chipnet.imaginary.cash's web explorer is returning 502, so every "Explorer"
button on a chipnet wallet led to a Bad Gateway. Its Electrum endpoint on
:50004 is a separate service and is fine — balances, history and the send
path were never affected, which is worth stating because a dead explorer
link looks like a dead wallet.
The explorer now resolves transactions as well as addresses, so it can back
both links rather than half of them. One search box: 64 hex characters is
treated as a transaction id, anything else goes to the cashaddr decoder so
it can complain precisely. A transaction shows confirmations, total out,
size and timestamp, its inputs as links to the parent transactions, and its
outputs as links to the receiving addresses — in-page, without a reload.
Inputs deliberately show no amount: Electrum does not resolve it, and
fetching every parent transaction to display one number is not worth the
round-trips.
Aegis's chipnet explorerTx/explorerAddr now point there. Same chain data,
read over the same Electrum connection the wallet already trusts, and a page
we can fix ourselves the next time one breaks. Mainnet is untouched.
Import accepts a picture of a QR code. The file is decoded in the panel by
the vendored jsQR, drawn to a canvas: no upload, no network, no camera.
Image, not camera, on purpose. Theseus sets blockCamera + hideMediaDevices
by default and hides device labels from fingerprinting; a camera scanner
would fail silently for everyone until they turned that off globally, and a
wallet should not be the reason a privacy browser gives up the camera. A
photo or screenshot of the code needs no permission at all.
What comes back is classified, never trusted. A QR is opaque to the person
holding it, and "scan this to restore your wallet" is a working phish, so
the decode only chooses which field to fill:
BIP39-shaped (12/15/18/21/24 lowercase words) -> mnemonic field
WIF or 32-byte hex -> private key field
anything else -> nothing is filled; the
decoded text is shown so
the user can see it was a
URL, an address, or junk
Nothing auto-submits. The user reads what landed in the box and presses
Import, and the host handler still does the real validation.
jsQR 1.4.0 is vendored at lib/jsqr.js under Apache-2.0 with its LICENSE
beside it, unmodified and unminified — code that touches seed phrases should
be auditable in the shipped add-on, not an opaque blob. It is 57 KB gzipped.
Verified by round-tripping through the shipped path: Aegis's own encoder
builds the QR, it is rasterised to a real PNG File, and decodeQrFile() reads
it back byte-exact; an image with no code returns null rather than throwing;
and driving the actual file input fills the mnemonic for a seed, fills the
key field for a WIF, and leaves every field untouched for a phishing URL.
The 380px panel is the wrong shape for anything that needs room. This opens
the wallet as a full Theseus tab, with the sidebar's own furniture — identity,
network, balance, section nav, wallet list — laid out as a left rail and the
tab body given to the selected section.
It is the SAME panel.html, loaded with ?surface=web. No second wallet, no
second copy of 4,600 lines to drift apart. That works because an add-on's own
tab is handed a window.silentmode with the same invoke/on surface as the
sidebar, and addon-msg dispatches it as from:"panel" with the add-on identity
derived from the file:// sender — so every existing handler, including the
panel-only ones, works there untouched. The whole change is a CSS grid behind
one attribute plus a chip to open it.
Details that needed care:
- The QR is drag-sized against a 380px panel and the size is remembered.
Given a 720px column it filled the page, so it is capped on this surface
only; the stored sidebar preference is left exactly as the user set it.
- #drop (the coin picker sheet) is fixed-position and sized for the panel;
it is pinned to the rail instead of covering the window.
- Content columns are capped at 720px so forms and lists keep the measure
the sidebar already tuned, rather than stretching across a monitor.
- Under 900px the grid falls back to the stacked layout, so a narrow window
degrades to what the sidebar already does.
- The "open full screen" chip hides itself on the full-screen surface, so it
cannot open a second copy of itself.
Everything is scoped to [data-surface="web"], so the sidebar is byte-for-byte
unchanged. Verified both surfaces, the narrow fallback (by exercising the
real media rule) and zero horizontal overflow.
The aegis.x/app URL still needs a main.js route in Theseus; this ships the
destination over the add-on channel first.
A wallet imported from a single private key cannot do WizardConnect, and no
amount of work inside Aegis changes that: the handshake ships BIP32 xpubs so
the dapp derives addresses without further round-trips, and a lone key has no
chain code to build one from. Manufacturing a parent whose child equals a
given key means inverting HMAC-SHA512, and even solved for index 0 the dapp's
next index lands elsewhere. The way out is to stop being a single-key wallet.
Promote derives a fresh wallet from the vault on the import's own network and
sweeps the key into it, after which WizardConnect works — and so does every
other thing that assumes a key tree. It reuses plan() + signAndBroadcast(),
the same pair the consolidate flow already spends through, rather than
growing a second money path.
Three things it deliberately does not do:
- The preview costs the sweep by planning a send-max to the wallet's OWN
address, so cancelling leaves nothing behind. Same inputs, same single
P2PKH output, so the fee is identical to the real sweep.
- The imported key is kept, not deleted. The sweep is unconfirmed when the
call returns and anyone holding the old address can still pay into it;
removing the key there would strand those coins. Removal stays a separate
step the user takes once the balance reads zero.
- A promote that fails in plan() takes the just-created wallet back out,
since nothing was broadcast. Past that point the wallet is kept even on
error, because a transaction may already be on the wire and its
destination has to stay visible.
BCH only: the BTC/DGB/ETH/TRX/SOL imported adapters still throw "read-only"
from plan(), and the refusal now names the chain instead of failing vaguely.
Wallet creation is lifted out of the addWallet handler into
createVaultWallet so promote builds its destination through exactly the same
purpose allocation, legacy-purpose carry-over and id numbering as the Add
flow, instead of a near-copy sitting next to a transfer.
Eight decimals of tail sat exactly where the eye lands. The hero now shows
two decimals once there is a whole part, because the whole units already
carry the significant digits, and digs past leading zeros otherwise so
amounts under 1 keep roughly four significant figures:
1204.23234145 -> 1,204.23 0.23234145 -> 0.2323
0.00012345 -> 0.0001234 0.00000001 -> 0.00000001
A flat "two decimal places" rule is the obvious version of this and it is
wrong: it renders 0.00042 BCH as 0.00 and the wallet reads as empty. The
rule here never collapses a non-zero balance to zeros, and it truncates
rather than rounds, so the figure shown is never more than the wallet holds
and sending the displayed amount always clears. An ellipsis marks the cut,
hover gives the exact figure, clicking pins full precision and is
remembered. Only this hero abbreviates — Send, MAX, history and the wallet
strip still call fmtBig, so every number acted on is exact.
Also repairs the regexes in the same function, which lost their backslashes
when the earlier commit was scripted: /^(-?)(\d+)(\.\d+)?$/ had become
/^(-?)(d+)(.d+)?$/, matching the letter "d". Still valid JS, so it parsed
cleanly and every balance quietly fell through to unformatted text — the
grouping and the dimmed decimals introduced in bb639a9 had never once run.
Caught by testing the function body extracted from the file rather than a
transcription of it.
The network chip sat on its own row holding a single chip and ~300px of dead
space, while the connection state and the per-wallet actions sat on a second
row underneath the balance. Two thin rows sandwiching the number people open
the panel for pushed it into the middle of the header. They are now one row
above it: [network] [state] ......... [Explorer] [Faucet].
Neither half belongs in Settings. The status line is not a hostname label —
it is also where "connecting…", "· syncing", "· <n> unconfirmed" and the
walletd setup prompt are written, so filing it away would hide an unconfirmed
balance and an instruction. Explorer and Faucet are verbs on the selected
wallet rather than configuration, which is why 0.9.2 lifted them out of the
Receive card in the first place.
Only the hostname may shrink. Left to itself the flexbox took width off the
network chip first and clipped "Chipnet testnet" to "Chipnet" — the one label
on that row that must never be ambiguous, since it says whether the next
action moves real money.
First pass of the wallet-app restyle. The panel led with a 22px balance that
carried no more weight than the labels around it, so the one number people
open the sidebar to read had to be hunted for. It is now the hero: 32px,
thousands-grouped, with the fractional part dimmed so magnitude reads before
precision. The ticker and the fiat conversion sit on its baseline as
annotations rather than peers, and wrap to their own line intact once the
amount outgrows a narrow panel.
The Receive/Send/History/Settings bar used an underline for the active tab,
which read as browser chrome and all but vanished at sidebar widths — a 2px
rule under a short label is easy to miss. It is a segmented pill bar now,
active section filled in the accent. The hover tint derives from --ink so it
shows in the light theme too, where a white overlay was invisible.
No charts yet: there is no price history behind Coin-Spectrum to draw, so
nothing here fakes a trend line.
Every chipnet wallet in the picker read "can't pair" with the reason
nowhere on screen: the explanatory note only rendered when NOTHING could
pair, so one working mainnet wallet hid it entirely. The cause now rides
on the row itself ("can't pair (WIF import)") and the note appears
whenever any wallet is blocked. A single private key has no chain code,
so there is no xpub for the handshake to send — the text now says that
and points at the two ways out.
Seed-imported wallets stored the full leaf path (m/44'/1'/0'/0/0) in
accountPath, because that is what derived the one address the strip
shows. WizardConnect was handed that as the BIP44 *account* node and
would derive m/44'/1'/0'/0/0/<branch>/<i>: a tree the user holds no keys
in. Pairing looked healthy and every sign request failed with "no path
for input". Same class as the 0.9.7 chipnet mismatch, one level down.
A dapp drops its pairing code from the DOM once connected, so the
commonest empty scan is a page that is already paired. Sending that user
to "open the Connect dialog" points at a dialog the dapp will not show
again; the message now names the existing pairing instead.
Each .warow was its own grid container, so the `auto` amount column
resolved independently per row: a row holding 0.3066756 got a narrower
column than one holding 0.43789841, and the copy button therefore landed
at a different x on every line. Column widths have to be SHARED to line
up, and nothing was sharing them.
The columns are now declared once on a .walist wrapper and every row
inherits them via `grid-template-columns: subgrid`. Column gaps moved to
the parent, since a subgrid takes its gutters in the subgridded axis from
the grid it inherits and would have ignored them on the row. A
@supports fallback pins the amount column to a fixed 104px for any host
without subgrid, which keeps the copy column straight there too.
Measured across six rows with four different amount lengths, at 260,
320, 400 and 520px wide: copy left edge, amount right edge, ticker left
edge and menu right edge all have 0px spread, with no row overflow and
no clipped amount.
0.9.8 claimed this area was verified, but the check only looked for cell
overlap WITHIN each row and never compared the same column ACROSS rows —
which is exactly the defect it missed.
The main-world bridge was pushed into every https page as a text script.
Sites that enforce Trusted Types refuse that and report the attempt to
their CSP endpoint — Google's sign-in pages among them, which then have
every reason to call the browser insecure. No dapp lives on those
origins: a static list of the big enforcing sites is skipped outright,
any other origin that rejects the bridge once is remembered and skipped
from then on, and where Trusted Types exist unenforced a policy keeps
the assignment clean.
The row's grid template still described the pre-0.9.2 layout — six
columns including an address cell that no longer exists — while the row
renders five. Every cell therefore sat one column left of where it
belonged: copy landed in the label's space, the amount in the old label
column, and the ⋯ in the amount column instead of the edge. That is the
whole cause of "the copy button collides with the amount" and "the last
edit button is not on the edge".
Now five columns for five cells: icon · label · copy · amount · menu,
8px gaps. The label is the flexible one, left-aligned, so it takes the
slack and truncates rather than squeezing the number. Verified at 520,
400 and 300px: no cell overlap at any width, no row overflow, and the
amount never clips — only long labels give way.
The copy glyph was the 📋 emoji, which has no glyph in this platform's
font stack and rendered as a tofu box that read like a stray character
stuck to the balance. Replaced with an inline SVG in both the row and
the address card. Both confirmation flashes now swap innerHTML rather
than textContent, which would have deleted the SVG and left a blank
square.
Address card: the address and its copy button share one row, so the
button sits at the end of the value it copies. The address clamps to two
lines and truncates beyond that instead of growing the card in a narrow
sidebar.
The QR is always visible and the panel is drag-resizable from a grip
under it (pointer events, arrow keys as a non-mouse path, clamped
90–420px, capped against the panel's own width so a size set on a wide
sidebar cannot overflow a narrow one, persisted). That replaces the
0.9.2 show/hide toggle — a size set once beats a binary, and it frees
the row Copy was sharing with a QR button.
drawQr was setting cv.style.width/height, which would have reset the
panel to its intrinsic size on every redraw — i.e. every time the
address changed. It now sets only the backing store and re-asserts the
user's size after drawing.
"Next unused address" is correct at the adapter level on both mainnet
and chipnet (tested: the index advances and the address changes), so the
reported failure is elsewhere. The handler was discarding the error and
flashing a bare "Failed", which is why there was nothing to diagnose; it
now surfaces the real message.
A chipnet BCH wallet derives from m/44'/1'/0', but the WizardConnect
registration fell back to a hardcoded m/44'/145'/0' whenever the entry
had no explicit accountPath — which is the normal case for a wallet
created through the UI. Mainnet's default happens to be that same
literal, so only chipnet was affected.
The consequence was worse than a failed pairing. Pairing SUCCEEDED, the
handshake carried xpubs for an unrelated key tree, and the dapp then
derived addresses this wallet does not own:
wallet's real chipnet address : bchtest:qpezx8qkwpjd4e6pd5aang0ve6fctpjvg5ckp2lwu7
address from the WC xpub : bchtest:qzvpe3w9rqnszk6mntnef6zv6v94zmfvpc49qkxml4
So the dapp saw an empty stranger's wallet, and anything it built spent
inputs the wallet could not match — signing would fail with "no path for
input". Silent, and only reachable on testnet.
Both registration sites (vault-derived and imported) now take the path
from adapter.snapshot().accountPath, which is by construction the tree
the wallet actually derives its addresses from.
Two wrong turns worth recording. defaultAccountPathFor() takes the coin
CONFIG object, not a chain string, so passing entry.chain returned null
and would have stopped WizardConnect registering at all — strictly worse
than the bug being fixed. chainMeta().defaultAccountPath was no better:
BCH has no coinType in COINS, so it is null for every BCH network. The
adapter is the only component that resolves this correctly, which is why
it is now the source.
