Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
A smart contract denial-of-service vulnerability makes required behavior unavailable to legitimate users. The failure may block one account, one market, or the entire protocol. Funds need not be stolen for the impact to be severe: permanently unreachable withdrawals are a security failure.
Unbounded work is a frequent cause. A function that iterates over every voter, position, or recipient may eventually exceed the block gas limit even through normal growth. Solidity's gas and loop guidance warns that storage-dependent loops can stall on-chain operations.
External calls create another liveness dependency. If a batch requires every recipient call to succeed, one contract that deliberately reverts can block the whole batch. Auctions that refund the previous leader before recording a new bid have the same problem.
Other cases include attacker-controlled queue growth, dust positions that make settlement too expensive, a privileged key becoming unavailable, arithmetic that always reverts in a reachable state, and state machines with no legal transition out of an error condition. A costly transaction is not necessarily exploitable; the attacker must be able to create or sustain the blocking condition at an acceptable cost.
Identify operations required for exits, liquidation, settlement, governance, and recovery. For each, bound work by protocol state rather than by expected usage. Trace every external call and determine whose failure propagates. Inspect queues and arrays for cheap insertion but expensive cleanup.
Test at maximum realistic and adversarial cardinality. Include reverting recipients, contracts that consume gas, duplicate or dust entries, paused dependencies, lost administrators, and partial progress followed by retry. Measure gas as state grows and verify that a user can always exit independently where that is an intended guarantee.
Liveness invariants should state what remains possible after each failure. Examples include an honest account being able to withdraw its own credit and a keeper being able to resume settlement from a checkpoint.
Prefer pull payments so each recipient claims independently. Solidity's withdrawal pattern isolates a reverting recipient from other users. Apply checks, effects, and interactions to the claim path to address reentrancy as well.
Bound batches, checkpoint progress, and make retries idempotent. Pagination alone is insufficient if every batch restarts from zero or if entries can be inserted faster than they are processed. When a failed external call is skipped, preserve the recipient's claim and emit enough state for a later retry; silently ignoring failure can create loss.
Emergency controls may restore service, but they add privileged-role and key-availability risks. Design escape hatches around narrow, documented states and test them.
Repository analysis can identify unbounded loops, failure-propagating calls, and some state locks. It cannot establish future state size, external contract behavior, transaction inclusion, gas-market conditions, or keeper availability from source alone.
Is every loop a denial-of-service risk?
No. Fixed or tightly bounded loops can be safe. Risk appears when required work can grow beyond an executable gas bound.
Should code ignore failed transfers in a batch?
Not blindly. Isolate the failure while preserving correct accounting and a retry or individual claim path.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Assess smart contract admin powers, upgrade authority, key custody, delays, caps, and the limits of source-only centralization analysis.
Understand first-depositor and donation attacks against tokenized vaults, rounding conditions, tests, and mitigation tradeoffs.
Review accounting assumptions for fee-on-transfer, rebasing, and other non-standard ERC-20 tokens, with test and mitigation guidance.
Understand transaction-ordering risk, sandwich attacks, the conditions that make them profitable, and practical review and mitigation techniques.
Learn how weak swap bounds expose users and vaults to adverse execution, how to review integrations, and where minimum outputs and deadlines fall short.