# Failed settlement marked success

Failure paths that record success or advance stage instead of reverting, letting attackers force or fake settlement

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2024-09-06. Updated 2026-11-01._

## How it works
A settlement or transfer step can fail without the transaction reverting. The code catches the failure, or a permissionless retry marks a terminal status, and the protocol records success or advances to the next stage. The broken assumption is that a failed external call means the operation is over and harmless. In practice an attacker can deliberately cause the failure, or call the retry themselves, and the protocol then treats an unsettled state as settled.

## Where it shows up
- try/catch around an external transfer or callback that returns false or continues instead of reverting [E1](https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-03.md)
- A settlement status set to Success/terminal without confirming the underlying transfer happened [E3](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-03.md)
- Retry or replay functions callable by anyone, with no check that the retry actually did work [E3](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-03.md)
- Revert handlers whose own failure is terminal (Aborted) with no retry or manual redemption [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-08.md)
- Admin-settable caps (e.g. maxSupply) that can make the revert handler itself fail [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-08.md)
- Auction or listing stages that advance when a prior stage is cancelled rather than completed [E1](https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-03.md)

## How to review
Trace every path that can end a settlement. The invariant: a settlement may only be marked successful or advance a stage if the corresponding transfer actually succeeded; any failure must revert or leave a retryable, non-terminal state. Check that permissionless retry/replay functions cannot flip status to terminal without performing the real work, and that the legitimate owner's redeem path still works afterward [E3](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-03.md). For revert handlers, confirm the failure of the handler is not terminal and funds remain recoverable [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-08.md). For try/catch, ask whether an attacker can trigger the caught failure on purpose [E1](https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-03.md).

## Variants seen
- Caught transfer failure treated as benign false, advancing to a cheaper stage [E1](https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-03.md)
- Permissionless zero-gas retry marks settlement Success, blocking owner redeem [E3](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-03.md)
- Revert handler reverts, CCTX aborted, burned funds never reminted [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-08.md)

## Why fixes fail
E2 shows a terminal Aborted state with no retry or redemption path; a cap that makes the handler fail leaves funds locked permanently.

## Impact and severity
NFT theft via stage bypass [E1](https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-03.md), permanent lock of burned cross-chain funds [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-08.md), and DoS of owner redemption locking assets [E3](https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-03.md). Severity rises when the failure is cheap to trigger and the resulting state is terminal.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2022-09-party%3AH-03.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-08.md
- E3: https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AM-03.md