Chaingateway Tron API

More USDT moves on TRON than on any other network. Roughly $85 billion of the stablecoin circulated there in the first quarter of 2026, and the chain settled close to $2 trillion in USDT transfers in that quarter alone. If your product accepts stablecoin deposits or sends payouts, TRON is the chain your users expect first. The Chaingateway TRON API turns that into a REST integration: import addresses, send TRX, TRC-10 and TRC-20 tokens, and get a signed webhook the moment a deposit lands.

TRON is also the most complete chain in the product, with 40 endpoints. Beyond plain transfers there are staking calls, a fee estimator and the Paymaster, which pays network fees on behalf of wallets that hold no TRX. Authentication is a Bearer token in the Authorization header. The base URL is https://app.chaingateway.io, and adding X-Network: testnet to any request switches it to the test network. A trial account runs 7 days and needs no KYC.

What the TRON endpoints cover

Forty routes, one payment lifecycle. The selection below shows the six groups an integration actually combines; the rest — balance, block and decoded-transaction reads, contract information, address management — is in the docs. All of them live under https://app.chaingateway.io and expect the Bearer token in the Authorization header. The grouping matches how integrations grow in practice: most start with Transactions and Webhooks, add Queries for fee logic, then reach for Staking or sponsored fees once volume makes fees a line item worth managing.

Transactions

Endpoint	What it does
POST /api/v2/tron/transactions	Send TRX
POST /api/v2/tron/transactions/trc20	Send TRC-20 tokens such as USDT
POST /api/v2/tron/transactions/trc10	Send TRC-10 tokens
POST /api/v2/tron/transactions/trc721	Send TRC-721 NFTs
POST /api/v2/tron/transactions/build	Build an unsigned TRX transaction for local signing
POST /api/v2/tron/transactions/trc20/build	Build an unsigned TRC-20 transaction for local signing
POST /api/v2/tron/transactions/broadcast	Broadcast a transaction you signed yourself

Seven endpoints because there are two sending modes. The first four sign for you with an imported key. The last three split the process into build, sign locally, broadcast, for teams whose keys never leave their own hardware.

Addresses

Endpoint	What it does
POST /api/v2/tron/addresses	Create a new address
POST /api/v2/tron/addresses/import	Import a private key so the API can sign for that address

Importing is only needed for wallets you send from. Watching an address for deposits works without any key.

Staking

Endpoint	What it does
POST /api/v2/tron/freeze	Stake TRX to generate Bandwidth or Energy
POST /api/v2/tron/unfreeze	Release staked TRX
POST /api/v2/tron/delegate	Route staked resources to another address
POST /api/v2/tron/undelegate	Take delegated resources back

Paymaster (legacy)

Endpoint	What it does
POST /api/v2/tron/paymaster	Create a sponsored-fee request
GET /api/v2/tron/paymaster	List your Paymaster requests
POST /api/v2/tron/paymaster/estimate	Price a sponsored transaction before sending
GET /api/v2/tron/paymaster/balance	Check your remaining Paymaster credit

The Paymaster endpoints remain documented for existing integrations, but the developer docs mark the feature as deprecated and recommend TronFuel for new setups — an Energy-rental API that serves the same purpose: transfers from wallets that hold no TRX, at rented-Energy rates instead of the burn price.

Queries

Endpoint	What it does
GET /api/v2/tron/chainparameters	Read live network parameters, e.g. the Energy price in Sun

Chain parameters change by governance vote, so read them at runtime instead of hard-coding fee constants that a passed proposal quietly invalidates.

Webhooks

Endpoint	What it does
POST /api/v2/tron/webhooks	Create a webhook for an address
GET /api/v2/tron/webhooks/notifications	List past webhook notifications
GET /api/v2/tron/webhooks/notifications/failed	List deliveries that failed
POST /api/v2/tron/webhooks/notifications/{id}/retry	Re-send a failed delivery

