# Hardcoded destination gas strands cross-chain messages

Destination gas hardcoded or caller-controlled without floor; receiver reverts and message is unredeemable

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

## How it works
A cross-chain send path must forward enough gas for the destination receiver to execute. When the sender hardcodes that gas (or lets a caller set it with no safe floor), the message still gets delivered but the receiver call reverts out-of-gas. If the bridge has no replay, the payload and any state it was meant to settle are stranded. The broken assumption is that delivery equals execution: the message arrives, but the receiver cannot finish.

## Where it shows up
- A literal gas value (e.g. `0`, `90000`) passed into an outbound message constructor instead of a per-chain config or the user's field.
- A user-supplied gas field forwarded with only the bridge's internal minimum as a bound.
- Receiver callbacks (`sgReceive`, `onReceive`, `lzReceive`) that do work beyond a cheap ack.
- Bridges with no replay/retry path for failed deliveries.
- Cached-swap or pending-message maps that only clear on successful receive.

## How to review
Trace the gas value from the emitted event/input struct to the outbound message constructor and confirm it matches the user's field or a per-chain configured value, not a literal. For each receiver, estimate whether the forwarded gas covers its worst-case path. The invariant: every delivered message either executes successfully or can be replayed/refunded; no caller-controlled gas field can make a third party's message permanently unredeemable. Check whether a failed receive leaves state (cached swaps, incentives) that only governance can recover.

## Variants seen
- Hardcoded `dstGasForCall=0` in Stargate lzTxObj, so `sgReceive` reverts and cached swaps are griefed into long-term DoS [E1](https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AM-16.md).
- Caller-supplied `gasLimitMessage` with no floor beyond the AMB minimum; failed L2 message is lost with no replay [E2](https://bugbountylibrary.com/r/c4%3A2024-05-olas%3AM-10.md).
- Outbound zEVM message hardcodes 90000, ignoring `destinationGasLimit`; cctx aborts without refunding sender [E3](https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-14.md).

## Impact and severity
Medium in all three: messages stuck, incentives irredeemable, swaps DoS'd, sender not refunded. Worse when the receiver does real work, the bridge lacks replay, and recovery needs governance.

## Why fixes fail
E1 notes `sgReceive` also fails to validate chainId/srcAddress/token, so fixing gas alone leaves the receiver open to unauthorized triggers.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2024-02-tapioca%3AM-16.md
- E2: https://bugbountylibrary.com/r/c4%3A2024-05-olas%3AM-10.md
- E3: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-14.md