# Users can gas grief or completely block keepers from executing orders

Keeper refunds ETH to user accounts with unlimited gas; a reverting or gas-hungry fallback blocks order cancellation and griefs keepers.

- Payout: Contest reward
- Severity: medium
- Program: Elfi Protocol
- Credited: ZeroTrust
- Disclosed: 2024-05-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-elfi-protocol-judging/issues/107
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-elfi-protocol%3AM-12
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** OrderFacet.executeOrder / GasProcess.processExecutionFee refund path
**Root cause:** processExecutionFee sends the execution-fee refund to order.account via withdrawEther with all remaining gas, without checking whether the account is a contract or limiting gas.
**Steps:**
1. User places an order with executionFee; keeper later cancels/executes it.
2. executeOrder calls GasProcess.processExecutionFee, which computes refundFee > 0.
3. VaultProcess.withdrawEther(order.account, refundFee) forwards ETH with unlimited gas to the user's contract.
4. User's fallback either reverts (blocking the keeper tx permanently) or burns all gas (griefing keeper).
**How found:** Code review of the shared executeOrder pattern noting refund ETH is sent to user-controlled address with no gas cap or code check.
**Exploitation:** Attacker deploys a contract account whose receive/fallback reverts or consumes all gas, places orders, and waits for keeper cancellation; the keeper's refund transfer reverts or exhausts gas, so cancellation never succeeds and keeper loses gas fees.
**Insight:** Any ETH refund/withdrawal to a user-supplied address in a keeper-driven flow is a griefing vector; check address.code.length and use a capped-gas call or pull-payment pattern.