# Wrong precision when adding balance within the `restoreBridgeTransaction` function

restoreBridgeTransaction credits invalidBridgedAmountsPool balance in token native decimals instead of 18-decimal protocol precision, making suspended bridge funds nearly unwithdrawable.

- Payout: Contest reward
- Severity: high
- Program: Symmetrical Update 2
- Credited: 0xAadi
- Disclosed: 2024-06-10
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-symmetrical-update-2-judging/issues/5
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-symmetrical-update-2%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:precision-loss

**Target:** BridgeFacetImpl.restoreBridgeTransaction / AccountFacetImpl.withdraw
**Root cause:** AccountStorage.balances is denominated in 18 decimals, but restoreBridgeTransaction adds bridgeTransaction.amount - validAmount in the token's native decimals (e.g. 6 for USDC) without scaling.
**Steps:**
1. Bridge 10000 USDC (10000e6); bridgeTransaction.amount = 10000e6.
2. Protocol suspends the transaction (status SUSPENDED).
3. Call restoreBridgeTransaction(id, 5000e6); line 90 credits invalidBridgedAmountsPool with 5000e6 instead of 5000e18.
4. Withdraw from pool: amountWith18Decimals = (amount*1e18)/1e6, so balance 5000e6 caps withdrawal at ~0.000000000000005 USDC.
**How found:** Code review comparing the precision of AccountStorage.balances (18 decimals) against bridgeTransaction.amount (token native decimals) and tracing the withdraw conversion formula to confirm the mismatch.
**Insight:** When a protocol stores balances in a normalized 18-decimal unit, audit every write to that mapping for missing scaling from token native decimals—especially in admin/recovery paths like restore/suspend handlers that bypass the normal deposit conversion.