What Happens When a Proposer Goes Silent: A Bounded Wait, and How to Tell That Is Not What You Are Seeing

The mechanism, from the protocol

Every round has a deadline. It starts at two seconds.

If the deadline passes without a certified block, the participant raises a timeout for that round and broadcasts a timeout vote. It then pushes its own deadline forward without changing the round, which the code explains is to stop the loop spinning on an already-expired deadline while it waits for either a timeout certificate or a late proposal.

When enough timeout votes gather into a certificate, the round advances, and the deadline grows by doubling.

When a normal certificate arrives instead, the round advances and the deadline resets to two seconds, with the doubling counter cleared.

The wait is bounded, and that is the important property

The doubling is capped at sixteen seconds.

So no participant ever waits longer than sixteen seconds on a stuck round before moving on. A proposer that stops speaking costs the network a bounded delay, once, and then the next round starts under somebody else.

That is the whole answer to the question in the title, and it is a good answer: silence is survivable by construction rather than by anybody intervening.

And it gives you a test

Every timed-out round is still a round. It gets consumed, the counter moves, and the next round begins.

So a network genuinely stuck on silent proposers burns rounds fast. With a sixteen-second ceiling, twenty minutes of that would consume somewhere around seventy-five to a hundred rounds.

Which means you can tell the difference from outside, with two numbers a block already gives you:

compare round across consecutive blocks against their timestamp_ms

Many rounds and little time means the network is fighting. Few rounds and much time means something else entirely.

Applied to this chain today, it rules the answer out

Eight consecutive readable blocks were fetched. Between each, the height rose by three and the round rose by exactly three.

The time between them was twenty or thirty minutes.

Zero rounds were lost. So the quiet on this chain is not the pacemaker waiting on a silent proposer, because that path consumes rounds and this one consumes none.

ANSWERED 2026-08-02, and this section invited exactly this. It said the intervals were regular almost to the second, which is a shape organic delay does not have, and declined to guess. The regularity was the clue and the answer is a constant.

First, the interval was wrong. Three chained blocks share one height value on this chain, so counting by height collapsed three intervals into one. Re-measured by canonical sequence, the gap is six hundred seconds, each within a couple of seconds of it, eight times in a row.

Second, it is configured. The node carries a named idle-heartbeat constant, and its comment says the proposer is event-driven: with no work it proposes one empty block every ten minutes, which finalizes the previous burst's leftover blocks, bounds how far participants can drift, and keeps the head advancing for monitoring. The reason given is disk: the free-running proposer wrote on the order of a gigabyte a day and the heartbeat brings it to a few megabytes.

So the quiet is not a fault at all. It is an idle chain doing what it was told, and the two errors that hid it were an index that is not one-per-block and a rate derived from it.

And it corrects something we published

An earlier page described this chain as running at roughly seven minutes per height.

That number averages across the quiet and misleads. When there is work the chain is fast: nine blocks in about seven and a half seconds in the burst this estate measured by sequence. The chain is intermittent rather than slow, and those are different problems with different fixes.

CORRECTED 2026-08-02: an earlier version of this paragraph said three blocks arrive in about a second, from a height-indexed reading. The sequence-indexed measurement is the reliable one, and the intermittence is a configured heartbeat rather than a fault.

What you can check yourself

solidus_canonHead, then solidus_getBlockBySeq downward, comparing round and timestamp_ms

Use the sequence, not the height. The interface's own documentation recommends it for iterating every block, and reading by height here produces intervals three times too long.

Expect to skip heights, because not every height resolves, and scan back rather than assuming consecutive numbers work.