# Transaction can fail due to batchId collision

SmartAccount's execTransaction accepts batchId 0, which is reserved for EntryPoint nonces, letting a call increment the shared nonce and cause subsequent UserOps to revert.

- Payout: Contest reward
- Severity: medium
- Program: Biconomy
- Credited: 0xdeadbeef0x
- Disclosed: 2023-03-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-biconomy-findings/issues/246
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-biconomy%3AM-08
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** SmartAccount smart contract nonce/batchId mechanism
**Root cause:** execTransaction lacks a check preventing batchId 0, which is hardcoded as the EntryPoint nonce space; both paths increment nonces[0], so a direct execTransaction call desynchronizes the EntryPoint nonce.
**Steps:**
1. Observe _validateAndUpdateNonce uses `nonces[0]++` for all UserOps via EntryPoint.
2. Observe execTransaction does `nonces[batchId]++` with no restriction on batchId.
3. Call `execTransaction(_tx, 0, refundInfo, signatures)` directly on the wallet.
4. nonces[0] is incremented, so the next EntryPoint UserOp with the expected nonce reverts with 'account: invalid nonce'.
**How found:** Code reading of the two transaction entry paths (EntryPoint vs execTransaction) and noticing both mutate the same nonces mapping with batchId 0 reserved only by convention, not enforced.
**Exploitation:** A caller (e.g. owner or anyone able to submit a valid execTransaction) submits execTransaction with batchId=0, bumping the EntryPoint nonce space and causing pending/future UserOps to fail validation.
**Insight:** When a contract reserves a nonce/ID namespace for one caller (EntryPoint), check every other entry point that writes the same mapping for an explicit guard—convention comments are not enforcement.