# lockQuote() increaseNonce parameters do not work properly

In Symmetrical's lockQuote(), the nonce increment reads quote.partyB before it is set, so it bumps partyBNonces[address(0)] instead of the real Party B nonce.

- Payout: Contest reward
- Severity: medium
- Program: Symmetrical
- Credited: Juntao
- Disclosed: 2023-06-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-symmetrical-judging/issues/123
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-symmetrical%3AM-4
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:signature-replay

**Target:** PartyBFacetImpl.lockQuote() in symmio-core Solidity contracts
**Root cause:** The increaseNonce branch executes `partyBNonces[quote.partyB][quote.partyA] += 1` before `quote.partyB = msg.sender` is assigned, so quote.partyB is still address(0) at increment time.
**Steps:**
1. Read PartyBFacetImpl.lockQuote() and note ordering: nonce increment precedes `quote.partyB = msg.sender`.
2. Call lockQuote(quoteId, upnlSig, true) as Party B on a quote where partyB is unset.
3. Observe partyBNonces[address(0)][partyA] increments while partyBNonces[msg.sender][partyA] stays unchanged.
4. Consequence: the same signature/nonce can be reused to lock multiple quotes of one Party A.
**How found:** Code reading of lockQuote() revealed the nonce increment placed before the partyB assignment, making the indexed key address(0).
**Exploitation:** Party B can lock quotes of only one Party A with a single signature and cannot open all of them; the sole effect is locking the user's quotes, since the intended per-partyB nonce never advances.
**Insight:** When auditing nonce/replay guards, verify the state variable used as the nonce key is already assigned at increment time; ordering bugs silently write to the zero-address slot and defeat replay protection.