# Adding reward tokens to twTap could cause pending cross-chain claim rewards msg to be stuck

Adding a reward token to twTap between cross-chain claim send and receive makes the length check revert, stranding the LayerZero message and burning TAP.

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

**Target:** TapTokenReceiver._claimTwpTapRewardsReceiver cross-chain claim handler
**Root cause:** The receiver asserts claimedAmount_.length-1 equals claimTwTapRewardsMsg_.sendParam.length, but the reward token set on the destination chain can grow after the message was sent, so the counts diverge and the handler reverts.
**Steps:**
1. User on chain A calls `TapOFT.sendPacket` with `MSG_CLAIM_REWARDS` and nonzero `amountToSendLD`.
2. Before LZ delivers, a new reward token is added to `twTAP` on chain B.
3. LZ replays message on chain B, invoking `TapTokenReceiver._claimTwpTapRewardsReceiver`.
4. Length check `(claimedAmount_.length - 1) != claimTwTapRewardsMsg_.sendParam.length` fails, reverting the handler.
5. Message remains stuck in LZ; burned TAP on chain A never minted on chain B.
**How found:** Code-reading of the cross-chain claim flow: noticed the receiver compares claimed token-type count against the send-time sendParam length, and reasoned that the destination reward-token set is mutable between send and receive.
**Insight:** For cross-chain messages, any length/count equality check against destination-side mutable state (token lists, arrays that can grow) is a liveness bug: the sender's snapshot can be stale by delivery time. Look for assertions comparing send-time payload shape to receive-time registry state.