This page is the road map for developers building a wallet that supports TRON — a new wallet from scratch, an existing multi-chain wallet adding TRON, or a specialized wallet for institutional or game-specific use cases. It lists the capabilities you must implement, points to the chapter where each capability is documented in depth, and recommends an SDK.

If you are integrating an existing user-facing wallet into a DApp (as a DApp developer), see DApp integration instead. If you are running an exchange or custodial wallet, see Exchange and custodial wallet integration.

📘
Prerequisites

Accounts

Transactions

What a TRON wallet needs to do

The minimum capability surface for a useful TRON wallet:

Capability	Notes	Where to read more
Key derivation	BIP-39 mnemonic → seed → BIP-32/BIP-44 derivation (path `m/44'/195'/0'/0/<index>`) → secp256k1 keypair → base58check TRON address (starts with `T`)	Accounts
Transaction construction	Build `raw_data` (contract, ref_block_bytes, ref_block_hash, expiration, fee_limit)	Transactions
Signing	secp256k1 sign of the SHA-256 of the protobuf-serialized `raw_data`	Transactions
Broadcasting	POST signed transaction to a full node or hosted RPC	RPC and indexer providers
Balance queries	TRX, TRC-10, TRC-20, TRC-721	Token standards
Resource accounting	Show users their Bandwidth and Energy budgets	Resource model
Staking (optional)	Stake 2.0 flow if you offer staking UX	Staking, voting, and rewards
Multi-sig (optional)	Account permission system for shared or institutional wallets	Account permission management

Key derivation specifics

TRON uses standard BIP-39 mnemonics and BIP-44 derivation. The TRON-specific parameters:

HD path: m/44'/195'/0'/0/<address-index> — 195 is TRON's SLIP-44 coin type
Curve: secp256k1 (the same curve Ethereum uses)
Address derivation: take the uncompressed public key (drop the 0x04 prefix), Keccak-256 hash it, take the last 20 bytes, prepend the 0x41 TRON-mainnet prefix, then base58check-encode the resulting 21 bytes
Address format: 42 characters of base58, starting with T

The full address derivation procedure with worked examples is in Accounts.

Transaction signing flow

A standard TRON transaction flow:

1. Get latest block reference     → /wallet/getblock (or SDK helper)
2. Build transaction.raw_data     → /wallet/createtransaction or SDK helper
3. Compute SHA-256 of raw_data    → client-side
4. Sign with secp256k1            → client-side; the private key never leaves the device
5. Attach signature               → transaction.signature[0]
6. Broadcast                      → /wallet/broadcasttransaction

Every SDK exposes high-level helpers that wrap these steps. Production wallets do not implement the signing primitive themselves — use the SDK to avoid edge cases around protobuf serialization and signature recovery byte handling. See Transactions for the full lifecycle and edge cases.

SDK choices

SDK	Language	When to use
TronWeb	JavaScript, TypeScript	Browser wallets, Node.js backends, mobile webviews
Trident	Java	Android wallets, JVM backends
gotron-sdk	Go	Backend services, custom signers, indexers
TronWallet Adapter	JavaScript, TypeScript	DApp-side multi-wallet integration — not for wallet authors
wallet-cli	Java	Reference CLI implementation; useful for local testing and as code reference; not intended to be embedded in production wallets

For wallet authors, the most common choices are TronWeb (cross-platform JavaScript) or Trident (Android-native). gotron-sdk fits server-side signing services such as custody or batched-signing backends.

Implementing staking UX (optional)

If your wallet exposes staking features to users:

Stake, unstake, and withdraw flow → Staking, voting, and rewards
Vote for Super Representatives → same chapter
The unstake delay (currently 14 days on Mainnet — chain parameter UNFREEZE_DELAY_DAYS, query via /wallet/getchainparameters) must be visible in UI between unstake and withdraw; users will ask

Use the SDK helpers for these flows rather than constructing the contracts manually. Surface the resulting state changes — pending withdrawals, voting power, accrued rewards — in your wallet UI.

Multi-sig

TRON supports native multi-sig through the account permission system. A wallet that targets institutional or shared-key users should implement:

Permission queries — read which keys are authorized for which actions and at what threshold
Multi-step signing — collect signatures from N keys, merge into the transaction's signature[] array
Threshold-aware UI — show progress like "2 of 3 signatures collected"

Full details, including the proto-level schema and worked permission examples, are in Account permission management.

Related resources

TronWeb documentation — JavaScript SDK reference
Trident — Java SDK
wallet-cli — reference CLI; useful as a code reference
Account permission management — multi-sig