If you operate a centralized service that holds TRX or TRC tokens for users — an exchange, a custodial wallet, a payment platform — this sub-chapter is for you. Three concerns shape every integration:

• Asset operations — detecting user deposits within minutes and broadcasting their withdrawals
• Balance and history queries — TRX, TRC-10, TRC-20, optionally TRC-721
• Operational scaffolding — hot and cold wallet separation, multi-sig, resource budgeting

This page is the architecture-level overview. The full implementation guide — node configuration, every API, block parsing logic, staking endpoints — is at Exchange wallet integration.

📘

Prerequisites

• Accounts
• Transactions

---

1. What needs to integrate

Asset operations (every integration)

• Deposit detection — when a user transfers TRX or a TRC token to a deposit address you control, your system must detect it within minutes and credit the user
• Withdrawal construction — build, sign, and broadcast transactions to send TRX or a TRC token to a user's external address
• Balance and history queries — for TRX, TRC-10, TRC-20, and any other token standards you list

Staking services (optional)

• Stake and unstake — let users stake TRX through your platform; surface the unstake delay (chain parameter UNFREEZE_DELAY_DAYS, currently 14 days on Mainnet) before withdrawal
• Voting — let users assign their voting power to Super Representatives
• Reward distribution — withdraw voting rewards and credit them to the right user balances

Operational concerns (every integration)

• Hot and cold wallet separation — your security architecture; not TRON-specific, but TRON's permission system enables clean implementation
• Multi-sig — for cold wallets and treasury operations, see Account permission management
• Resource budgeting — withdrawals consume Bandwidth (TRX transfers) or Energy (TRC-20 transfers); plan ahead — see Resource model

---

2. Architecture choice: TronGrid vs self-hosted full node

Most integrators start with TronGrid and migrate to a self-hosted node when volume or feature needs justify it. Both paths speak the same wire format, so the migration cost is small — typically a change of base URL plus your own implementation of any extension APIs you depended on.

For self-hosted setup, see Deploy a node and the broader RPC and indexer providers page.

---

3. Deposit-monitoring patterns

Two patterns are common:

Pattern A — Poll TronGrid account-history APIs

The simplest approach. Every few seconds, call v1/accounts/{address}/transactions for each deposit address. Process new entries; track the last-seen timestamp per address to avoid double-crediting.

Trade-offs: easy to implement; rate-limited by your TronGrid plan; latency equals your polling interval. Suitable for small to medium volume.

Pattern B — Parse blocks as they finalize

Pull each new solidified block, walk its transactions, and identify the ones that affect addresses you care about. Track block height to resume cleanly after restarts.

Trade-offs: lower latency than polling; no API rate limit because you read from your own node; more code to write (especially for smart-contract internal transactions). Suitable for high volume.

Full implementation patterns — including the type dispatch for TransferContract, TransferAssetContract, and TriggerSmartContract — are in Exchange wallet integration § Parsing blocks.

---

4. Staking services — decision matrix

---

5. Resource and fee considerations

Withdrawals consume Bandwidth (for TRX transfers) or Energy (for TRC-20 transfers and other contract calls). Two strategies:

• Stake TRX for resources — predictable, recommended for high-volume operators. See Resource model and Staking, voting, and rewards for Stake 2.0
• Burn TRX per transaction — simpler accounting, more expensive at volume

fee_limit on every transaction caps the Energy spent. Get this right before scaling — under-set values cause OutOfEnergyException and a failed (but billed) transaction. See Resource model for the math.

---

6. Pre-launch checklist

Before going live, verify the following:

• Deposit address derivation is BIP-44-compliant; you can recover any address from a master seed if your hot system is lost
• Withdrawal signing is performed offline, in an HSM, or by a hardware wallet — not by a key sitting in plaintext on your application server
• You handle TRX, TRC-10, and TRC-20 separately — they are different transaction types and balances
• You parse internal transactions when crediting deposits — a user may receive TRX or TRC-10 through a smart contract call (e.g., a swap router); these do not appear as top-level transactions
• You read from a solidified block height, not the chain head — solidification is ~1 minute behind head and guarantees no fork rollback
• You handle reorganization gracefully — TRON has fast finality but is not finalized on the head block
• Your resource and fee strategy is decided before scaling traffic
• If offering staking — the unstake delay (currently 14 days on Mainnet, query via /wallet/getchainparameters) is visible in your UI; users will ask

---

In this section

• Exchange wallet integration — full guide — node setup, every API endpoint, transaction patterns, block parsing, staking APIs

---

Related resources

• Wallet developer guide — for non-custodial wallets
• RPC and indexer providers — TronGrid alternatives and self-hosted considerations
• Staking, voting, and rewards — staking semantics in depth
• Account permission management — multi-sig for hot or cold wallet separation
• Resource model — Bandwidth, Energy, fee_limit