路线 2：非托管钱包开发者

本路线可以作为了解非托管钱包如何接入 TRON 核心链路的起点，适合开发钱包原型，或评估现有多链钱包所需的账户、资产查询和转账能力的开发者。

可以从这条路线了解什么

这条路线从账户恢复和密钥边界出发，依次介绍资产与资源查询、TRX 转账、TRC-20 转账和交易状态处理，重点说明非托管钱包如何在不把私钥交给节点或后端服务的前提下完成这些工作。

路线以一个最小钱包原型为贯穿任务。这个原型能够从固定测试向量恢复 TRON 账户，展示 TRX、TRC-20、Bandwidth 和 Energy，在本地签署并广播转账，并根据原 txID 更新交易状态。

固定测试向量只用于离线验证账户派生，不应充值或参与链上交易；资产查询和转账应使用另行生成、只持有测试资产的 Shasta 测试账户。

如果希望一边阅读一边实践，可以在现有钱包工程中逐步增加这些能力。这个原型主要用于建立 TRON 钱包的核心链路；面向生产环境的密钥保护、安全审计、节点容灾、风险控制和发布准备，还需要结合具体产品继续完善。

开始前不必一次掌握所有协议细节。可以先通过下方概览了解各阶段的重点，再按照文档逐步实践；遇到账户、交易或合约编码方面的问题时，再回到推荐阅读补充所需信息。

路线概览

阶段	主要内容	最小钱包原型中的任务
1. 建立账户恢复与密钥范围	了解助记词、派生路径、地址格式和私钥边界	使用固定测试向量核对账户恢复、地址派生和秘密材料的可见范围
2. 建立只读钱包	了解链适配层、资产精度和资源查询	查询并展示 TRX、TRC-20、Bandwidth 和 Energy
3. 支持 TRX 转账	了解交易构造、确认、本地签名和广播	从真实待签交易生成确认信息，并完成一笔 Shasta TRX 转账
4. 支持 TRC-20 转账	了解标准 `transfer` 调用、参数解析和费用信息	展示 Token、金额、接收地址、目标合约和费用，并完成一笔测试转账
5. 建立统一交易状态	了解广播、执行、固化和异常恢复	根据原 `txID` 更新状态，并处理拒签、篡改、过期和节点异常

开始前

建议先了解账户、交易、资源和测试网等 TRON 基础概念；如果尚不熟悉，可以先从路线 0：完全初学者开始。完成阶段实践还需要熟悉一种钱包开发语言，了解 HD Wallet 派生约定和 ECDSA 签名的基本概念，并准备只持有测试资产的 Shasta 账户和测试 TRC-20 Token。

可以通过 Shasta 水龙头获取测试资产。如果需要自定义测试 Token，可以参考用 TronWeb 部署 TRC-20 Token ；该 Recipe 需要先准备实际编译得到的 ABI 与字节码。所有查询、构造、广播和确认继续使用 Shasta Endpoint 。

本路线主要梳理各阶段的核心知识，并通过相关文档呈现非托管钱包的完整链路。地址算法、Protobuf 字段、API 请求和 SDK 代码请参考钱包开发者指南 — TRON 钱包核心功能清单以及各阶段链接的文档与 recipe。

WalletConnect、多重签名、账户权限、Stake 2.0 和硬件设备签名不属于这个最小原型的必选范围，可以在核心链路稳定后根据产品需要继续接入。

路线阶段

1. 建立账户恢复与密钥范围

非托管钱包首先要保证同一组恢复材料能够稳定得到同一组账户。TRON 通常使用 BIP-39 助记词生成种子，并按照 BIP-44 coin type 195 派生账户。派生路径、账户索引和地址格式一旦确定，就需要在不同版本和不同实现之间保持一致。

TRON 账户使用 secp256k1。同一地址可以表示为以 41 开头的 Hex 格式或以 T 开头的 Base58Check 格式，钱包需要在存储、SDK 调用和界面展示之间明确使用哪种表示。格式转换不应改变账户本身。地址本身不标识 Mainnet 或 Shasta，因此钱包还需要单独保存并展示当前网络。

账户能够恢复只是第一步。助记词和私钥只能进入受控的密钥存储与本地 signer，不应出现在节点请求、后端接口、日志、分析系统、崩溃报告或剪贴板记录中。联网的链数据查询与持有秘密材料的签名模块也应保持清晰边界。

阶段实践

