TRON GOBLIN
explorerv0.5-beta
MAINNET
block #83,173,899
LIVE · MEMPOOL · 0s ago
direct from node

Live Tron Mempool

Every transaction broadcast to Tron lands in a node's mempool — the few seconds of queue time before it's sealed into a block. This is that queue, in real time, decoded straight from a node. Watch the shape of activity that the chain is about to commit.

pending now
214
10 decoded · 1 samples
ingest
0.00
tx/s · arriving
confirm
0.00
tx/s · leaving
avg dwell
0ms
median 0ms
in-pool composition · type · count
Transfer 4
Stake / Vote 4
Account 1
TRC10 Transfer 1
mempool size · history
214
min 214 · max 214
ingest rate
0.00 tx/s
peak 0.00 tx/s
confirm rate
0.00 tx/s
peak 0.00 tx/s
next block
3.0s
avg dwell 0ms · median 0ms
in-pool composition · 10 decoded share of pending pool by contract type
Transfer 40.0% · 4 Stake / Vote 40.0% · 4 Account 10.0% · 1 TRC10 Transfer 10.0% · 1
Live arrivals · 10 shown
streaming · feed = decoded sample · pool total is bigger
TYPE · HASH VALUE IN POOL
Transfer
761aa3e2…31bcf5a0
43.303501 TRX
559ms
Account
387542ca…3bcc034f
559ms
Stake / Vote
6147c5e1…4930c6b9
559ms
Transfer
3643f6b4…b6ba83a3
685.15 TRX
559ms
Stake / Vote
3cbf3d87…41a55d6e
559ms
Transfer
99b55914…c866835f
0.000001 TRX
559ms
Stake / Vote
2b36a3dd…1009e722
559ms
Stake / Vote
1aec5933…96879bc8
559ms
TRC10 Transfer
d6ec84d1…2f903470
999,999,999 1005136
559ms
Transfer
497ab144…de7e1d90
0.000001 TRX
559ms
Pool flow · ingest vs confirm
net +0.00 tx/s ◆ balanced
drain ETA at current rate
ingest
0.00
confirm
0.00
Tokens moving · transfers in pool
TRX 4
Most-called contracts
Pool age · how long pending txs have waited
<1s
100%
1–2s
0%
2–3s
0%
3–5s
0%
>5s
0%
Active senders · concentrated activity
Status
node tick 135ms
poll cadence 2.5s
block cadence ≈3s
arrivals · last tick 0
confirms · last tick 0
tracked pool 209 hashes

How this page works

The Tron Goblin server runs an in-process polling loop against a Tron node. Every 2.5s it pulls /wallet/getpendingsize and /wallet/gettransactionlistfrompending, diffs the result against the previous tick to identify newly-arrived transactions, then fetches the decoded body for a sample of those new arrivals through /wallet/gettransactionfrompending. Departures (transactions removed between two ticks) feed the dwell-time histogram.

The snapshot is broadcast to every connected browser over Server-Sent Events at /api/mempool/stream. The page subscribes, tweens the headline numbers between updates, and dribbles new arrivals into the SVG particle field at a paced rate so individual transactions remain legible even when the pool churns by the hundreds per block. The whole pipeline holds state in process memory — no third-party feed, no extra database.

Why Tron's mempool looks the way it does

Tron settles new blocks every ~3 seconds and rewards a single Super Representative per block. The result: dwell time is naturally short (median sub-second on a healthy network) and the pool churns completely every couple of blocks. Long dwell almost always means a transaction with a stuck contract call or an insufficient fee limit bouncing in and out of the queue.

The composition skews heavily toward TRC20 transfers — stablecoin settlement (USDT especially) is Tron's defining workload. You'll see a steady baseline of TRC20 ops plus bursts of native TRX transfers, smart-contract calls (DEX swaps, lending), and the occasional witness vote.

Frequently asked questions

What is the Tron mempool?
The mempool (memory pool) is the queue of pending transactions a node holds before they're sealed into a block. Each Tron node maintains its own copy; the figures on this page reflect the queue on the node powering Tron Goblin. On Tron, blocks arrive every ~3 seconds and most transactions live in the mempool for less than 2 seconds — much shorter than other chains.
How is the live data fetched?
Every ~2.5 seconds the server polls a Tron node's /wallet/getpendingsize and /wallet/gettransactionlistfrompending endpoints, diffs the result against the last poll to identify newly arrived transactions, fetches a sample of their decoded bodies, and pushes a snapshot to every connected browser via Server-Sent Events. No third-party feed; this is the raw queue state.
Why do mempool sizes differ between nodes?
Mempools are local. A transaction broadcast to the network propagates peer-to-peer, so different nodes see it at slightly different moments. They also expire from each node's pool independently once included in a block (or after a configurable timeout). Two nodes a few seconds apart in connectivity will report different pending counts even on the same chain.
What does "dwell time" mean?
Dwell time is how long a transaction sat in the mempool before it left — either because it was included in a block, or because the node evicted it (typically after the user-set expiration window). On Tron the average dwell is sub-second to a few seconds; longer dwells usually signal a fee-limit problem or a stuck contract.
Can I see every pending transaction?
The live feed surfaces a sample of newly-seen arrivals — typically 20–30 fresh ones per tick. To bound memory and bandwidth we don't pull every single hash's body on every poll; the composition stats and pending count cover the whole pool, while the feed shows the freshest activity.
Is this the same as the home dashboard transactions list?
No — the dashboard shows confirmed transactions (already in blocks). This page shows pending transactions — the few seconds of activity before they're confirmed. Same chain, different state.