# WeVE (FTM) may be lost forever if redemption process is failed

Velodrome's cross-chain WeVE redemption burns tokens on FTM but reverts on Optimism when the hardcoded eligible cap is exceeded, permanently losing user funds.

- Payout: Contest reward
- Severity: medium
- Program: Velodrome Finance
- Credited: Chom
- Disclosed: 2022-08-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-velodrome-findings/issues/90
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-velodrome%3AM-17
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Cross-chain redemption contracts (RedemptionSender/RedemptionReceiver) via LayerZero
**Root cause:** eligibleWEVE is hardcoded at initialization and lzReceive reverts when cumulative redeemedWEVE exceeds it; the revert on the destination chain does not refund the already-burned WeVE on the source chain.
**Steps:**
1. User calls `redeemWEVE` on RedemptionSender (Fantom), burning WeVE and sending a LayerZero message.
2. LayerZero is slow; user assumes failure and calls `redeemWEVE` again, burning more WeVE.
3. First `lzReceive` on RedemptionReceiver (Optimism) succeeds, paying USDC+VELO.
4. Second `lzReceive` hits `require((redeemedWEVE += amountWEVE) <= eligibleWEVE, "cannot redeem more than eligible")` and reverts.
5. No refund path exists; the second batch of WeVE is lost forever.
**How found:** Code review of the redemption flow: noticed eligibleWEVE is immutable/hardcoded and that a destination-chain revert has no refund path back to the source chain, making repeated redemption under LayerZero latency a permanent-loss scenario.
**Insight:** In cross-chain burn-and-mint/redeem designs, any revert on the destination leg must have a compensating refund path on the source leg; check whether caps/limits are hardcoded and whether retries after message latency can double-burn.