Block production on Tron: the 3-second schedule explained

Tron produces one block every 3 seconds. The schedule is deterministic, round-robin across the active 27 Super Representatives, and resets every 6 hours. There is no proposer auction, no priority fee market, no MEV-style ordering games at the consensus layer. The clock just runs.

That predictability is the whole design point. Once you understand the schedule, you can predict — within a few seconds — when the next block will land, who's about to produce it, and how the network will react if they miss their slot.

The clockwork

Every 3-second slot belongs to exactly one SR. The 27 active SRs cycle in order: SR #1 produces block n, SR #2 produces block n+1, and so on. After all 27 have produced one block, the cycle restarts. So each SR gets a turn every 81 seconds (27 × 3) on the happy path, and over a 24-hour day each one ends up producing roughly 1,066 blocks (28,800 ÷ 27).

The order itself is randomized per epoch — see below — but within an epoch it's fixed. That gives every full node the same expectation about who should produce next, which is what makes "missed block" detection trivial: if the timestamp on the next block lands more than 3 seconds after the previous one, somebody skipped their slot.

The 6-hour epoch

The 27 active SRs aren't permanent. Tron's consensus runs a maintenance period every 6 hours — at 00:00, 06:00, 12:00, and 18:00 UTC. At each maintenance boundary, the network re-tallies vote counts and elects the top 27 vote-getters as the active SR set for the next 6 hours.

If your favorite SR slipped to rank #28, they don't produce blocks for the next 6 hours. If a partner candidate earned enough votes overnight to crack the top 27, they're in. The rotation is the only mechanism through which the active validator set ever changes.

This is also where the production order gets shuffled. The deterministic round-robin within an epoch is fixed, but the order of the 27 is reshuffled each maintenance period using on-chain randomness, so SR #1 in this epoch isn't necessarily SR #1 in the next one.

What happens when an SR misses their slot

Misses happen. An SR's node could be down, network-partitioned, or just slow to broadcast. When the scheduled SR fails to produce in their 3-second window, the protocol simply skips to the next slot — no fallback producer, no second chance. That block height is permanently empty in the chain history.

Two practical consequences:

• The miss counts against the SR's efficiency stat. The validators page tracks totalOutOfTimeTrans (lifetime missed slots) and lastWeekOutOfTimeTrans (recent). Voters use this — high miss counts erode trust and votes.
• The block reward goes uncollected. The 16 TRX block reward is paid only on production. The 160-TRX voting reward pool, however, is distributed proportionally regardless, so other SRs (and their voters) are unaffected.

Compare to Bitcoin, where a miner skipping a "block" doesn't really happen — there's no schedule. Or to Ethereum's PoS, where missed proposals attract slashing penalties under certain conditions. Tron's penalty is purely reputational: the on-chain record shows you dropped the ball, voters see it, and you eventually get voted out.

Block rewards: who gets what

Two reward streams flow per block:

1. Block production reward: 16 TRX. Paid to the SR (or partner) who produces the block. This is the per-block payout — earned only by showing up.
2. Voting reward: 160 TRX. Distributed proportionally to all 27 active SRs based on their share of the total active vote weight. Each SR then passes the voter-share through to the addresses that voted for them, after taking their brokerage (typically 20%).

At 28,800 blocks per day, that's 460,800 TRX of block rewards and 4,608,000 TRX of voting rewards distributed daily — roughly 5 million TRX flowing to validators and their voters every 24 hours. The voting calculator shows how that pool translates to your yield based on what you stake and which SR you back.

Why 3 seconds (the design tradeoff)

Three seconds is short enough that user-facing UX feels close to instant — a tx submitted now lands inside the next block, then needs ~57 seconds to be considered final under the 19-confirmation rule. Bitcoin operates on 10-minute blocks; Ethereum on 12 seconds. Tron's choice is firmly in the fast-finality camp.

The cost of fast blocks is propagation pressure: every node has to broadcast and validate more frequently, which limits how far participation can scale. Tron's answer is to cap the producer set at 27 — small enough to keep latency manageable, large enough to spread production across distinct operators. Whether that's "decentralized enough" depends on who's asking; the validators page lays out the actual data.

What this means in practice

For a user submitting a transaction: it lands in the next 3-second block, almost always. For finality, count to 19 (~57 seconds). For a developer building on Tron: schedule assumptions hold to within a few seconds — block n+10 arrives ~30 seconds after block n, give or take a missed slot. For an SR operator: don't miss your slot, and treat the maintenance period as a redeploy boundary.

The schedule is the most predictable thing on Tron. Once you've internalized it, the rest of the consensus layer follows.