Use cases
Four common setups, each with the settings that make it work. One account can run several of them side by side: each is just a scenario.
Sweep deposit addresses for less
The situation. An exchange, a payment gateway or a merchant gives each customer their own deposit address. Payments land all day, and each one has to be swept to a hot wallet. Without Energy, every sweep burns TRX from the deposit address, so someone has to keep TRX on thousands of addresses or pay the burn. A fresh deposit address isn't even activated on TRON until it gets TRX.
The setup. Create a scenario:
| Setting | Value | Why |
|---|---|---|
| What should TRONAgg Radar do? | Add Energy when USDT arrives | Energy only when there's something to sweep. |
| Add Energy when deposits reach | 100 (or 50 or 10 if small payments matter) | Below this, a sweep isn't worth its cost. USDT already on the address doesn't count. |
| Energy each time | 65,000 | The sweep goes to your hot wallet, which already holds USDT. |
| Times per address a day | 5 (default) | One addition per deposit; this only caps unusual days. |
| TRX a day | Enough for a busy day | The form shows how many additions the budget buys at the current price. |
| Add Energy again if not swept within 1 hour | On if your sweeper runs in batches | Energy lasts one hour. |
| Send alerts to | Your webhook, plus a Telegram group for operations | The sweeper reacts to the webhook; people see problems and security. |
Give the Telegram group only Problems and Security, so people see what needs them and your webhook gets everything.
Add the addresses with a CSV, or from your backend with POST /api/v1/watch/addresses as you create them, with your customer or invoice number as the external_id.
What happens. A customer pays 1,250 USDT. Radar sees the deposit, adds Energy for one transfer and sends Ready to sweep: address.sweep.ready to your webhook. Your sweeper signs and sends the sweep. The timeline shows Sent 1,250.00 USDT with Energy and an estimate of the TRX it saved. More deposits on the same address before the sweep don't add more Energy.
The result. No TRX parked on deposit addresses. Each sweep costs the Energy rate of that hour instead of the TRX burn; the first one also activates the address. Deposits that wait too long are easy to spot in Waiting to sweep. The developer quickstart has a working sweeper skeleton.
Keep payout wallets ready
The situation. A payout service sends hundreds of USDT payouts a day from a few hot wallets, often to customers' brand-new wallets. A payout without enough Energy burns TRX, and one with too low a fee limit can fail.
The setup. One scenario for the hot wallets:
| Setting | Value | Why |
|---|---|---|
| What should TRONAgg Radar do? | Add Energy after each transfer | Every payout uses the Energy; Radar refills it for the next one. |
| Energy each time | 131,000 | Recipients often hold no USDT, so a payout needs about twice the Energy. |
| Times per address a day | Your payouts per wallet per day, with room to spare | Each payout needs one addition. The default of 5 would stop Radar after five payouts. |
| TRX a day | Payouts a day × the price of one addition | The form shows how many additions the budget buys at the current price. |
| Alert when USDT drops below | The balance you never want to go under | You get USDT balance is low in time to refill the wallet. |
| Send alerts to | A Telegram group with Problems and Security | The team hears about anything that could cost money. |
Then open each wallet once and press Add Energy, so the first payout is covered too. From then on, Radar refills after every payout.
What happens. A payout goes out on Energy. Radar sees it and adds Energy for the next one, usually within seconds. If a wallet runs short, the group gets Not enough Energy, with an Add Energy now button in your private chat. If a payout slips out before the refill, TRX burned shows what it cost and what Energy would have cost; Transfer failed with out of Energy tells you to add Energy or raise the fee limit.
Tip. Energy can't be added to a transfer that's already been sent. If your wallets send several payouts within seconds, check that the wallet is Ready before each one, or use AutoEnergy, which keeps Energy on a wallet ahead of time.
Watch deposits for free
The situation. An OTC desk, a shop or a family wallet wants a message the moment USDT lands, without writing code and without paying for Energy.
The setup.
| Setting | Value | Why |
|---|---|---|
| What should TRONAgg Radar do? | Only alert me | Free, for up to 100 addresses. |
| Warn when an address can't send without burning TRX | Off | You only want deposits; the addresses show Watching deposits and never appear as a problem. |
| Send alerts to | Your Telegram chat or your team's group | Deposits & transfers, plus Security. |
What happens. A client sends 5,000 USDT; the group sees ⬇️ +5,000.00 USDT from TYqHsa…ggvo and the new balance within seconds. A busy day folds into one digest message instead of dozens. In your private chat, Mute 1h quiets a noisy address for an hour.
The result. It costs nothing. When you do need to send from one of these addresses, press Add Energy on its page to buy Energy for that one transfer.
Guard treasury wallets
The situation. A company keeps its reserves on a few cold wallets and a multi-signature treasury. They rarely move, which is exactly why a change nobody planned has to be seen at once.
The setup.
| Setting | Value | Why |
|---|---|---|
| What should TRONAgg Radar do? | Only alert me | Free; these wallets don't need Energy every day. |
| Warn when an address can't send without burning TRX | On if the treasury sometimes sends USDT | You hear about missing Energy before a planned transfer, not after. |
| Alert when USDT drops below | Optional | A floor for the reserve. |
| Send alerts to | Telegram (direct messages) for the people responsible, a group, and a webhook to your security tools | Security alerts reach every place someone will see them. |
What happens. Someone adds a key to the treasury's owner permission. Radar reports Permissions changed: Owner keys 1 → 2 right after the block, with the transaction. An unlimited USDT approval, a freeze by the issuer or a lookalike address trying to poison the transfer history are reported the same way. Permission changes, freezes and unlimited approvals never fold into a digest.
What to do. Security alerts explains each alert and the first steps to take.