# Same contract multi permits fundamentally cannot be solved via the chosen standards

Permit signatures for USDO/TOFT approvals are public and front-runnable; an attacker can burn multi-permit sequences, resetting allowances to zero and DoS-ing cross-chain flows.

- Payout: Contest reward
- Severity: medium
- Program: Tapioca DAO
- Credited: GalloDaSballo
- Disclosed: 2024-05-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/81
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-25
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window vuln:dos vuln:signature-replay

**Target:** USDO/TOFT permit-based approval flows (cross-chain)
**Root cause:** Permit signatures are broadcastable by anyone and are single-use; when multiple permits (grant + revoke) target the same token, an attacker can submit them first, consuming the signatures and resetting allowance to 0.
**Steps:**
1. Monitor mempool for a sequence of permit signatures targeting the same token (e.g. add exact allowance then revoke).
2. Front-run by broadcasting all of the permit signatures before the victim's transaction.
3. The revoke permit executes, resetting allowance to 0.
4. Victim's xChain transaction reverts because the approval is gone.
**How found:** Follow-up to a Spearbit finding on permit-based DoS griefing; reasoned that since permits are public signatures usable by any msg.sender, any multi-permit sequence (grant + revoke) is front-runnable.
**Exploitation:** Attacker watches mempool, extracts permit signatures, and submits them ahead of the victim's transaction, burning the approvals and forcing the subsequent cross-chain call to revert.
**Insight:** When a protocol uses EIP-2612 permits for both granting and revoking allowances, the revoke permit is a griefing vector: prefer grant-only permits with try-catch and an operator-side renounceAllowance to enforce 0->X->0 without exposing a revoke signature.