# Composing approval with other messages is subject to DoS

Front-running a permit/approval message in Tapioca's TOFT lzCompose chain causes the whole composed message batch to revert, griefing subsequent messages and burning fees.

- Payout: Contest reward
- Severity: medium
- Program: Tapioca
- Credited: GiuseppeDeLaZara
- Disclosed: 2024-02-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-02-tapioca-judging/issues/67
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AM-12
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:chained technique:race-window vuln:business-logic vuln:dos

**Target:** TOFT cross-chain compose receiver (lzCompose)
**Root cause:** lzCompose processes a chain of composed messages sequentially; a permit/approval message uses a nonce, so if a griefer consumes the permit first, the original permit reverts and the entire lzCompose chain reverts, dropping subsequent messages.
**Steps:**
1. User calls `TOFT::sendPacket` with `_composeMsg` containing first an approval/permit message and then a `MSG_YB_SEND_SGL_BORROW` message.
2. Attacker observes the pending `lzCompose` on the destination chain and front-runs by submitting the same permit/approval directly.
3. Permit nonce is consumed; when the user's `lzCompose` executes `_extExec` for the approval it reverts.
4. The revert aborts the whole `_lzCompose` recursion, so `nextMsg_` (the borrow message) is never processed and fees/gas are lost.
**How found:** Code review of `_lzCompose` recursion and the observation that permits are nonce-based and thus single-use, combined with knowledge of the Trust-Security permit front-run DoS pattern.
**Exploitation:** Griefer monitors destination-chain mempool for composed messages beginning with a permit, front-runs the permit to consume its nonce, forcing the victim's lzCompose to revert and wasting the cross-chain fee and any airdropped value.
**Insight:** When a protocol batches multiple actions into one atomic cross-chain/relayed message, any single-use authorization (permit nonce, one-time signature) inside the batch becomes a griefing lever: an attacker can consume it first and revert the entire batch. Look for composed/batched execution where one step is externally consumable.