# Push payment revert blocks shared flow

A payout to a recipient who can force it to revert halts a queue, settlement, or consensus path

_Area: Smart contract access control and control flow. Seen in 55 disclosed reports; one confirmed bounty: $5,000; latest 2026-05-18. Updated 2026-10-23._

## How it works
A contract pays out by pushing funds to a recipient (native transfer, ERC20 transfer, or a callback invoked on transfer). The recipient can make that push revert: a contract with no payable fallback, a token blacklist, a token rejecting self/proxy/zero addresses, or a callback target that is not a live contract. When the payout sits inside a loop, settlement, or consensus-critical path, the revert aborts the whole operation, not just that one payment. Two failure modes break the flow: (1) a recipient-controlled revert, where the payee chooses to reject; (2) a forced-balance revert, where a third party donates funds so an unconditional refund to a non-receiving party fails. Both break the same assumption: that flow progress (cursor, counter, state transition) is decoupled from any single transfer succeeding.

## Where it shows up
- A queue or loop that advances a head/index pointer only after a successful external transfer.
- Permissionless functions that record `msg.sender` as a future payment recipient.
- Refunds or payouts to a stored, mutable owner/receiver field.
- User-registered callbacks invoked on every transfer, with no check the target is a live contract.
- ERC1155/ERC721 safe-mint to user-supplied receivers inside a batch loop.
- Push-payments with `require(success)` to a counterparty inside a state transition.
- Tokens with transfer guards (self/proxy/blacklist/zero-address) used in settlement paths.
- Unconditional refunds of the contract's own balance to a caller or receiver.

## How to review
Check the invariant: no single recipient or third party can make a shared flow revert. Does the cursor/counter advance independently of the transfer succeeding? Is the payout pull-based or wrapped in try/catch with a claimable fallback? Is the recipient validated (non-zero, live contract, not blacklisted) before storage? For callbacks, confirm at registration that the target is a live contract (E1). For consensus paths (BeginBlocker, staking/distribution), can any user-registered value force a transfer to fail? For refunds, can a donation turn a conditional refund into a revert? Triage: permanent lock (cursor coupled to transfer, no alternate path) versus temporary delay (retryable).

## Variants seen
- Callback hook pointed at a non-contract bricks all transfers of a denom, blocking reward withdrawals and enabling halt via slashing [E1](https://bugbountylibrary.com/r/c4%3A2024-11-mantra-chain%3AH-01.md).
- Permissionless batch sender is a contract rejecting ETH, so fee push reverts and blocks all result submissions [E2](https://bugbountylibrary.com/r/sherlock%3A2024-12-seda-protocol%3AH-6.md).
- Creator sets a reverting referral-fee receiver so sells revert while buys succeed, trapping holders [E3](https://bugbountylibrary.com/r/c4%3A2024-01-curves%3AH-03.md).
- Owner set to address(0) makes settlement refund revert, locking bidder funds [E4](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-04.md).
- Third-party ETH donation forces a refund to a non-payable proxy, reverting the swap [E5](https://bugbountylibrary.com/r/c4%3A2023-03-polynomial%3AH-11.md).
- Stray dust makes an unconditional native refund to a non-receiving receiver revert, DoSing order fill [E6](https://bugbountylibrary.com/r/c4%3A2026-01-olas%3AM-07.md).
- Bidder rejecting ETH refund reverts commitment processing, locking provider stake and payout [E7](https://bugbountylibrary.com/r/cantina%3Agenius_jul2025%3A3.2.2.md).

## Impact and severity
High: permanent denial of service, trapped user funds, frozen queues and settlements, and in consensus contexts a chain halt [E1](https://bugbountylibrary.com/r/c4%3A2024-11-mantra-chain%3AH-01.md). Severity rises when the cursor cannot advance by any other path [E4](https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-04.md) and when funds are locked rather than delayed [E7](https://bugbountylibrary.com/r/cantina%3Agenius_jul2025%3A3.2.2.md). Forced-balance reverts [E5](https://bugbountylibrary.com/r/c4%3A2023-03-polynomial%3AH-11.md)[E6](https://bugbountylibrary.com/r/c4%3A2026-01-olas%3AM-07.md) are lower only when the attacker must spend funds and the flow is retryable.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-11-mantra-chain%3AH-01.md
- E2: https://bugbountylibrary.com/r/sherlock%3A2024-12-seda-protocol%3AH-6.md
- E3: https://bugbountylibrary.com/r/c4%3A2024-01-curves%3AH-03.md
- E4: https://bugbountylibrary.com/r/c4%3A2023-04-frankencoin%3AH-04.md
- E5: https://bugbountylibrary.com/r/c4%3A2023-03-polynomial%3AH-11.md
- E6: https://bugbountylibrary.com/r/c4%3A2026-01-olas%3AM-07.md
- E7: https://bugbountylibrary.com/r/cantina%3Agenius_jul2025%3A3.2.2.md
- E8: https://bugbountylibrary.com/r/cantina%3Aprimev_oct2024%3A3.1.8.md