# Permanent loss of tokens if swap data gets outdated

StargateBridgeAdapter.sgReceive swap failure leaves bridged tokens stuck in the adapter, retryable only with the same stale swap data, causing permanent loss.

- Payout: Contest reward
- Severity: medium
- Program: Decent
- Credited: windhustler
- Disclosed: 2024-03-22
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-decent-findings/issues/665
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-decent%3AM-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm technique:source-review vuln:business-logic

**Target:** StargateBridgeAdapter.sgReceive / UTB.receiveFromBridge cross-chain swap
**Root cause:** sgReceive failure does not revert the Stargate delivery; tokens land in the adapter while the cached payload can only be retried with the same now-outdated swap data (e.g. stale minAmountOut).
**Steps:**
1. User calls `UTB:bridgeAndExecute()` which routes through `StargateBridgeAdapter:bridge()` passing swapData to remote chain.
2. StargateComposer transfers tokens to StargateBridgeAdapter on destination chain and calls `sgReceive()`.
3. `sgReceive` calls `UTB:receiveFromBridge` which attempts the swap.
4. Swap reverts (e.g. outdated minimum amount out); payload cached in StargateComposer, tokens remain in adapter.
5. Retry via `clearCachedSwap` uses same payload, so swap keeps failing and tokens are stuck.
**How found:** Code-reading of the Stargate composability flow: noticed sgReceive failure does not revert the whole delivery and that cached payloads can only be retried with identical swap data, making stale slippage unrecoverable.
**Exploitation:** Not attacker-driven; user-initiated bridge with swap data that becomes stale (slippage/minAmountOut) after cross-chain delay causes swap revert, leaving tokens stranded in the adapter with no rescue path.
**Insight:** In cross-chain composability flows, check whether a failed destination-side callback reverts the bridge delivery or merely caches the payload; if retries reuse the same calldata, any time-sensitive parameter (slippage, deadlines) becomes a permanent-loss vector.