Liveness Risk

Overview

Liveness means that valid operations eventually complete, such as transactions being included, withdrawals becoming available, or consensus advancing. Liveness risk appears when censorship, outages, deadlock, unavailable signers, network partitions, or overloaded dependencies prevent progress.

A system can remain safe by refusing conflicting actions while still becoming unusable. Threshold designs may protect against unauthorized signing yet block all activity when too many participants are offline or unable to coordinate.

Designers should identify progress assumptions, timeout behavior, quorum availability, dependency capacity, and emergency procedures. Monitoring must distinguish slow processing from halted progress, while recovery mechanisms should not weaken safety or permit unauthorized bypass. Service objectives should define the maximum acceptable delay before escalation or intervention.

Dependencies can weaken Liveness Risk even when the primary component behaves correctly.

Liveness risk is the possibility that a system stops making required progress even though its safety properties may remain intact. Security includes continued progress, so quorum availability, timeouts, dependencies, censorship resistance, and safe recovery must be designed together.

For Liveness Risk, the assessment should evaluate the possibility that a system stops making required progress even though its safety properties may remain intact. The assessment record should separate observed evidence supporting the possibility that a system stops making required progress even though its safety properties may remain intact from assumptions, state the time horizon and existing controls, and identify who owns any remaining exposure. Monitoring should test whether the conditions described in the possibility that a system stops making required progress even though its safety properties may remain intact have changed enough to require a new rating, treatment, or approval.