集成快速入门
完整的集成包含五个部分。每一步都链接到描述具体格式的页面，而且每种格式都提供了测试向量，你可以在拿起手机之前先用它们校验代码。
1. 添加支持 UR 的二维码扫描器
除纯地址外，BitTool Signer 的所有二维码都是 Uniform Resource（UR）：以 ur:<type>/ 开头的文本。较大的载荷以动态二维码呈现：由一系列帧共同承载数据。请使用 UR 解码器，不要自己解析文本。
| 平台 | 库 |
|---|---|
| JavaScript / TypeScript | @ngraveio/bc-ur（BitTool Signer 使用的库） |
| Swift | URKit |
| Kotlin / Java | Hummingbird |
| Rust | ur |
把扫描到的每一帧都交给解码器，直到它报告完成为止。帧可能以任意顺序到达，也可能重复。
2. 配对：导入账户
请用户在 BitTool Signer 中打开对应钱包的 Connect（连接）页面。这里提供两种配对二维码：
- Wallet level（钱包级）：一个动态
ur:bytes二维码，包含 Bitcoin（四种地址类型）、EVM、TRON 以及三个 Solana 地址。最适合多链钱包。参见钱包级二维码。 - Coin level（币种级）：每条链一个标准二维码（
ur:crypto-account、ur:crypto-hdkey、ur:crypto-multi-accounts或纯地址），格式与其他二维码签名器相同。参见币种级二维码。
保存账户 xpub（Solana 则保存地址）、对应的派生路径以及主指纹。构建签名请求时，这三者缺一不可。显示每个账户的第一个地址，并请用户与 BitTool Signer 在二维码下方显示的地址进行比对。
3. 构建签名请求
用户发起转账时，照常构建未签名交易，再将其封装为该链对应的请求类型：
| 链 | 请求 | 包含的内容 |
|---|---|---|
| Bitcoin | ur:crypto-psbt | 一个 PSBT，其中每个输入和找零输出都带有 bip32Derivation（指纹 + 完整路径） |
| EVM | ur:eth-sign-request | 未签名的 RLP 交易、EIP-712 JSON 或消息字节，以及路径、指纹、链 ID 和地址 |
| TRON | ur:tron-sign-request | raw_data protobuf 字节，以及路径、指纹和地址 |
| Solana | ur:sol-sign-request | 序列化后的消息（而不是交易），以及路径、指纹和公钥 |
将请求显示为动态二维码。把未签名交易和一个随机请求 ID 保存在待处理记录中。参见通过二维码签名。
4. 扫描签名
BitTool Signer 会展示每个字段，要求输入钱包密码，然后将结果显示为二维码。扫描后按以下顺序检查：
- UR 类型是预期的响应类型。
- 请求 ID 与你的待处理请求一致（Bitcoin：PSBT 内的未签名交易没有被改动）。
- 签名能够用预期的公钥、针对你请求签名的确切字节验证通过。
5. 组装并广播
将签名填入交易（EVM：r、s、v；TRON：追加到 signature[]；Solana：放入该签名者对应的槽位；Bitcoin：对 PSBT 执行 finalize），然后广播。BitTool Signer 从不广播交易，也无从得知交易是否已发送。
无需手机即可测试
本站的所有示例都由 BitTool Signer 引擎使用以下公开测试助记词生成：
abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
在测试设备上将它导入 BitTool Signer（或用于你自己的测试），你看到的地址、二维码和签名应与本文档完全一致。所有数据都可以从测试向量页面下载。
- 动态二维码在两个方向上都能正常扫描，包括漏扫某一帧之后。
- 用户在收款之前可以比对每个账户的第一个地址。
- 每个响应在广播前都经过验证；针对其他请求的响应会被拒绝。
- 对于 SegWit v0 和 Legacy 输入，Bitcoin 输入携带完整的前序交易（
nonWitnessUtxo）。 - Solana 交易使用静态账户密钥（不使用地址查找表）。