Avoid nonce collisions across concurrent swap actions

One account's transaction nonce is a sequence resource. Two workers that independently read the same pending nonce can construct conflicting transactions even when both swap requests are valid.

Own the sequence explicitly

For a backend-controlled signer, serialize nonce allocation per chain and account. Persist the reservation with the transaction attempt before releasing the lock. A process-local counter is insufficient when multiple instances or restarts can access the same account.

The transaction count RPC provides chain state, but reading it is not an atomic reservation across your workers. Reconcile the local ledger with confirmed and pending transactions whenever errors or external activity create uncertainty.

Approval adds a dependency

A swap needing approval should not merely receive the next nonce and assume the approval will succeed. The second transaction can remain blocked behind the first or fail after it. Unless the chosen account architecture supports a documented atomic batch, track the approval receipt and refresh the executable route before proceeding.

Browser wallets typically manage transaction nonces themselves. Do not impose a backend nonce queue on an unrelated user wallet or assume the user has no transactions open in another application. Instead, handle replacements and delayed confirmations through wallet and chain evidence.

Recovery cases

Distinguish nonce too low, replacement underpriced and a gap before the next pending transaction. Each indicates a different sequence problem. Never skip forward blindly to the largest number returned by one source.

Test simultaneous requests, a worker crash after signing, an external transaction and a rejected approval. The invariant is that each submitted transaction has an accountable sequence position and that the application can explain whether it remains pending, was replaced or reached a receipt.