路线 7：硬件钱包签名集成

本路线可以作为在 TRON 应用中接入硬件钱包签名能力的起点，适合负责在钱包、托管工具或其他应用中，通过现有硬件钱包签署 TRON 交易的开发者。

可以从这条路线了解什么

硬件钱包接入通常由主机应用和设备共同完成。主机应用构建交易、调用接入组件、验证返回的签名、广播交易并查询结果；硬件钱包保存私钥，并按照设备支持的方式向用户展示和确认签名请求。

路线以一笔 Shasta TRX 转账为贯穿实践：从设备读取 TRON 账户，在主机应用中构建未签名交易，调用真实设备完成签名，再验证签名并跟踪交易直至固化。完成这条流程后，可以继续按照设备已经支持的交易类型接入 TRC-20 转账或其他操作。

本路线不介绍硬件设计、固件开发、APDU、安全芯片或厂商应用上架。设备连接方式、签名接口、确认页面和支持的交易类型，以所选硬件钱包的厂商文档和 SDK 为准。

路线概览

开始前

完成实践需要一台明确支持 TRON 的硬件钱包、对应的厂商 SDK 或设备通信库、一个仅用于 Shasta 的测试账户，以及能够构建和广播 TRON 交易的主机程序。请先根据厂商文档确认设备、固件、TRON 应用和接入组件的版本能够配合使用。

测试账户不应持有真实资产。主机应用只读取设备公开的地址或公钥，并向设备提交签名请求；助记词和私钥不应离开硬件钱包，也不应出现在日志、配置或测试数据中。

如果暂时没有真实设备，可以使用配套 Recipe 中的模拟适配器检查主机侧的数据流，但这不能验证设备连接、密钥隔离、设备显示或物理确认。完成本路线的贯穿实践仍需要使用真实硬件钱包签署测试交易。

路线阶段

1. 选择设备接口并建立连接

不同硬件钱包提供的连接方式和签名接口并不相同。开始实现前，需要先确认目标设备是否支持 TRON、能够签署哪些交易类型，以及应用应通过哪一个厂商 SDK 或设备通信库访问设备。

主机应用应把设备通信封装在独立适配器中。适配器至少需要支持按账户路径读取地址或公钥，以及提交交易签名请求。请求参数、返回签名格式、用户确认流程和错误码均应以厂商接口为准，不能假定所有硬件钱包接收相同的 raw_data_hex 或返回相同格式的签名。

推荐阅读

1. 所选硬件钱包的官方开发者文档

   用于确认 TRON 支持范围、设备连接方式、SDK 版本、签名参数和返回值。这些内容具有厂商特性，TRON 协议文档不能替代。

2. 离线构建交易 — 硬件钱包签名流程

   用于了解联网主机构建交易、硬件钱包签名和联网端广播之间的数据流；具体设备调用仍以厂商接口为准。

3. TRON 网络

   用于准备 Shasta Endpoint 和测试账户。不同 TRON 网络使用相同地址前缀，应用不能仅根据地址判断网络。

阶段实践

选择一款支持 TRON 的硬件钱包，记录设备、固件、TRON 应用、接入组件和主机运行环境的版本。按照厂商示例连接设备，并从应用调用一次只读的账户接口。

此时应能稳定识别设备连接、断开、用户取消和应用未打开等状态。不要在错误日志中记录签名载荷之外的敏感设备信息。

开始核对账户前：应用能够通过厂商支持的接口连接设备并读取 TRON 地址或公钥，且不要求设备导出助记词或私钥。

2. 核对设备账户

主机应用需要明确由哪个设备账户签名。TRON 账户使用 secp256k1，硬件钱包通常按照 BIP-44 coin type 195 派生账户。具体派生路径和账户选择方式仍以设备实现为准。

同一账户可以表示为以 41 开头的 Hex 地址或以 T 开头的 Base58Check 地址。应用需要统一接入组件、TRON SDK 和节点 API 使用的地址格式，并确认转换前后仍为同一个账户。

推荐阅读

1. 钱包开发者指南 — 私钥与地址派生技术细节

   用于了解 TRON 的 BIP-44 coin type、secp256k1 和常见派生路径。

2. 账户与密钥 — 密钥对 和 地址格式

   用于核对公钥、Hex 地址和 Base58Check 地址之间的关系。

3. 验证 TRON 账户派生

   用公开测试向量交叉核对地址计算。Recipe 中的软件派生只用于验证主机实现，不能代替从真实设备读取账户。

阶段实践

从设备读取一个仅用于测试的 TRON 账户，保存派生路径、公开地址和公钥等非秘密信息。使用 TRON SDK 核对 Hex 与 Base58Check 地址转换，并确认后续交易的 owner_address 使用这个账户。

再切换一次设备账户或账户索引，确认应用会更新签名者，而不是继续复用上一个地址。

构建交易前：设备、接入组件和主机应用指向同一个 TRON 账户，测试记录不包含助记词、私钥或其他可恢复秘密材料。

3. 构建并签署 TRX 转账

从字段较少的 TRX 转账开始，可以先验证主机交易构建、设备确认和签名返回是否能够形成闭环。主机使用选定的设备地址作为 owner_address，在 Shasta 构建一笔小额、未签名的 TransferContract。

应用随后按照所用接入组件的要求提交签名请求。用户应在硬件钱包上核对设备能够展示的信息并确认签名；设备具体展示哪些字段、是否完整解析交易，由所用设备和 TRON 应用决定。主机不能用自己生成的确认文字代替设备确认。