选择一组公开、只用于测试且不持有资产的固定助记词，记录多个账户索引对应的派生路径、公钥、Hex 地址和 Base58Check 地址。清除本地钱包状态后重新恢复，再使用另一种 TRON SDK 或独立实现核对结果。

同时记录助记词和私钥在钱包中的可见范围。账户恢复与签名模块可以访问秘密材料，资产查询、交易广播、日志和后端服务则不应访问。测试时还需要检查错误信息和调试输出，确认其中没有秘密材料。

另行生成一个只用于后续链上实践的 Shasta 测试账户。固定助记词对应的公开测试地址只验证派生结果，不用于充值、签名或广播。

建立只读钱包前：确认固定测试向量可以重复恢复出相同账户和地址顺序，并且助记词和私钥没有进入日志或网络请求。下一阶段将只使用另行生成的 Shasta 测试地址查询链上数据。

2. 建立只读钱包

账户可以稳定恢复后，需要把密钥管理与链数据访问分开。只读钱包通过地址查询资产和资源，不需要私钥，也不需要用户签名。节点或 RPC 提供商只负责返回链上数据，不应参与账户恢复和签名。

最小钱包需要展示 TRX 余额、受支持的 TRC-20 余额、Bandwidth 和 Energy。TRX、TRC-20 和资源数据来自不同查询，钱包可以通过独立的 TRON 链适配层统一这些接口，避免业务界面直接依赖某个 SDK、节点供应商或原始响应格式。

TRC-20 金额还需要结合合约的 decimals 转换显示单位。钱包应同时保留原始整数和显示金额，避免使用浮点数造成精度损失。Token 应以当前网络和合约地址识别，不能只依赖可能重复的名称或 symbol。未知 Token、缺失元数据、查询超时和部分数据失败也需要显示为明确状态，不能自动解释为余额为零。

查询不到账户状态时，应先判断地址是否尚未激活，而不是直接显示为普通零余额账户。钱包还需要在用户向未激活地址发送首笔 TRX 前提示账户创建会产生额外成本；具体数值应读取当前链参数。

阶段实践

在钱包工程中建立独立的 TRON 链适配层，为账户信息、TRX 余额、TRC-20 元数据与余额、Bandwidth 和 Energy 定义稳定接口。初始化只读客户端时只提供目标网络和节点地址，不提供私钥。

使用阶段 1 另行生成的 Shasta 测试地址完成查询，并把页面结果与独立节点或 Shasta 区块浏览器查询进行核对。测试未知 Token、元数据缺失、单项查询失败和节点超时，确认页面能够保留已经取得的数据，并明确显示无法确认的部分。

支持 TRX 转账前：确认业务层可以在不接触私钥的情况下展示 TRX、TRC-20、Bandwidth 和 Energy，且更换节点或 mock 实现不会改变页面的数据模型。下一阶段将在独立 signer 中完成交易授权。

3. 支持 TRX 转账

TRX 转账需要经过构造、确认、签名和广播。钱包应先构造包含发送账户、接收地址、金额、TAPOS 引用和过期时间的真实待签交易，再从这笔交易的 raw_data 生成确认信息。确认页不能只复述表单输入，因为表单内容与最终待签数据可能已经不一致。

用户确认后，钱包使用本地 signer 对由最终 raw_data 计算出的 txID 签名，再从签名中恢复地址，确认 signer 与发送账户一致。签名完成后不应重新构造或修改交易；广播的必须是用户确认并签署的同一笔交易。

txID 在未签名交易构造完成时已经产生，不是广播成功后才生成。节点接收广播只说明交易通过初步校验，不代表转账已经进入区块或完成固化。钱包需要保存原 txID，继续查询交易本体、执行结果和固化状态。

阶段实践

使用阶段 1 的 Shasta 测试账户和阶段 2 的链适配层构造一笔 Shasta TRX 转账。确认页从最终 raw_data 解析并展示目标网络、发送账户、接收地址、金额、过期时间和预期资源信息，再由本地 signer 完成签名。

签名后恢复 signer 并重新核对 raw_data，然后广播同一笔已签名交易。保存原 txID，继续查询执行结果和固化状态，并将页面显示的信息与链上交易内容进行比较。

支持 TRC-20 转账前：确认 Shasta 上已有一笔由钱包本地签署并完成固化的 TRX 转账。保存的记录应能证明确认页、签名数据和广播交易内容一致，且私钥未进入节点或后端服务。

4. 支持 TRC-20 转账

