# Suspended bridge transactions cannot be restored

restoreBridgeTransaction always reverts because invalidBridgedAmountsPool is never settable and stays zero, permanently locking suspended bridge assets.

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

**Target:** BridgeFacetImpl.restoreBridgeTransaction in protocol-core bridge facet
**Root cause:** restoreBridgeTransaction requires bridgeLayout.invalidBridgedAmountsPool != address(0), but no setter or initializer ever assigns this storage field, so it is always zero and the require always reverts.
**Steps:**
1. Observe restoreBridgeTransaction at BridgeFacetImpl.sol:83-93 requires invalidBridgedAmountsPool != address(0) at line 88.
2. Search codebase for any assignment to bridgeLayout.invalidBridgedAmountsPool; none exists (no setter, no initializer).
3. Trigger a bridge transaction that becomes SUSPENDED, then call the restore path; the require at line 88 reverts with 'BridgeFacet: Zero address'.
4. Assets remain stuck in the suspended transaction; bridge providers cannot reclaim funds.
**How found:** Code reading of the restore function's require against the storage layout; noticed the guard references a field with no write path anywhere in the codebase.
**Insight:** When a function guards on a config/storage field being non-zero, grep for every write to that field (setters, initializers, upgrade scripts); a guard on a never-initialized field is a permanent DoS on that code path.