There are two ways to handle keys across all of this. Import a private key once and send with a single call afterwards. Or keep keys on your own infrastructure: build the raw transaction with one of the /build endpoints, sign it locally and push it through /transactions/broadcast. In the second mode no key material ever leaves your servers; the self-signing section below walks through the flow.

USDT on TRON: the numbers

Tether had issued about $190 billion of USDT by April 2026. TRON carried roughly 45% of that supply, around $85 billion, with Ethereum close behind at about 40%; the two chains have swapped the lead more than once since late 2025. On TRON itself the picture is unambiguous: USDT made up 98.6% of the chain's stablecoin value in Q1 2026. Whoever says TRC-20 means USDT, for all practical purposes.

Supply is only half the story. Transfer volume tells you what a chain is used for, and TRON's USDT volume approached $2 trillion in the first quarter of 2026. Ethereum's USDT leans toward DeFi collateral and institutional settlement. TRON's is the version people actually move: exchange deposits, remittances, payouts to contractors in countries where a dollar balance beats the local bank account.

For an integration decision the consequence is plain. If your users pick a deposit network from a dropdown, TRC-20 will be the most-chosen entry, and wrong-network support tickets drop when your default matches what users expect. Build TRON first; the shared request schema lets you add the other chains later without new code.

Send USDT (TRC-20) with one request

A TRC-20 transfer takes the token contract, sender, recipient and amount, plus the wallet password you set when importing the key. You provide those, the API handles fee estimation and broadcasting.

curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/trc20 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
    "from": "TYourHotWalletAddress",
    "to": "TRecipientAddress",
    "amount": 25,
    "password": "YourWalletPassword"
  }'

<?php
$payload = [
    'contractaddress' => 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t', // USDT
    'from'     => 'TYourHotWalletAddress',
    'to'       => 'TRecipientAddress',
    'amount'   => 25,
    'password' => 'YourWalletPassword',
];

$ch = curl_init('https://app.chaingateway.io/api/v2/tron/transactions/trc20');
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER     => [
        'Authorization: Bearer YOUR_API_KEY',
        'Content-Type: application/json',
    ],
    CURLOPT_POSTFIELDS     => json_encode($payload),
]);

$response = json_decode(curl_exec($ch), true);

import requests

response = requests.post(
    "https://app.chaingateway.io/api/v2/tron/transactions/trc20",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",  # USDT
        "from": "TYourHotWalletAddress",
        "to": "TRecipientAddress",
        "amount": 25,
        "password": "YourWalletPassword",
    },
)
print(response.json())

The contract address above is USDT on TRON. Swap it for USDC, DAI or your own token and the call stays identical; decimals are handled automatically. TRC-10 tokens go through POST /api/v2/tron/transactions/trc10 with the same structure.

Energy and Bandwidth: TRON's two fee meters

TRON has no single gas price. The network meters two separate resources, and knowing which one your transaction consumes is the difference between predictable fees and surprise support tickets.

Bandwidth is charged on every transaction and follows byte size. Each account gets 600 free points per day; a plain TRX transfer weighs 250 to 300 bytes, so occasional TRX transfers cost nothing at all. Past the free quota the network burns 0.001 TRX per point, roughly 0.35 TRX for a typical TRC-20 transfer.

Energy applies only when a smart contract runs, and it has no free daily allowance. A USDT transfer is a contract call, the TRC-20 contract updates its internal balance table, so it needs Energy on top of Bandwidth. Since governance Proposal #104 took effect in August 2025, one Energy unit costs 100 Sun, halved from 210. A transfer to an address that already holds USDT takes about 64,000 Energy, which works out to 6.4 TRX. A transfer to an address that has never held USDT writes a new storage entry, and new state costs about twice the Energy of an update: roughly 134,000 units, or 13.4 TRX.

Before you send, two tools make the numbers concrete. The TRON fee calculator computes Bandwidth, Energy and the TRX total for one specific transaction, and GET /api/v2/tron/chainparameters returns the live unit prices so your code never bakes in a constant that the next governance vote changes. The fee guide covers the mechanics in depth.

Sponsored fees: send USDT from wallets that hold no TRX

