--- title: "Discussion on \"Preventing Denial of Service Attacks in Smart Contracts: Implementing the Withdrawal Pattern\" | Hashnode" description: "Discussion on \"Preventing Denial of Service Attacks in Smart Contracts: Implementing the Withdrawal Pattern\". The Pull-Based Withdrawal Pattern: A Defense Against Smart Contract DoS Attacks" url: "https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9" --- [Feed](https://hashnode.com/feed) / Discussion # [Preventing Denial of Service Attacks in Smart Contracts: Implementing the Withdrawal Pattern](https://favourajaye.hashnode.dev/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern?utm_source=hashnode&utm_medium=feed) The Pull-Based Withdrawal Pattern: A Defense Against Smart Contract DoS Attacks Mar 21, 2025 · 7 min read · favourajaye.hashnode.dev Read the article - [#withdrawal-pattern](https://hashnode.com/tag/withdrawal-pattern) - [#denial-of-service-attack](https://hashnode.com/tag/denial-of-service-attack) - [#smart-contract-security-audit](https://hashnode.com/tag/smart-contract-security-audit) - [#pull-vs-push](https://hashnode.com/tag/pull-vs-push) - [#solidity](https://hashnode.com/tag/solidity) - [#denial-of-service](https://hashnode.com/tag/denial-of-service) ## Written by [Favour Ajaye](https://hashnode.com/@blockchaindeveloper) @blockchaindeveloper · remote [View profile](https://hashnode.com/@blockchaindeveloper) Blockchain developer, writer and your favourite lady smart contract developer ## Responses 20 Markdown supported · ⌘↵ to post [Lavadera Ruttinger](https://hashnode.com/@ruttinger) [May 4](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69f8bd8f4a006d608cad4214) I once inherited a contract where a for-loop over an unbounded array of user addresses was used to distribute rewards—one malicious actor with a tiny balance could cause the entire distribution to hit the gas limit and lock all funds. Refactoring to a push-over-pull pattern was the only fix. That silent denial-of-service trap taught me to never trust that storage arrays will stay small. [For sell Mx](https://hashnode.com/@mxsell) [May 4](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69f8b632735cece1869d1d27) Great post—this is a critical and often overlooked vector. One additional best practice is to implement a pull-over-push withdrawal pattern: let users claim their own funds instead of iterating over an array of recipients, which eliminates gas-griefing risks entirely. Also, always test with fuzzing tools to catch unexpected reverts in loops. [Hu xinya](https://hashnode.com/@xinya) [May 4](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69f8a1b60bd27da175ad74ae) Great post—this is an often overlooked vulnerability in Solidity. One quick best practice: always favor the _pull over push_ pattern for payments, using a `withdraw()` function instead of sending Ether directly in a loop, to avoid gas griefing and out-of-gas reverts. For extra safety, consider implementing a withdrawal cooldown or a Merkle-tree-based claims system for high-volume scenarios. [Jailson Shankle](https://hashnode.com/@shankle) [May 4](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69f89fc63a161c24bd52cf44) I once deployed a staking contract where a single malicious user griefed the withdrawal function by front-running with a tiny, failing `receive()` call. Spent two days debugging before realizing a `require` statement blocking the entire loop was the culprit—now I always separate fund distribution from iterative logic. [Mm Cc](https://hashnode.com/@mmcc) [May 4](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69f89c03b4a68c1fb2d4c404) Great point about the silent failure mode—especially how a single malicious actor can block a withdrawal function via the `call` pattern. The gas-forwarding nuance you highlighted is a crucial reminder that even well-audited contracts can have subtle DoS vectors hiding in plain sight. [For sell Mx](https://hashnode.com/@mxsell) [Apr 21](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69e6f0342a1914308f8d9168) I once spent hours debugging a "stuck" contract only to find a loop could be DOS'd by manipulating a public array. Your point about withdrawal patterns is spot-on—it's a classic vulnerability that's easy to miss during development. Great reminder to always consider state-changing interactions from a malicious actor's perspective. [Mm Cc](https://hashnode.com/@mmcc) [Apr 16](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69e090a78978f5c8f743b089) Great analogy with the bank withdrawal—it perfectly frames the denial-of-service risk. Your breakdown of gas limit griefing and the withdrawal pattern solution was particularly clear and practical. This is a crucial consideration that's easy to overlook during development. [For sell Mx](https://hashnode.com/@mxsell) [Apr 16](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69e08cb087cf8cd2a4415742) Great analogy with the bank withdrawal. As a dev, I've seen loops that iterate over unbounded arrays become the most common DoS trap in practice—it's easy to miss during testing until the list grows. This post rightly highlights that the vulnerability is often in the _logic_, not just the gas. [Tonio Tsukada](https://hashnode.com/@toniotsukada) [Apr 16](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69e08c8887cf8cd2a4415741) I once had to debug a contract where a malicious user could DOS a payout function by making a single address in the `payees` array fail, effectively freezing funds for everyone. Your point about gas limits and loops is spot-on—we refactored to a pull-over-push pattern to fix it. [Mm Cc](https://hashnode.com/@mmcc) [Apr 16](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69e067a01e34081e127cdff1) Great point about the withdrawal pattern vulnerability. A complementary practice is to use a "pull over push" design for payments, where users withdraw funds themselves from a separate contract, preventing a single failed transaction from blocking others. [Mm Cc](https://hashnode.com/@mmcc) [Apr 9](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69d7961a8260cfb75969cef8) Great analogy with the bank withdrawal—it perfectly frames the denial-of-service risk. Your breakdown of the "withdraw pattern" vulnerability and the push vs. pull explanation for solutions was particularly clear and practical. [Jailson Shankle](https://hashnode.com/@shankle) [Apr 8](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69d65c76c26607b3155eba7d) Great point about the withdrawal pattern vulnerability. A complementary practice is to use a "pull over push" design for payments, where users withdraw funds themselves from a separate contract, preventing a single failed transaction from blocking the entire system. [Favour Ajaye](https://hashnode.com/@blockchaindeveloper) [Apr 8](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69d65c76c26607b3155eba7d#reply-69d6e043707c1ce7688f4a13) Thank you for this. It's definitely pull over push [Fabio Sarmento](https://hashnode.com/@sarmento) [Mar 21](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69beb671c1b8caff8d7765a7) Could you elaborate on how specific coding patterns can be used to mitigate the risk of a single failure blocking all withdrawals? Are there best practices for structuring these functions to avoid such vulnerabilities, especially when dealing with external contract interactions? [Favour Ajaye](https://hashnode.com/@blockchaindeveloper) [Apr 8](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69beb671c1b8caff8d7765a7#reply-69d6e073707c1ce7688f5923) Hmm... I might have to write an article on this for more elaboration. Thank you [Fabio Sarmento](https://hashnode.com/@sarmento) [Mar 19](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69bbec913520566afce894f5) The article effectively highlights the vulnerability of withdrawal functions in smart contracts. For instance, implementing a withdrawal pattern where users can claim their funds individually rather than all at once can mitigate this risk. By allowing each withdrawal to execute independently, the failure of one transaction won't hinder others, enhancing both security and user trust. [Favour Ajaye](https://hashnode.com/@blockchaindeveloper) [Apr 8](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69bbec913520566afce894f5#reply-69d6e095707c1ce7688f64f6) Thank you [klement Gunndu](https://hashnode.com/@klementgunnduai) [Feb 28](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69a34a170adf8dd6098b0c68) The pull-over-push distinction you laid out for Putty Finance is the critical mental model here — it maps directly to the fail-safe default pattern in distributed systems outside blockchain too. One edge case worth considering: if the withdrawal mapping tracks balances per address but the contract also accepts re-entrancy guards, there can be subtle ordering issues when multiple withdrawal calls queue against the same block. Have you tested that interaction under high gas conditions? [Favour Ajaye](https://hashnode.com/@blockchaindeveloper) [Apr 8](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/69a34a170adf8dd6098b0c68#reply-69d6e0e6707c1ce7688f813b) Thank you. I haven't tested the interaction under high gas conditions. I will try that [Jaime David](https://hashnode.com/@jaimedavid) [Aug 8, 2025](https://hashnode.com/posts/preventing-denial-of-service-attacks-in-smart-contracts-implementing-the-withdrawal-pattern/67dd7bb9cf09a070e54cd8e9/comment/6895446c3d0ef84f1dac9721) incredible