# In execute() the amount routers pay is what user signed, but in _reconcile() the amount routers get is what nomad sends and these two amounts are not necessary equal because of slippage in original domain

Connext execute() deducts routers based on user-signed amount while _reconcile() credits them the smaller bridged amount after slippage, letting attackers drain router liquidity.

- Payout: Audit contest
- Severity: high
- Program: Connext
- Found by: unforgiven
- Disclosed: 2022-10-17
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-06-connext-findings/issues/222
- Library page: https://bugbountylibrary.com/r/c4%3A2022-06-connext%3AH-04
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:chained technique:source-review vuln:accounting-error vuln:business-logic

**Target:** BridgeFacet.sol cross-chain bridge execute/reconcile flow
**Root cause:** transferId and router debit in execute() use _args.amount (user-signed), but the Nomad message and _reconcile() credit routers with bridgedAmt, which differs from _args.amount due to swap slippage or deflationary tokens in xcall().
**Steps:**
1. Call `xcall()` with `_args.amount` large but a token/swap path where `swapToLocalAssetIfNeeded()` yields `bridgedAmt` much smaller than `_args.amount` (slippage or deflationary token).
2. Nomad message carries `bridgedAmt`; `_formatMessage` and transferId derive from bridged amount on origin.
3. On destination, call `execute()` with `_args.amount` set to the larger user-signed amount; `_handleExecuteLiquidity()` deducts `toSwap = _getFastTransferAmount(_args.amount,...)` from router balances.
4. When `_reconcile()` runs, `toDistribute = action.amnt()` (the smaller bridgedAmt) is credited to routers.
5. Router loses the difference; attacker receives full transfer amount.
**How found:** Code-reading comparison of xcall() (which bridges bridgedAmt after swap) versus execute() (which debits _args.amount) and _reconcile() (which credits message amount), spotting the mismatch between user-signed amount and bridged amount.
**Exploitation:** Attacker picks a low-liquidity token with high slippage, bridges with a large signed amount but small bridged output, executes fast-liquidity on destination so routers front the larger amount, then reconciliation credits routers only the smaller bridged amount, draining router liquidity to the attacker.
**Escalation:** Repeatable against low-liquidity tokens to drain router balances cumulatively.
**Insight:** When a bridge hashes an amount into a transferId and separately debits/credits liquidity, verify every code path uses the same canonical amount; slippage-adjusted swap outputs are a classic divergence point between user-signed and actually-bridged values.