Trait RoundsWithoutTimeout 

pub trait RoundsWithoutTimeout: TimeoutVoteConditions + SingleLeaderRoundsNeedTimeout { }

Caveat (Rounds that never time out). ChainOwnership::round_timeout returns None — so that ChainManager::create_timeout_vote fails with ChainError::RoundDoesNotTimeOut and no timeout certificate can ever form — in three cases:

round	round_timeout is None when
Round::Fast	timeout_config.fast_round_duration is None, which is the default, or owners is empty
MultiLeader(r)	r + 1 != multi_leader_rounds, i.e. every multi-leader round but the last
SingleLeader, Validator	never

Consequences, which the liveness argument must and does respect:

• A non-final multi-leader round is left only by a proposal in a higher round (SingleLeaderRoundsNeedTimeout). This is by design — multi-leader rounds are skippable — but it means “wait for the timeout” is not a strategy there.
• With a super owner and the default TimeoutConfig, the fast round has no timeout at all. If the super owner issues two conflicting fast proposals, correct validators split between them (FastConfirmationNeedsEmptyLock pins each to the first it sees), neither reaches a quorum, and — since only a super owner may open a later round while the current round is fast, by the is_super(&proposal.owner()) || !current_round.is_fast() guard in ChainManager::check_proposed_block — the height cannot progress until that same super owner proposes again in a higher round. A super owner that stops there wedges the chain permanently. This is the caveat the module documentation of crate::manager states as “super owners must be careful to make only one block proposal”, stated precisely.

Both are liveness properties; CommitAgreement is unaffected.

Implementors