TRC-20 转账不是普通 TRX 转账，而是对 Token 合约发起 transfer(address,uint256) 调用。交易的目标合约是 TRC-20 合约地址，真正的 Token 接收地址和金额则编码在调用参数中。钱包需要同时展示这两类地址，避免把接收地址与目标合约混为一谈。

金额解析需要使用合约声明的 decimals，并保留传入 uint256 的原始整数。确认页还需要展示 Token 名称与 symbol、发送账户、目标网络、函数、费用信息和 fee_limit。这些内容应从真实待签调用和已经核对的 Token 元数据生成，不能只依赖外部请求附带的名称或金额说明。

确认页需要区分 Energy 估算、预计燃烧的 TRX 和 fee_limit 上限；fee_limit 不是固定手续费，估算失败也不能显示为零。

标准 transfer 调用会消耗 Bandwidth 和 Energy。交易广播后，需要通过 receipt 判断合约执行成功或失败；节点接受交易不能作为 Token 已经转出的依据。

阶段实践

在 TRX 转账闭环上增加一个受支持的 Shasta 测试 TRC-20 Token。读取并核对 Token 合约的地址、名称、symbol 和 decimals，再构造一笔标准 transfer(address,uint256) 调用。

确认页从最终待签交易中解析目标合约、函数、接收地址和原始金额，并结合已核对的 Token 元数据显示用户金额与费用信息。用户确认后，由同一个本地 signer 完成签名，广播交易并保存原 txID，再通过已固化 receipt 查询最终结果。

建立统一交易状态前：确认 Shasta 上已有一笔由钱包本地签署并完成固化的 TRC-20 转账。确认页应能区分 Token 接收地址与目标合约，并使原始金额、显示金额和链上调用参数保持一致。

5. 建立统一交易状态

TRX 和 TRC-20 可以共用一套交易状态模型，但每个状态需要有明确含义。已签名表示本地已经生成签名；已广播表示节点已经接受交易；执行成功或失败来自链上执行结果；已固化表示交易进入不可逆区块；暂时无法确认则表示当前数据不足以判断最终结果。

钱包不能把用户确认、签名完成或广播成功直接显示为业务成功。TRC-20 调用还可能在已经进入区块后执行失败，因此需要继续查询 receipt。节点超时或索引延迟也不等于交易失败，应保留原 txID 并继续查询。

异常处理需要与状态模型保持一致。错误网络、无效地址、待签数据被篡改或 signer 不匹配时，应在广播前停止；用户拒签时不应生成成功状态；交易过期或 TAPOS 失效后需要重新构造，并再次请求确认和签名；节点异常时则先查询原交易，再决定等待、重新广播同一笔有效交易或重建交易。重新构造会生成新的 txID，必须重新向用户展示并获得授权。

阶段实践

为 TRX 和 TRC-20 建立统一状态机，并记录每次状态变化的来源。使用固定测试用例覆盖已签名、已广播、执行成功、执行失败、已固化和暂时无法确认，确保界面不会跳过执行结果或提前显示最终成功。

继续补充错误网络、无效地址、待签数据篡改、用户拒签、交易过期、TAPOS 失效、广播超时、节点不可用和重复广播等场景。对每个场景记录停止位置、是否已有 txID、能否继续查询、是否允许重新广播，以及何时必须重新构造并再次请求用户授权。

验证状态处理结果：TRX 和 TRC-20 的正常流程可以重复完成，异常场景也会停在符合实际情况的状态。节点超时或结果暂时未知时，钱包应继续跟踪原 txID，避免重复付款或误报成功。

后续实践与扩展

完成这条路线后，最小钱包原型应能够稳定恢复测试账户，展示 TRX、TRC-20、Bandwidth 和 Energy，在本地签署并广播 TRX 与 TRC-20 转账，并根据原 txID 准确更新交易状态。

核心链路稳定后，可以根据产品范围继续接入 WalletConnect、多重签名和 TRON 网络质押。多重签名与质押的操作示例分别参见多签交易和质押与代理资源。如果需要把签名能力放入独立硬件设备，还需要单独建立设备展示、设备签名和主机校验边界。

如果只完成了其中一部分，可以保留固定测试向量、链适配接口、待签交易样本、txID 和异常测试结果，之后再从相应阶段继续。助记词和私钥不应出现在这些记录中。

如果某个阶段仍然无法继续，请提交路线反馈，注明“路线 2”、当前阶段、钱包平台与 SDK、Shasta Endpoint、已经完成的步骤和实际错误信息；不要提交助记词、passphrase、私钥、API Key 或生产账户信息。