Every TRC-20 transfer needs Energy, and the Energy has to come from somewhere. For most senders the source is their own TRX balance. That assumption breaks in two common situations, and both generate operational pain until you fix them structurally.

The first is your own fleet of deposit wallets. Every wallet that forwards funds to a hot wallet needs its own TRX balance for the sweep, and with a few thousand wallets, topping them up becomes a job of its own, complete with its own fee costs for the top-up transfers. Sponsored fees remove that job. The recommended way to set this up today is TronFuel, which rents Energy sourced in bulk from stakers — the same mechanism the fee guide describes as cutting fee costs by up to 60% compared with burning TRX at the market rate. Chaingateway's legacy Paymaster endpoints do the same and stay available for existing integrations.

The second is the end customer. A user holds 200 USDT in a self-custody wallet and zero TRX; the USDT arrived from an exchange or from another person, and nobody told them a second currency is required to move it. When they try to pay you or withdraw, the transfer fails. From the user's perspective the money is stuck. From your support queue's perspective it is a recurring ticket that no FAQ entry fully kills, because the fix, "go buy some TRX on an exchange first", is exactly the friction the customer wanted to avoid by using stablecoins. A sponsored transfer ends this: you submit the transfer, the sponsor covers Energy and Bandwidth, the cost lands on your account, and the customer never learns what TRX is. For checkout and withdrawal flows this one change removes the most common failure mode of TRC-20 payments.

Price a sponsored transaction first, then create it:

# 1. Estimate the fee
curl -X POST https://app.chaingateway.io/api/v2/tron/paymaster/estimate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRC20", "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TDepositWallet", "to": "THotWallet", "amount": "500"}'

# 2. Create the Paymaster request
curl -X POST https://app.chaingateway.io/api/v2/tron/paymaster \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRC20", "contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TDepositWallet", "to": "THotWallet", "amount": "500", "password": "YourWalletPassword"}'

GET /api/v2/tron/paymaster lists every request you created and reports its status from pending through completed or failed, and GET /api/v2/tron/paymaster/balance shows the sponsorship credit you have left — together they cover reconciliation.

Self-signing: keys never leave your servers

Importing a private key is the fastest path to production, but some teams cannot ship key material to a third party at all. The reason may be an internal policy, a regulator, or a hardware security module whose keys physically cannot be exported. The TRON API has a second mode built for exactly this constraint.

The flow has three steps. Call POST /api/v2/tron/transactions/trc20/build, or /api/v2/tron/transactions/build for plain TRX, with the same fields you would use for a normal send. The API returns the unsigned raw transaction. Sign that payload wherever your keys live: an HSM, an air-gapped machine, a signing service behind your own firewall. Then submit the signed result through POST /api/v2/tron/transactions/broadcast, which pushes it to the network and returns the transaction hash.

# 1. Build the unsigned transaction
curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/trc20/build \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contractaddress": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t", "from": "TColdWallet", "to": "TRecipient", "amount": 1000}'

# 2. Sign locally with your own tooling, then broadcast
curl -X POST https://app.chaingateway.io/api/v2/tron/transactions/broadcast \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"signed_transaction": "<the signed transaction as a JSON string>"}'

Two things to know before choosing this mode. A built TRON transaction expires after a short window, so the sign-and-broadcast step needs to happen promptly rather than sitting in a queue overnight. And the operational responsibility shifts: your side owns the signing library and its updates. What you gain is that Chaingateway never sees a secret. Deposit monitoring is unaffected either way, since watching an address requires no key. Many production setups mix both modes, imported keys for low-value operational wallets, self-signing for the treasury path.

Webhooks: deposits without polling

Polling an explorer for incoming transfers wastes requests and still gets the timing wrong. Chaingateway pushes instead. Register a webhook and your backend receives a POST for transaction status, confirmations and balance changes. Set a personal secret in your account and each delivery carries an X-Signature header — a base64-encoded HMAC-SHA256 of the payload's txid — so you can verify the sender. Deliveries that fail land in a failed-notifications list, and POST /api/v2/tron/webhooks/notifications/{id}/retry sends any of them again.

