Denial of Service

A malicious smart contract or transaction consumes all available gas in a wallet's execution context, causing a transaction to revert and funds to be locked. This is common in multi-signature wallets or account abstraction contracts where complex logic can be exploited.

• Example: A malicious approve function call enters an infinite loop, exhausting the gas limit for the entire batch transaction.
• Impact: Legitimate transactions fail, rendering the wallet temporarily unusable.

Attackers flood a wallet's connected RPC node or backend service with a high volume of requests, causing timeouts and preventing the wallet from fetching blockchain data or broadcasting transactions.

• Targets: Public RPC providers, wallet-specific APIs, and indexing services.
• Mitigation: Wallets use rate limiting, failover to alternative providers, and decentralized RPC networks.

Exploiting transaction malleability (altering a TXID without changing its semantic meaning) or replay attacks across forks can cause a wallet's internal state to desynchronize, leading it to reject valid transactions.

• Historical Context: A key issue in early Bitcoin, mitigated by SegWit.
• Wallet Impact: Confusion over transaction status, requiring manual state resets.

In DAO treasuries or smart contract wallets with timelocks and proposal queues, an attacker can submit spam proposals to fill the queue. This blocks legitimate governance actions, effectively freezing funds controlled by the wallet's multi-sig.

• Mechanism: Proposals have a minimum duration; filling all slots creates a long blockade.
• Defense: Requires careful governance parameter design (e.g., proposal deposits, queue limits).

A contract or protocol requires the wallet to verify an computationally expensive, unbounded number of signatures (e.g., in a merkle proof). The verification cost exceeds the block gas limit, causing the wallet's transaction to fail.

• Context: Affects wallets interacting with certain bridges or airdrops.
• Solution: Protocols must implement gas-efficient verification and reasonable limits.

Attackers target the wallet's web or mobile interface, not the blockchain. Malicious dApps or crafted transaction data can cause the wallet's UI to freeze or crash by consuming excessive memory or CPU during simulation.

• Example: A malicious token with an overly complex balanceOf hook causes infinite re-renders.
• Protection: Sandboxing, timeouts, and input validation in the wallet client.

Targeting the core consensus protocol to halt block production. In Proof of Stake (PoS) networks, this could involve attacks on validator nodes to take them offline or manipulate peer-to-peer (P2P) gossip protocols. In Proof of Work (PoW), while costly, a 51% attack could be used to orphan blocks and create chain instability. These attacks aim to break the liveness guarantee of the blockchain.

Attacking the critical off-chain data feeds that DeFi protocols depend on. An attacker could spam an oracle network with fake data or transaction calls to trigger erroneous price updates or exhaust its reporting capacity. This can cause oracle failure, leading to incorrect liquidations, broken swaps, or frozen protocols that rely on accurate external data.

Exploiting the complex message-passing systems of cross-chain bridges. An attacker can spam the bridge with invalid or repetitive messages, clogging its relayer network or verification circuits. This can delay or halt asset transfers between chains, causing a loss of funds or confidence. The interconnected nature of bridges makes them a high-value target for cascading disruption.

A classic DoS vector where an attacker floods the network with low-value transactions, consuming block space and driving up gas prices to price out legitimate users. Mitigations include:

• Base Fee Mechanism: EIP-1559's variable base fee automatically adjusts based on network demand, making sustained spam economically prohibitive.
• Gas Limits per Block: A hard cap on computational work per block prevents a single block from halting the network.
• Prioritization Fees (Tips): Users can pay a premium to have their transactions prioritized, ensuring critical operations can bypass congestion.

Attacks that target a node's computational resources by forcing it to execute expensive operations. A historical example is the 2016 Ethereum Shanghai DoS attacks, which exploited low-gas opcodes for memory and storage operations.

Key mitigations include:

• Gas Cost Re-pricing: Networks periodically audit and increase the gas cost of underpriced, resource-intensive opcodes.
• Wasm Engine Limits: For WASM-based chains (e.g., Polkadot, Near), strict limits on memory, CPU cycles, and stack depth are enforced at the virtual machine level.
• Node-Level Rate Limiting: Individual validators can implement connection and request limits to shield themselves from abusive peers.

An attack that aims to bloat the blockchain's state (e.g., account storage) indefinitely, increasing node hardware requirements and sync times. This is done by creating many empty accounts or storing large amounts of data cheaply.

