Pairing QR codes
Pairing gives your wallet the public keys it needs to show balances and build transactions. In BitTool Signer the user opens a wallet and taps Connect, which has two tabs.
| Wallet level | Coin level | |
|---|---|---|
| QR content | One animated ur:bytes QR code | One QR code per chain and account type |
| Chains | Bitcoin (4 address types), EVM, TRON, Solana (3 presets) | The chain the user selects |
| Format | BitTool's own bittool-signer-wallet v1 | Standard UR types: crypto-account, crypto-hdkey, crypto-multi-accounts, or a plain address |
| Best for | Multi-chain wallets that want one scan | Wallets that already support QR hardware signers (Keystone-style) |
| Supported today by | BitTool Wallet | Sparrow, BlueWallet, MetaMask, Rabby, Solflare and others (see Compatibility) |
Both are read-only exports of the same public keys; the wallet-level code is simply all of them at once. Neither needs the wallet password, and neither contains the phrase, the seed or any private key.
What to store
For every account you import, keep:
| Field | Why |
|---|---|
| Master fingerprint (8 hex digits) | Goes into every signing request so BitTool Signer can find the wallet |
Account path, e.g. m/84'/0'/0' | The prefix of every full path you put in a request |
| Account xpub (Bitcoin, EVM, TRON) | To derive receive and change addresses |
| Script type (Bitcoin) | Decides the address format and the PSBT fields |
| Address and full path (Solana, and TRON or EVM address-only exports) | Solana has no xpub; each preset is one key |
Derive addresses locally from the xpub. Never ask the user for the recovery phrase, and do not try to derive one chain's keys from another chain's xpub.
Let the user verify
BitTool Signer shows the first address of every exported account under the QR code. After importing, show the same addresses in your app and ask the user to compare them in full, not just the first and last characters. This is the only defense against a tampered or mistaken pairing, because the QR code itself is not signed.
Duplicates and re-pairing
- Treat a pairing as the same wallet only if the public keys match. The fingerprint alone is not enough.
- If a new pairing has a known fingerprint but different keys, do not overwrite the existing wallet (a different BIP39 passphrase does exactly this).
- Re-pairing the same keys after reinstalling either app should restore the same wallet, not create a second one.
Network
All exports are mainnet: Bitcoin mainnet, the eight supported EVM networks, TRON mainnet and Solana mainnet-beta. Testnet keys are not exported.