# Single-use signature front-run griefing

Public permit or approval signatures consumed by anyone before the intended caller, resetting state or blocking flows

_Area: Smart contract access control and control flow. Seen in 4 disclosed reports; latest 2024-09-06. Updated 2026-10-23._

## How it works
A signature (EIP-2612 permit, approval, or relay authorization) is a bearer token: any address can submit it, and it is consumed on first use. The code assumes the intended caller will submit it, but an attacker can submit the same signature first. Because the signature is single-use, the intended use is now impossible, and the state it would have set (an allowance, a nonce, a relay flag) is either set by the attacker or left reset. The broken assumption is that "only the authorized party can trigger this state change."

## Where it shows up
- Permit or approval flows where grant and revoke are separate signatures on the same token [E4](https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-25.md)
- Receiver/executor modules where `msg.sender` is a bridge endpoint, not the user [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-14.md)
- Relay guards keyed on storage that may be empty or wiped (migration, upgrade, spacer mismatch) [E1](https://bugbountylibrary.com/r/sherlock%3A2023-03-optimism%3AH-2.md)
- Deprecated-but-reachable handlers that skip multi-party voting [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-01.md)
- Any allowance the user pre-grants to a module that later acts on their behalf [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-14.md)

## How to review
Check the invariant: every state-changing action must authenticate the original author, not just possession of a public signature. For permits, ask whether a consumed signature can leave the system in a worse state (allowance reset to zero, flow blocked). For receivers, confirm `msg.sender` is checked against the intended user, not merely an allowance. For relay guards, confirm the replay-check storage actually persists across the upgrade and matches the deployed layout [E1](https://bugbountylibrary.com/r/sherlock%3A2023-03-optimism%3AH-2.md). For voting handlers, confirm tally logic is live and reachable [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-01.md).

## Variants seen
- Multi-permit grant+revoke sequence front-run, resetting allowance to zero and DoS-ing cross-chain flows [E4](https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-25.md)
- Receiver module trusts pre-existing allowance, letting anyone redirect collateral or borrowed funds [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-14.md)
- Legacy replay guard passes because migration wiped the mapping, enabling double relay [E1](https://bugbountylibrary.com/r/sherlock%3A2023-03-optimism%3AH-2.md)
- Deprecated NonceVoter bypasses multi-observer tally, one observer sets any nonce [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-01.md)

## Why fixes fail
In-function `approve()` is a no-op when `msg.sender` is the bridge endpoint, so it does not restore authentication [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-14.md). Grant-only permits with try-catch and operator-side renounce are preferred over paired grant/revoke permits [E4](https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-25.md).

## Impact and severity
Double-spend of bridged assets [E1](https://bugbountylibrary.com/r/sherlock%3A2023-03-optimism%3AH-2.md), chain halt via nonce desync [E2](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-01.md), theft of collateral or borrowed funds [E3](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-14.md), and DoS of cross-chain flows [E4](https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-25.md). Severity is high where funds move; griefing-only cases are lower but still block users.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2023-03-optimism%3AH-2.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AH-01.md
- E3: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AH-14.md
- E4: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-25.md