Mitigation strategies involve:

• Storage Rent: Proposals where contracts pay ongoing fees for state storage, incentivizing cleanup.
• State Expiry: Schemes to move inactive state to a secondary archive, keeping the active state manageable.
• EIP-4444 (History Expiry): Client-side pruning of historical block data after a retention period, reducing storage burden.

Targeting the peer-to-peer networking layer to isolate nodes or waste bandwidth. Examples include eclipse attacks (surrounding a node with malicious peers) and sybil attacks (creating many fake node identities).

Defenses are implemented at the client level:

• Peer Scoring: Clients like Geth assign scores to peers based on behavior, deprioritizing or banning malicious ones.
• Inbound Connection Limits: Restricting the number of incoming connections prevents a node from being overwhelmed.
• Random Peer Selection: Ensuring a diverse, random set of peer connections to resist eclipse attempts.

Attacks that aim to halt block production entirely. In Proof of Stake, this could involve preventing a validator subset from proposing or attesting. In Proof of Work, it could be a 51% attack to censor transactions.

Protocol-level mitigations include:

• Slashing: Penalizing and ejecting validators for provable malicious actions like double-signing or liveness violations.
• Inactivity Leak: In PoS (e.g., Ethereum), if the chain fails to finalize, inactive validators gradually lose stake, allowing the active majority to regain control.
• BFT Timeouts: Consensus protocols have built-in round timeouts to progress if a leader fails.

Vulnerabilities within contract logic that can lead to permanent denial of service. Common patterns include:

• Block Gas Limit Loops: Iterating over unbounded arrays can exceed gas limits, freezing funds.
• Forced Ether Reception: A contract can be DoS'd if it lacks a payable function but can receive ether via selfdestruct or coinbase rewards.
• Owner/Guardian Centralization: A single-point-of-failure private key loss can permanently lock a protocol.

Mitigation involves audits, using pull-over-push patterns for payments, and implementing timelocks or multi-sig controls for critical functions.

A classic on-chain DoS vector exploited in 2016. Attackers filled blocks with computationally cheap but state-expanding operations (e.g., creating empty accounts via SELFDESTRUCT). This bloated the Ethereum state, causing nodes to slow down or crash as they struggled to process the ever-growing data, effectively denying service to legitimate users. The fix required a hard fork (EIP-150) to increase the gas cost of these specific operations.

Solana's high throughput design has been stress-tested by transaction floods. In September 2021, a surge of bot transactions from a Decentralized Exchange (DEX) launch and NFT mint overwhelmed the network. Validators could not process the queue, causing the network to fork and stall for ~17 hours. This highlighted the challenge of maintaining liveness under extreme, coordinated load, even with high theoretical Transactions Per Second (TPS).

An economic DoS attack targeting the Unspent Transaction Output (UTXO) set. Attackers send tiny, uneconomical outputs (dust) to thousands of addresses. This UTXO set bloat forces all nodes to store more data. More critically, if spent later, these dust outputs can be aggregated into a single transaction, forcing nodes to validate thousands of signatures at once, consuming significant CPU and memory resources and slowing block validation.

A 2016 Ethereum Ponzi scheme contract, GovernMental, was frozen by a DoS attack. The contract's withdraw function iterated over all investors to calculate payouts. An attacker funded numerous wallets with small amounts, making the payout loop so large it would exceed the block gas limit, rendering the contract's funds permanently inaccessible. This is a gas limit DoS via intentional state manipulation.

Optimistic Rollups like Arbitrum and Optimism rely on a central sequencer to order transactions. If this sequencer goes offline (e.g., due to infrastructure failure or a targeted attack), users cannot submit transactions to the L2, causing a liveness failure. While users can force transactions via L1, this is slower and more expensive. This represents a single point of failure DoS risk in otherwise decentralized systems.

A common infrastructure-level DoS. Public Remote Procedure Call (RPC) endpoints (e.g., Infura, Alchemy) are used by dApps to interact with blockchains. If an application experiences a traffic surge or is targeted by a botnet, it can exhaust request quotas or overwhelm the endpoint, causing downtime for all users of that service. This demonstrates how centralized service dependencies can become DoS bottlenecks in a decentralized ecosystem.