# Unprotected slippage tolerance can lead to user/protocol loss of funds

Anyone can front-run rebalanceXChain() and set 100% slippage tolerance, causing vault swaps to execute at manipulated prices and lose funds.

- Payout: Contest reward
- Severity: medium
- Program: Derby
- Credited: Ch_301
- Disclosed: 2022-10-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-01-derby-judging/issues/54
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-derby%3AM-41
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** MainVault/XProvider cross-chain rebalance swap
**Root cause:** rebalanceXChain() is callable by any external user and passes a caller-supplied _slippage tolerance into xTransfer without bounds or access control, so an attacker controls the swap slippage.
**Steps:**
1. Observe a pending rebalanceXChain() tx in mempool
2. Front-run it calling rebalanceXChain() with _slippage set to 100%
3. When homechain != controllerChain, xTransfer() is invoked with the attacker's _slippage
4. XCall executes rebalance and performs XChain swaps at the inflated tolerance
5. Swaps fill at far worse prices than the 30 (0.03%) standard tolerance, draining value
**How found:** Reviewers noticed rebalanceXChain() lacked onlyDao/onlyKeeper access control and that the caller-supplied _slippage flowed unchecked into xTransfer, then reasoned a mempool front-run could set tolerance to 100%.
**Exploitation:** Attacker front-runs the rebalance transaction and supplies a 100% slippage tolerance; the resulting Connext XChain swaps execute at manipulated prices, causing user/protocol fund loss.
**Insight:** When a rebalance/swap entrypoint takes a slippage parameter from the caller, check whether the function is permissioned; if not, the parameter is attacker-controlled and front-runnable.