Skip to main content
In some cases, you might want to submit multiple transactions that will be processed in sequence by the network. This is useful for scenarios like batch operations or when you need to ensure transactions are processed in a specific order. Here’s how to submit multiple transactions with sequential nonces.
The sequential pattern below applies to EOA wallets. If your client uses Account Abstraction, skip to Account Abstraction wallets: the bundler rejects a second user operation with the next sequential nonce, so parallel sends need 2D nonces instead.

​
Understanding Nonces

Before submitting concurrent transactions, it’s important to understand nonces:
  • Every Ethereum transaction requires a nonce
  • Nonces must be used in sequence (0, 1, 2, etc.)
  • The network will process transactions in nonce order
  • Multiple pending transactions can exist in the mempool as long as they have sequential nonces
  • Submitting multiple transactions with the same nonce will result in the transaction with the highest gas overriding others

​
Steps

  1. First, retrieve your current nonce from the network. This ensures you start with the correct sequence number.
  1. Format your transaction objects with incrementing nonces. Here’s an example transaction format:
  1. Submit multiple transactions using the Portal API. Each request should use the /v1/sign endpoint with eth_sendTransaction method:
  1. Repeat the request for each transaction, incrementing the nonce each time.

​
Important Notes

  • All transactions will enter the mempool but may not be processed immediately
  • Transactions will be processed in nonce order, regardless of submission time
  • If a transaction with a lower nonce fails, subsequent transactions will remain pending
  • Consider adding delays between submissions to prevent rate limiting
  • Make sure your wallet has sufficient funds to cover all transactions
If any transaction in the sequence fails due to insufficient funds or other errors, subsequent transactions with higher nonces will remain pending until the issue is resolved.

​
EVM Account Abstraction wallets

EVM Account Abstraction clients send ERC-4337 user operations instead of transactions, and user operation nonces work differently from the single counter an EOA has. Think of the wallet as having many lanes, each with its own counter:
  • The nonce is a 256-bit value made of a 192-bit key (the high bits) and a 64-bit sequence (the low bits): nonce = (key << 64) | sequence. The key names a lane, and the sequence is that lane’s counter.
  • Every lane starts at 0 and counts up by one each time a user operation on it lands. A lane that has never been used still has its counter at 0.
  • Sending without a nonce uses lane 0. Two requests sent at the same time both read lane 0’s current counter, so the second one fails with AA25 invalid account nonce: Another UserOperation with same sender and nonce is already being processed.
  • Sending sequence + 1 on the same lane before the previous user operation lands does not help either. The bundler checks the nonce against the current on-chain counter, so it fails with AA25 invalid account nonce until the previous one is mined.
User operations on different lanes never share a counter, so they never collide. To send several in parallel, open a fresh lane per request: pick a key that has not been used for this wallet and send it with sequence 0. A random key per request is the simplest way to guarantee it is unused. A key derived from your own identifier for the operation (for example a payout id) also works, and has the side effect that resending the same operation later fails with AA25, because that lane’s counter has already moved past 0. The random hex below is not a nonce in the EOA sense; it picks the lane. The 16 zero bytes that follow it are the lane’s counter at 0, which is why the value that lands on-chain ends in zeros.
Then pass nonce in the eth_sendTransaction params. Every parallel request needs its own lane, so the value below is the one computed above for this request, not a constant to reuse:
Use this pattern only when the order of execution does not matter. Separate keys remove the nonce dependency between the user operations, but the bundler may include them in any order, so operations that depend on each other’s state (for example an approval followed by a transfer) still need to be sent one after the other.
The 48-bit key in the example is a convenient size, not a limit. Any key up to the full 192 bits is accepted and reaches the chain unchanged. Two random 48-bit keys on the same wallet collide about once in 16 million sends, and a collision costs one AA25 on one request; use more bits if you want that lower.