取得签名后，主机应基于原交易重新计算 txID，规范化接入组件返回的签名格式，并恢复签名地址。恢复地址必须与设备账户及交易 owner_address 一致，签名前后的交易数据也必须保持不变。

推荐阅读

1. 交易 — 交易结构、过期时间与时间戳 和 TAPOS

   用于了解构建交易时写入的引用区块、时间戳、过期时间和合约数据。

2. 地址与数据编码 — 交易数据载荷

   用于区分结构化 raw_data、Protobuf 序列化字节和 raw_data_hex，并确认 txID 的计算对象。

3. 签名校验 — 签名消息 和 单签校验

   用于在广播前检查签名格式并恢复签名账户。

4. 硬件钱包签名接入框架

   用于验证主机侧的交易构建、适配器调用、验签和可选广播流程。示例默认使用模拟适配器；实际接入时必须替换为所选硬件钱包支持的厂商 SDK 或设备通信库。

阶段实践

在 Shasta 构建一笔小额 TRX 转账，通过真实硬件钱包完成用户确认和签名。保存设备与接入组件版本、原 txID、非敏感的设备确认记录和主机验签结果。

分别测试用户拒绝签名、设备断开和签名者不匹配，确认这些情况不会进入广播阶段。

广播交易前：签名由真实设备产生，恢复地址与设备账户和 owner_address 一致，且设备确认之后原交易没有被修改。

4. 广播并确认交易

签名成功不代表交易已经被网络接受或执行。主机需要把设备返回的签名写入原交易并广播，然后始终使用签名前已经确定的 txID 查询结果。

广播接口返回 result: true 只表示当前节点接受交易。应用还需要确认交易是否被打包、执行是否成功，以及包含该交易的区块是否已经固化。

广播超时或返回重复交易错误时，不应立即构建另一笔转账。应先查询原 txID，必要时在交易仍有效时重播同一笔已签名交易；只有确认原交易未上链且已经过期后，才重新构建并请求设备再次确认和签名。

推荐阅读

1. 交易签名与广播 — 广播已签名交易 和 确认交易结果

   用于广播已签名交易并查询交易本体、执行收据和已固化结果。

2. 确认语义 — 状态语义速查

   用于区分节点接收、交易打包、执行结果和固化状态。

3. 广播与 RPC 错误诊断 — 交易广播接口响应码

   用于处理重复交易、过期、签名错误和广播结果未知。

阶段实践

广播上一阶段由设备签署的原交易，依次保存广播响应、交易记录、执行结果和已固化结果。核对各阶段使用同一个 txID，并模拟一次广播结果未知，确认应用会继续查询原交易而不是自动创建另一笔付款。

扩展交易类型前：应用能够验证设备签名、广播同一笔交易，并根据执行和固化结果更新状态。

5. 扩展与回归测试

完成 TRX 转账闭环后，可以根据设备和接入组件已经支持的范围增加 TRC-20 转账、账户权限或其他交易类型。每增加一种类型，都需要确认主机如何构建交易、设备能够展示和确认哪些内容、接入组件返回何种签名，以及应用如何验证链上结果。

对于 TRC-20 transfer(address,uint256)，主机至少应核对目标合约、函数 selector、接收地址、最小单位金额、Token 精度和 fee_limit。如果设备无法清晰展示合约调用内容，应按照厂商提供的行为向用户说明，而不能把主机界面的说明当作设备已完成可信确认。

回归测试应覆盖账户不匹配、交易被修改、交易过期、用户拒签、设备断开、不支持的交易类型、无效签名和广播结果未知。交易内容或过期时间发生变化后，必须重新请求设备确认和签名。

推荐阅读

1. 系统合约类型 — TriggerSmartContract

   用于了解 TRC-20 转账所在的合约调用结构。

2. 参数编码与解码 — 函数选择器 和 静态类型参数的编码规则

   用于核对 transfer(address,uint256) 的接收地址和金额参数。

3. FeeLimit 与能量成本

   用于理解合约调用中的费用上限；设备展示和策略仍以厂商实现为准。

4. 广播与 RPC 错误诊断

   用于为签名拒绝、交易过期和广播结果未知分别制定处理方式。

阶段实践

先把真实设备签署 TRX 转账的成功流程和异常场景整理为可重复执行的测试。设备明确支持 TRC-20 转账时，再构建一笔 Shasta 测试调用，核对设备显示、返回签名和主机解析结果；如果设备不支持，则记录支持范围，不通过模拟代码声称已经完成硬件接入。

完成本路线的贯穿实践：应用能够从真实设备读取 TRON 账户，通过厂商支持的接口请求并取得一笔 TRX 转账签名，在主机侧完成验签、广播和固化确认，并正确处理用户拒签、设备断开和交易结果未知。

后续实践与扩展

完成这条路线后，应得到设备与接入组件版本记录、不包含秘密材料的账户测试记录、一笔由真实硬件钱包签署并在 Shasta 固化的 TRX 交易，以及相应的异常场景测试结果。

继续接入更多交易类型时，应以设备实际支持范围为准，并分别补充交易字段核对、设备确认、签名验证和链上结果检查。涉及固件、安全芯片、设备端解析或厂商应用发布时，需要转入相应硬件钱包厂商的开发与安全流程。