GET /api/v2/tron/webhooks/notifications returns past notifications, useful when you need to replay events after a bad deploy. Setup takes a few minutes with the webhook guide.

Staking: turn burned fees into owned resources

High-volume senders should not burn TRX forever. Freeze TRX via POST /api/v2/tron/freeze and the network grants Bandwidth or Energy in return; route those resources to your hot wallet with POST /api/v2/tron/delegate. Unfreeze and undelegate reverse both steps when you want the capital back.

Current resource prices come from GET /api/v2/tron/chainparameters. Since Proposal #104 the Energy unit price is 100 Sun, down from 210, which changed the break-even point between staking and burning. Check the live value before you size a stake.

The arithmetic favors staking as volume grows, because burned TRX is gone while staked TRX is merely parked. As a rough figure from mid-2026, a stake in the region of 5,000 TRX generated about one USDT transfer's worth of Energy per day. A business sending 50 transfers a day would need a stake in the low hundreds of thousands of TRX to cover its Energy entirely from staking. Treat these as orders of magnitude rather than quotes: your daily yield depends on how much TRX the whole network has staked, and that ratio drifts. The fee calculator and the chain parameters endpoint give you today's inputs for the calculation.

Delegation is what makes staking operationally clean. Keep the stake on a treasury address that never touches customer traffic, then delegate its Energy to the hot wallets doing the actual sends. When a wallet is retired, undelegate and point the resources at its successor; the staked TRX itself never moves. One caveat for treasury planning: after unfreezing, TRX stays locked for a waiting period of around two weeks before it is spendable again, so a stake is not an instant-access reserve. Size it from steady-state volume and cover spikes with rented Energy instead.

Any token on TRON, including your own

Chaingateway supports the standard token types on TRON. USDT, USDC and DAI work out of the box with automatic decimal handling. For a token you launched yourself, pass its contract address and the API treats it like any other TRC-20. The request schema is shared across chains, so the ERC-20 call on Ethereum, BNB Smart Chain, Polygon or Arbitrum looks exactly like your TRC-20 call, with a different path segment.

Why developers pick TRON for payments

The network is designed for roughly 2,000 transactions per second, which suits payment workloads made of many small transfers. Fees stay low enough that micropayments remain viable, a few TRX per token transfer rather than a fee that eats the payment. TRON holds a larger share of circulating USDT than any other chain, so the counterparties your users deal with are already there, and the wallet ecosystem around TRC-20 is mature enough that tooling rarely gets in the way.

Built for payment workloads

Typical integrations look like this: a checkout flow that accepts USDT and credits the order after confirmation; an exchange backend that watches thousands of deposit addresses and processes withdrawals from a hot wallet; payout systems that run airdrops or vesting schedules; subscription billing that charges in stablecoins each month; remittance services that move value across borders in minutes. The same API covers each pattern. What changes is which endpoints you combine.

Test the full flow on testnet first

Every endpoint on this page accepts the header X-Network: testnet. With it, the identical request runs against the TRON testnet: same paths, same payloads, same response shapes. Test TRX comes free from public faucets, so a complete rehearsal costs nothing, create a deposit address, send a TRC-20 transfer to it, receive the webhook, verify the HMAC signature, sweep to a hot wallet.

Rehearse the webhook path at least once end to end. The classic integration mistakes, a signature check against the wrong payload encoding or a firewall that silently drops the delivery, surface on testnet exactly as they would in production, where they cost real deposits instead of test tokens. Going live afterwards means deleting one header; the quickstart shows the whole cycle.

When requests fail

Two failure classes want opposite handling. A 4xx response means the request itself is wrong: a missing or expired Bearer token, a malformed address, an amount the sending wallet cannot cover. Log it and fix the cause, but do not retry unchanged, because identical input produces identical rejection. A 5xx response or a network timeout says nothing about your input; retry those with exponential backoff and a cap.

