Summary
The mobile pairing flow (mobilePairing in the vault backend) does not export the wallet's known pubkey set. It derives a fresh, fixed list from the device at pairing time using default (account 0) paths only:
- EVM: hardcoded
m/44'/60'/0'/0/0 ("ETH primary (default)")
- UTXO: the three script-type xpubs, account 0 only
- All other chains:
chain.defaultPath
Impact
A user with funds in BTC account 1 or ETH account 2 — accounts the desktop vault itself supports and displays (see the v1.5.1 evmAddressPath() fixes for accounts beyond the first) — pairs their phone and gets a silently under-reported portfolio. There is no indication on either side that coverage is partial.
Suggested fix
Export the wallet's full cached/known pubkey set (all accounts with activity) in the pairing payload instead of re-deriving account-0 defaults. The mobile app already aggregates multi-account payloads correctly (entries are merged per asset), so no mobile-side change is needed — the payload is the only gap.
Notes
🤖 Generated with Claude Code
Summary
The mobile pairing flow (
mobilePairingin the vault backend) does not export the wallet's known pubkey set. It derives a fresh, fixed list from the device at pairing time using default (account 0) paths only:m/44'/60'/0'/0/0("ETH primary (default)")chain.defaultPathImpact
A user with funds in BTC account 1 or ETH account 2 — accounts the desktop vault itself supports and displays (see the v1.5.1
evmAddressPath()fixes for accounts beyond the first) — pairs their phone and gets a silently under-reported portfolio. There is no indication on either side that coverage is partial.Suggested fix
Export the wallet's full cached/known pubkey set (all accounts with activity) in the pairing payload instead of re-deriving account-0 defaults. The mobile app already aggregates multi-account payloads correctly (entries are merged per asset), so no mobile-side change is needed — the payload is the only gap.
Notes
🤖 Generated with Claude Code