Smart Contract Security · Term

What is a contract DoS?

A smart contract denial of service makes a function, or the whole contract, permanently unusable, sometimes locking funds forever. Here is how DoS happens on-chain and how to design around it.

Smart Contract Security · TermSmart Contract Audit
TL;DR

A smart contract denial of service (DoS) makes a function or an entire contract unusable, sometimes permanently, which can lock funds forever. Unlike traditional DoS, it is usually a logic or design flaw: a loop over an unbounded array that runs out of gas, a payment to an address that always reverts (blocking a queue), or a privileged role that gets stuck. Because contracts are immutable, a DoS bug can be unrecoverable. The fix is pull-over-push payments, bounded loops, and no single point that can block everyone.

By SecureLayer7 Audit Team, Smart Contract Audit, SecureLayer7Updated

What it is

On-chain DoS is rarely about traffic; it is about getting the contract into a state where it cannot proceed. Each transaction has a gas limit, and some operations can be forced to revert, so a contract can be made to fail every time a function is called.

The danger is that contracts are immutable: if a function that controls funds becomes permanently un-callable, the funds can be locked forever with no way to patch it.

How it works and example

Common on-chain DoS patterns:

  • Unbounded loop / gas exhaustion: a function iterates over an array anyone can grow (for example a list of participants). Once it is large enough, the loop exceeds the block gas limit and the function can never complete.
  • Revert-based DoS (push payments): a contract pays out by pushing funds in a loop; one recipient is a contract that always reverts, so the whole distribution fails for everyone.
  • Stuck privileged role: an owner-only step where the owner key is lost or set to a contract that cannot act, freezing the protocol.

Documented for defensive context.

How to defend

  • Use pull-over-push payments: let each user withdraw their own funds, so one bad recipient cannot block others.
  • Avoid unbounded loops over user-growable arrays; cap iteration or use pagination/withdrawal patterns.
  • Never let one external call’s failure halt a process for everyone; isolate failures.
  • Avoid single points of control that can get stuck; use multisig and recovery paths for privileged steps.
  • Audit and gas-test functions against worst-case sizes and reverting counterparties.

References

  1. [1]SWC Registry: Smart Contract Weakness Classification(SWC Registry)
  2. [2]Solidity docs: Security considerations(Solidity)
  3. [3]MITRE CWE-400: Uncontrolled Resource Consumption(MITRE CWE)
Related terms

Common questions

Smart contract security, asked often

Shipping a contract on-chain soon?

Scope an audit

Get your smart contracts audited before they go on-chain.

Our auditors review your Solidity line by line and model the economic attacks a real adversary would run, then deliver a report your team can act on with every finding reproduced and a fix. Re-test of fixes included.

See smart contract audit30-min scoping call, fixed-price proposal in 48 hours.