The edge case worth engineering for is the timeout after a send. Your HTTP client gave up, yet the transaction may still have been broadcast. Firing the identical transfer again on reflex is how double payouts happen. Check first what actually went out: GET /api/v2/tron/transactions lists the transfers created through your account. Resend only if the first attempt verifiably failed. For fee-related failures there is a cheaper pattern still: check GET /api/v2/tron/chainparameters and the wallet's resources before sending, turning a runtime error into a pre-flight check.

From signup to production in four steps

1. Get your API key. Register and the key is available right away. The trial runs 7 days and needs no KYC to start.
2. Make your first request. The quickstart walks through the first address and the first transfer.
3. Set up webhooks. Point a URL at your backend and subscribe to deposit events, as shown in the webhook guide.
4. Go live. Remove the X-Network: testnet header; the code stays the same. Plans and limits are listed on the pricing page.

FAQ

How are private keys handled?

You choose. Import a key via POST /api/v2/tron/addresses/import and Chaingateway signs transactions for you. Or build transactions with the /build endpoints, sign them locally and submit through /transactions/broadcast. In the second mode no key ever leaves your infrastructure.

How much does a USDT transfer cost through the API?

The network fee is the same as anywhere else: about 6.4 TRX to an active address and about 13.4 TRX to an empty one, at the current Energy price of 100 Sun. Use the fee calculator or GET /api/v2/tron/chainparameters for an exact figure before sending. API plan pricing is separate and listed on /pricing/.

What is the TRON Paymaster?

A mechanism that pays Energy and Bandwidth on behalf of the sending wallet, so USDT can move out of an address that holds no TRX. Chaingateway's Paymaster endpoints (POST /api/v2/tron/paymaster, /estimate, /balance) remain documented and functional, but the developer docs mark the feature as deprecated and recommend TronFuel, an Energy-rental API, for new integrations.

Do you support testnets?

Yes. Send the header X-Network: testnet with any call and it runs against the TRON testnet. Endpoints, payloads and responses stay identical, so switching to mainnet later is a one-line change.

Can I use the same integration for other chains?

Yes. The chain sits in the path: /api/v2/tron/transactions/trc20 becomes /api/v2/ethereum/transactions/erc20 or /api/v2/bsc/transactions/bep20. Payloads follow the same schema, so adding a chain is mostly a configuration entry.

What about rate limits and pricing?

Limits depend on the plan; details are on the pricing page. Every plan starts with the 7-day trial without KYC, so you can test against real traffic before paying.

What is the difference between TRC-10 and TRC-20 tokens?

TRC-10 tokens are native protocol assets: no smart contract runs when they move, so transfers cost only Bandwidth. TRC-20 tokens live in smart contracts, follow the same interface idea as ERC-20 and need Energy on top. Nearly every asset that matters commercially, USDT included, is TRC-20. The API sends both, through /transactions/trc10 and /transactions/trc20 respectively.

How fast are TRON transactions confirmed?

TRON produces a block roughly every 3 seconds, so a transfer is included almost immediately, and most integrations treat a deposit as settled within about a minute once enough blocks have confirmed it. Webhooks push confirmation updates to your backend as they happen; how many confirmations you require before crediting a customer is your policy decision, not the API's.

Do I need to run my own TRON node?

No. The API replaces node operations entirely: no sync, no storage growth, no client upgrades at 3 a.m. If you were planning a node purely to send transactions and watch deposits, the REST endpoints cover both jobs. Self-signing mode keeps the trust argument too, because your keys stay with you and the node's role shrinks to transport.

How do I monitor deposits across thousands of addresses?

Register webhooks for your deposit addresses and process the incoming POSTs; there is no polling loop that has to scale with your address count. Deliveries carry an HMAC signature you can verify, failed ones are kept in a list, and a retry endpoint re-sends them one by one. After an outage on your side, GET /api/v2/tron/webhooks/notifications lets you re-read what you missed instead of reconciling against a block explorer.

Ready to integrate TRON?

Create an account at app.chaingateway.io/register, grab the API key and send your first testnet TRC-20 transfer. The full endpoint reference is in the docs.