钱包开发者指南

本文是构建 TRON 钱包的技术路线图，覆盖三类场景：从零开发独立 TRON 钱包，在多链钱包中增加 TRON 支持，或开发面向机构和游戏场景的定制钱包。下文梳理钱包必须实现的核心能力，并给出对应文档和 SDK 选型建议。

如果只是让 DApp 连接用户钱包，请读 DApp 钱包集成。如果运营中心化交易所或托管钱包，请读交易所与托管钱包集成。

📘
前置阅读

账户

交易

TRON 钱包核心功能清单

一个可用的 TRON 钱包至少需要实现以下功能：

核心功能	功能说明	详细技术指南链接
私钥与地址派生	基于 BIP-39 助记词生成种子，遵循 BIP-44 派生路径（币种路径为 `m/44'/195'/0'/0/<index>`），通过 secp256k1 椭圆曲线计算出公私钥对，最终编码为以 `T` 开头的 Base58Check 格式地址	账户模型
交易体构建	在本地或通过 API 构造包含 `raw_data` 的交易体（包括合约参数、引用区块高度 `ref_block_bytes`、引用区块哈希 `ref_block_hash`、过期时间 `expiration` 以及 `fee_limit`）	交易生命周期
离线签名	对经 Protobuf 序列化后的 `raw_data` 执行 SHA-256 哈希计算，再使用私钥执行 secp256k1 签名	交易生命周期
交易广播	将已包含签名的交易数据通过 POST 请求发送至全节点或托管 RPC 服务的广播接口	RPC 与数据服务
余额与对账	查询账户名下的 TRX、TRC-10、TRC-20 以及 TRC-721（NFT）等资产余额	Token 标准
资源核算展示	向用户清晰展示其账户当前拥有的可用带宽（Bandwidth）与能量（Energy）配额	资源模型
质押与投票 (选配)	如果钱包提供质押增值服务，需实现完整的 Stake 2.0 质押、资源代理及超级代表 (SR) 投票交互流程	质押、投票与奖励机制
多重签名 (选配)	支持账户权限分配、阈值权重计算以及多方签名的收集与合并	多重签名与权限管理

私钥与地址派生技术细节

TRON 遵循 BIP-39 助记词规范和 BIP-44 多币种派生标准。TRON 相关参数如下：

分层确定性（HD）路径：派生路径为 m/44'/195'/0'/0/<address-index>。其中 195 是 TRON 在 SLIP-44 标准中注册的币种标识代码。
椭圆曲线算法：采用 secp256k1 曲线（与以太坊生态一致）。
地址派生算法：获取 64 字节的未压缩公钥（移除 0x04 前缀），对其执行 Keccak-256 哈希计算，截取哈希结果的最后 20 字节；接着在该字节数组前附加代表 TRON 主网的单字节前缀 0x41（得到 21 字节的原始地址数据）；最后对这 21 字节执行 Base58Check 编码，即可生成用户可见的地址。
地址呈现格式：包含 34 个字符的 Base58Check 字符串，且锁定以大写字母 T 开头（若为 Hex 格式，则为以 41 开头的 42 字符 Hex 字符串）。

关于地址生成的完整代码示例与推导步骤，请参阅账户模型章节。

离线签名与广播流程

一个标准的 TRON 交易处理流程包含以下步骤：

1. 获取最新区块的引用数据（Ref Block） → 调用 `/wallet/getblock` 接口（或 SDK 封装方法）
2. 构建交易体 (transaction.raw_data)  → 调用 /wallet/createtransaction 接口或 SDK 方法
3. 计算 raw_data 的 SHA-256 哈希值      → 在客户端本地执行
4. 使用私钥执行 secp256k1 签名          → 在客户端本地执行，确保私钥绝不离开安全设备
5. 将签名追加至交易中                  → 写入至 transaction.signature[0] 数组中
6. 向网络广播已签名的交易              → 调用 /wallet/broadcasttransaction 接口

各类 SDK 都对上述步骤做了高层封装。生产级钱包建议直接调用 SDK 的签名模块，不要自行实现底层加密与序列化原语，以免在 Protobuf 序列化和签名恢复字节（Recovery ID）处理上出现边界错误。完整交易生命周期见交易底册。

开发 SDK 推荐

开发 SDK 工具	主要编写语言	适用集成场景
TronWeb	JavaScript / TypeScript	适用于浏览器插件钱包开发、Node.js 业务后台以及移动端 Hybrid/WebView 钱包
Trident	Java	适用于 Android 原生钱包开发及 JVM 生态的后端集成
gotron-sdk	Go	适用于高性能后端微服务、自建数据索引器与专属离线签名机
TronWallet Adapter	JavaScript / TypeScript	仅用于 DApp 侧集成各种不同的第三方钱包——钱包开发商无需集成此库
wallet-cli	Java	命令行钱包参考实现；适合作签名与底层调用的代码参考，不宜直接嵌入生产级钱包客户端

实际开发中，客户端钱包通常优先选 TronWeb（跨平台、JavaScript 框架）或 Trident（Android 原生）。后端高并发场景，例如服务端签名机和资产批量出款，更适合 gotron-sdk。

质押（Stake 2.0）界面交互集成（可选）

若钱包计划向用户提供原生资产质押与收益服务：

质押与赎回交互：质押 TRX 获取资源、资源代理与回收、最终提取本金的完整交互逻辑，见质押、投票与奖励机制。
超级代表 (SR) 投票：用户通过质押获取的投票权（TRON Power）为超级代表进行投票的细节，可查阅上述同一章节。
解除质押锁定期提示：用户申请解除质押后，本金要经过等待期才能提取。主网当前值为 14 天，对应链参数 UNFREEZE_DELAY_DAYS。该参数可通过 /wallet/getchainparameters 动态查询，不要把 14 天硬编码进客户端 UI。

统一调用 SDK 封装的高层方法发起这些系统合约交易，不要手动拼接底层字节码。同时在钱包资产面板清晰展示相关状态：质押中的 TRX、待提取的锁定期余额、当前投票权 TRON Power，以及已累积但未领取的超级代表产块与投票收益。

多重签名集成规范（可选）

TRON 通过原生账户权限机制支持多重签名。面向机构客户或共享账户的钱包，建议实现以下交互：

权限配置查询：调用相关接口查询目标账户的权限列表，展示哪些地址拥有对应角色的操作权限，以及各个地址对应的权重和交易所需的阈值（Threshold）。
异步签名收集：实现异步收集流水线，逐个收集各授权私钥对交易哈希的签名，并合并到交易体的 signature[] 数组。
签名进度展示 UI：设计直观的进度面板，例如在界面上清晰提示“该交易已收集 2/3 的有效签名，还需 1 个签名以达到起签阈值”。

关于 TRON 多重签名合约定义与权限树的具体架构，请参阅多重签名与权限管理章节。

前置阅读