Test vectors
Every QR code, signature and address on this site comes from these files. They were produced by running the BitTool Signer engine (the same JavaScript bundle the iOS app ships) with the public BIP39 test phrase, and every signature was verified with an independent library.
abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
Anyone can derive the keys for these addresses. Never send funds to them. All transactions are synthetic (made-up previous outputs, reference blocks and blockhashes) and were never broadcast.
Downloads
| File | Contents |
|---|---|
wallet-pairing.json | The wallet-level pairing object, inner CBOR, UR CBOR, all frames, and the first address of each account |
coin-level-exports.json | Every coin-level export: all Bitcoin profiles, multisig cosigners, EVM, the three Solana presets, and the plain-address exports |
signing.json | All signing round trips: request frames and CBOR, decoded fields, response frames and CBOR, signature, and the assembled transaction |
walletconnect.json | WalletConnect requests and results for the seven worked examples |
recovery-phrase.json | BIP39 seeds, fingerprints and first addresses, with and without a passphrase |
Signing vectors
| Name | Chain | What |
|---|---|---|
btc-p2wpkh | Bitcoin | P2WPKH spend with change output |
btc-p2tr | Bitcoin | Taproot key-path spend (witness UTXO only) |
evm-eth-transfer | Ethereum | EIP-1559 ETH transfer (data-type 4) |
evm-erc20-transfer | Ethereum | USDT transfer |
evm-erc20-approve | Ethereum | USDC approve (the eth_sendTransaction example) |
evm-bsc-legacy | BNB Chain | Legacy EIP-155 transaction (data-type 1) |
evm-avax-legacy | Avalanche | Legacy transaction with a three-byte v |
evm-personal-sign | EVM | Sign-In with Ethereum message (data-type 3) |
evm-eip712-permit | Ethereum | ERC-2612 Permit (data-type 2) |
tron-trx-transfer | TRON | TRX transfer |
tron-trc20-transfer | TRON | USDT TRC-20 transfer |
tron-message | TRON | TIP-191 message |
sol-transfer | Solana | SOL transfer, legacy message |
sol-spl-transfer | Solana | USDC TransferChecked |
sol-message | Solana | Text message |
ECDSA (Bitcoin SegWit v0, EVM, TRON) and Ed25519 (Solana) signatures are deterministic, so your implementation should reproduce them byte for byte when signing the same bytes with the same key. Taproot signatures use fresh randomness and differ every time: verify them instead.
How to use them
- Decoder tests. Feed the
framesof each export or response to your scanner code, in a shuffled order and with duplicates, and compare the result with the decoded JSON. - Encoder tests. Build the same request from the same inputs and compare the UR CBOR hex (
urCBORHex). Request IDs in the vectors are fixed (5f1e9b2c…) so the bytes are reproducible. - Assembly tests. Take the response signature and assemble the transaction; compare with
signedTxHex,signedTransaction,signedTransactionBase64orfinalTxHex. - End-to-end. Import the test phrase into BitTool Signer on a test iPhone (the app requires a device passcode), pair your wallet, and scan your own requests.
Regenerating
The docs repository contains the generator and the tested code samples:
cd devdocs
npm run vectors -- /path/to/bittool-signer-ios/engine # rewrites src/data/vectors.json and static/vectors/*.json
cd examples && npm install && node test.mjs /path/to/bittool-signer-ios/engine
test.mjs runs every code sample on this site against the engine: requests built by the samples are decoded, matched and signed by the engine, and the samples verify and assemble the results.
Vectors generated 2026-10-18 from the engine bundle with SHA-256 6933d0d8a6f60faa8222506ac0bd7eef80eb884c9f73e31e9f354b4740f21077: the engine shipped in BitTool Signer 1.0.0 and examined by both security reviews.
BitTool Signer for Android 1.0.0 ships a later build of the same engine (SHA-256 4b371759…00fa19). It changes only how Bitcoin and Solana burns are summarized; the QR formats and signatures are the same.