Register the addresses you care about. We watch every block, handle finality, and POST you an HMAC-signed webhook once the deposit is confirmed. No more getblockbynum loops, no more missing-transaction traps — or get alerts straight in Telegram, no server required.
Real deliveries from the last few minutes on addresses we monitor ourselves — three public canary addresses that verify the whole pipeline end-to-end, 24/7 (they also drive our alerting).
| Delivered (UTC) | Asset | To | Tx | Status |
|---|---|---|---|---|
| 2026-09-24 03:29:13 | 3.2223 TRX | TSD2AW…rLUe | e3f4b4655c… | delivered ✓ signature verified |
| 2026-09-24 03:29:13 | 3.2223 TRX | TSD2AW…rLUe | 47e5329fdd… | delivered ✓ signature verified |
| 2026-09-24 03:27:52 | 3.2223 TRX | TSD2AW…rLUe | 3a724d2c97… | delivered ✓ signature verified |
| 2026-09-24 03:27:02 | 6.53055 TRX | TSD2AW…rLUe | 82a5463578… | delivered ✓ signature verified |
| 2026-09-24 03:26:21 | 3.2223 TRX | TSD2AW…rLUe | 5c9caf6ee4… | delivered ✓ signature verified |
Refreshes every 5 minutes; rendered server-side — no tracking, no third-party requests. Last render 03:30:38Z.
Every team building on TRON ends up writing the same fragile scraper. We wrote it once, properly, so you don't have to.
getblockbynum every 3 seconds, parse every transaction, dedupe, retry, repeat. Every team builds the same fragile scraper.
Read from the wrong node and transactions "disappear". We only emit events confirmed by solidity nodes — the #1 cause of missing-deposit bugs, handled.
Your script died at block 85,101,201. Ours has a cursor, catch-up mode, retries with backoff, a dead-letter queue — and an events API to reconcile against.
Two ways in — pick yours.
GET /v1/events as your reconciliation safety net.# 1. Watch an address curl -X POST https://tronhooks.com/v1/watches \ -H "Authorization: Bearer tw_live_..." \ -d '{ "address": "TYourAddress...", "asset_filter": "USDT", "webhook_url": "https://you.dev/hook" }'
// 2. A signed webhook on every confirmed deposit { "api_version": "2026-08", "event_id": "cmshauqa30...", "type": "transfer.confirmed", "network": "mainnet", "asset": "USDT", "to": "TYourAddress...", "from": "TSenderAddr...", "amount": "129.5", "amount_raw": "129500000", "tx_id": "f647d176fe9f...", "event_index": 0, "block_number": 85113777, "block_timestamp": "2026-08-06T09:14:27.000Z", "contract": "TR7NHqje...", "watch_id": "cmshaqna..." }
Events fire only after solidity-node confirmation. No reorg surprises.
Every attempt logged with response codes; failed hooks land in a dead-letter queue you can inspect, not a void.
Read-only infrastructure. We never touch private keys or funds. Nothing to steal, nothing to trust.
Connect Telegram, watch your addresses, get alerts. Zero servers, zero webhooks.
Plans are priced by watched addresses only. A busy address never costs extra and never gets throttled — every confirmed transfer is delivered.
Rate-limit headers, idempotent event IDs, versioned payloads, a TypeScript SDK, a public status page, and a machine-readable /healthz.
Honest comparison of the three ways teams get TRON deposit events.
| tronhooks | DIY polling loop | Raw block / event streams | |
|---|---|---|---|
| Time to first deposit event | minutes | days to weeks | days |
| Finality (no "vanishing" txs) | built in — solidity-only | you implement | you filter, usually |
| Address filtering | server-side, per watch | your code | you sift the full firehose |
| Retries, dead-letter, attempt log | built in | you build | varies, often none |
| Signed payloads (HMAC) | ✓ | n/a | varies |
| Reconciliation after downtime | GET /v1/events | your database | replay you build |
| Event caps | none — priced by addresses | none | often events/day tiers |
| Telegram alerts, no code | ✓ | — | — |
| Upstream quota & node ops | ours | yours | partly yours |
| What you pay | $0 → $9/mo | engineering time + API quota | metered usage |
DIY is the right call if TRON is your core competency and you already run nodes. For everyone else, we handle the block loop so you can ship the product.
Start free. Upgrade when you outgrow three addresses.
| Free | Starter $9/mo | Pro $29/mo | Scale $99/mo | Business | |
|---|---|---|---|---|---|
| Watched addresses | 3 | 20 | 100 | 1,000 | 10,000+ |
| Rate limit | 60 rpm | 120 rpm | 300 rpm | 1,200 rpm | custom |
| Webhooks + events API | ✓ | ✓ | ✓ | ✓ | ✓ |
| Telegram alerts | ✓ | ✓ | ✓ | ✓ | ✓ |
| SLA + dedicated support | — | — | — | — | ✓ |
| Annual (pay for 10 months) | — | $90/yr | $290/yr | $990/yr | Contact us |
Paid plans opening soon — early signups get Pro features free until payments open. Paid tiers are billed in USDT (TRC-20); questions → ops@tronhooks.com.
No. tronhooks is read-only infrastructure — we never generate deposit addresses, never custody funds, never see a private key.
We process at block speed (~3s). A confirmed deposit typically reaches your endpoint — or your Telegram — seconds after finality.
Retries over ~9 hours with exponential backoff (1m/5m/30m/2h/6h). After that the event lands in your dead-letter view, and GET /v1/events always has the full history for reconciliation.
Yes. Connect Telegram in the console, add the addresses you care about, and get alerts on every confirmed deposit. Console-only, no code, no server.
No. Plans are priced by the number of watched addresses only — there is no events-per-day quota, no overage, and a busy address is never throttled. Rate limits apply to your API calls, not to the webhooks we send you.
USDT (TRC-20) and native TRX today, with incoming, outgoing, or both directions per watch. Any-TRC-20 support is on the roadmap.