Nonce Lanes: Concurrent Submission from One Account

One funded account on Sei EVM has one sequential nonce. That suits a wallet, where each action follows the last. It does not suit a stream of independent work: one transaction that never lands blocks every transaction signed after it. The usual fix is a fleet of hot wallets, which multiplies balances, approvals, and keys. sei-nonce-lanes is a reference implementation that removes the queue instead. One funded externally owned account (EOA) keeps its address, balance, and approvals while holding many mutually independent operations in flight at the same time. The pattern applies whenever one funded address needs to do many things that do not depend on each other: market making and order flow, liquidation and keeper bots, oracle updates, payout and claim batching, or game and backend transactions.

The repository is a runnable engineering demonstration, not a production service. It uses a mock venue, plaintext development keys in .env, an in-process queue, and console output. Read Before you adapt this before pointing it at real funds.

This page is about submission concurrency. If you want a hosted bundler, a paymaster, and gas sponsorship for consumer wallets, start with Pimlico or Thirdweb EIP-7702 instead. Nonce lanes solve the opposite problem: throughput from one address you control, with no third party in the submission path.

Why one account is one queue

An EVM account’s transaction nonces are strictly sequential. If nonce n has not executed, nonce n + 1 cannot execute first. Two failures that look similar behave differently:

Event	Blocks later nonces?
The transaction lands and its call reverts	No. The transaction consumed its nonce.
The transaction never lands	Yes. Every later nonce waits until the gap is filled or replaced.

The second case is the submission bottleneck. It covers transactions that are dropped, underpriced, rejected at admission, lost before broadcast, or stranded after a process crash. Two properties of Sei make this sharper than on Ethereum:

Strict nonce admission. Under Giga, the Autobahn producer mempool admits EVM transactions in per-sender nonce order and rejects a gap with a bad nonce error instead of holding it for later. See Giga mode behavior. What you observe through an RPC endpoint can differ, because the node in front of the producer may hold a gapped transaction and release it later, or accept it and then drop it. The repository’s npm run baseline command probes the RPC path you configure; in one session it returned two different verdicts for two Atlantic-2 endpoints.
No dependable pending view. Sei does not expose Ethereum-style pending state, and Finality and block tags tells you not to rely on a pending nonce differing from the confirmed nonce. txpool_content is also truncated and collapses the pending/queued distinction. Even where a node answers a pending-nonce query, the value cannot be used to rebuild an in-flight queue.

Do not design around a pending nonce on Sei. eth_getTransactionCount(address, "pending") is documented as returning EvmNextPendingNonce from the mempool, so it is not an alias for "latest". The finality guidance still marks the pending view as unreliable, and the value varies by node and by whether the node runs Giga. The design below does not depend on the answer: its hot path reads no nonces.

Splitting work across hot wallets raises throughput, but every wallet is another balance to rebalance, another set of approvals to maintain, and another key that can move funds.

How it works

The design combines four mechanisms. Each solves one part of the problem; none is sufficient alone.

Mechanism	What it contributes
ERC-4337 v0.8 two-dimensional nonces	Independent nonce lanes for one account
EIP-7702 delegation	The existing funded address keeps its balance and approvals
An in-process bundling queue	No per-sender pending cap and no third-party bundler
Gas-only relayers with a write-ahead journal	Sequential transactions still exist, but the accounts that send them hold only gas

ERC-4337 nonce lanes

EntryPoint v0.8 stores a UserOperation nonce as a 192-bit key plus a 64-bit sequence:

nonce = (uint192 key << 64) | uint64 sequence

The EntryPoint keeps one sequence counter for each key. The specification calls this a two-dimensional nonce; the repository calls a key a lane. Four rules follow from that layout:

Operations on different lanes have no ordering relationship.
Operations on the same lane stay strictly sequential, so the implementation allows at most one in-flight operation per lane.
An operation that executes and reverts still consumes its lane sequence.
An operation that never reaches a successful handleOps transaction consumes nothing.

LaneAccount rejects lane 0. Most SDKs pick key 0 when you do not pass one, and work that lands entirely on key 0 is a single queue again. Rejecting it converts a silent fallback into an explicit validation failure. ADMIN_LANE (the maximum uint192) is reserved for integrations that need one explicitly ordered lane for administrative calls.

EIP-7702 keeps the funded address

An EIP-7702 authorization writes a delegation designator into the EOA’s code slot:

0xef0100 || <LaneAccount implementation address>

The address does not change. Its native balance, token balances, protocol state, and approvals stay attached to the same account. When the EntryPoint calls the account, the EVM runs LaneAccount’s code in the EOA’s context, so LaneAccount.execute reaches the target with the funded EOA as msg.sender. LaneAccount inherits the reference Simple7702Account from the eth-infinitism account-abstraction repository and adds a single policy check:

contract LaneAccount is Simple7702Account {
    uint192 public constant ADMIN_LANE = type(uint192).max;

    error LaneZeroReserved();

    function _validateNonce(uint256 nonce) internal pure override {
        if (nonce >> 64 == 0) revert LaneZeroReserved();
    }
}

Installing the delegation takes one type-4 transaction. Sei requires a non-empty authorization list on type-4 transactions; see Transaction types. The nonce cost depends on who sends that transaction. The EVM applies the authorization list after incrementing the sender’s nonce for the transaction itself, so when the authority is also the sender, the authorization must be signed over nonce + 1 and applying it increments the account a second time. A self-sponsored delegation advances the account’s nonce by two; npm run delegate takes this path. A delegation sponsored by a different sender advances the funded account by one, the increment the authorization itself performs. In both cases, once the designator is in place, the submission path signs UserOperations only and the funded account’s EVM nonce stops moving.

EIP-7702 alone does not create independent nonces; it preserves the account. ERC-4337 supplies the nonce model. The design needs both.

Gas-only relayers carry what is left of the queue

UserOperations are not transactions. Something still has to wrap them in EntryPoint.handleOps transactions and pay for them. The repository uses a pool of gas-only relayers fed by an in-process bundling queue. The sequential constraint moves rather than disappears. Each relayer has one sequential EVM nonce and keeps one outer transaction in flight at a time. The custody boundary is what changes: relayers hold native SEI for gas and nothing else. A compromised relayer key can lose its own gas balance or rebroadcast operations the funded account already signed. It cannot create a new operation, because every UserOperation carries an EIP-712 signature from the funded account over the EntryPoint’s PackedUserOperation digest. The bundling queue matters for a different reason. It is an in-process queue, not a mempool: nothing is gossiped, nothing arrives from another party, and it is gone when the process exits. It therefore never enters the canonical ERC-4337 alt-mempool, and the ERC-7562 validation rules that govern that mempool, including SAME_SENDER_MEMPOOL_COUNT = 4 for an unstaked sender, do not apply to it. A cap of four pending operations per sender is sized for wallets, not for a submission pipeline. Those rules exist so competing bundlers can safely pack operations from unrelated senders into one bundle. Here every operation comes from one account you control, so that threat does not arise. The EntryPoint still enforces everything that protects funds: the signature, per-lane nonce uniqueness, and prefund solvency.

One bundle, start to finish

Each relayer runs one asynchronous worker. The worker takes a bundle of up to MAX_OPS_PER_BUNDLE operations (never two from the same lane), and then works through a fixed sequence. Two rules provide most of the safety:

Write-ahead ordering. The signed outer transaction is written to the journal before it is broadcast. Each journal snapshot is fsynced before it is renamed into place, and the directory is fsynced after it, so a written record survives a kernel panic or host loss, not only a process crash. On restart, the exact raw bytes are rebroadcast first, so a crash between signing and sending cannot lose or duplicate work. The journal is still one file on one disk, not a replicated database.
Same-nonce replacement. If no receipt arrives within BUNDLE_RECEIPT_TIMEOUT_MS, the worker checks earlier attempts for a receipt, bumps fees by REPLACEMENT_FEE_BUMP_PERCENT, and signs a replacement at the same relayer nonce. It never sends nonce n + 1 while a transaction at n might still land, which is the gap this design exists to avoid.

The receipt wait polls every RECEIPT_POLLING_INTERVAL_MS, 250 ms by default. Sei produces blocks in well under a second. With viem’s 4-second default, most of the timeout passes idle between polls, and a bundle that has already landed can be reported as timed out, which triggers an unnecessary fee-bumped replacement. Two further guards cover the simulation and the journal. The eth_estimateGas call passes the relayer’s address string as account, not the viem Account object. Given a local account object, viem prepares a full transaction request before estimating, which adds a chain ID read, a fee lookup, and an eth_getTransactionCount(address, "pending") call; passing the address skips all three, including the pending-nonce read this hot path is built to avoid. A file lock keeps a second process off the same account. The lock identifies its holder by inode rather than by the existence of a file, and the process re-checks that it still holds the lock immediately before it signs and before every journal write, so a process that lost a lock race stops instead of signing. Before any new work is created, a restarted process reconciles every incomplete journal entry against the EntryPoint. If the chain sequence is ahead of the journal, the operation was consumed. If they match, the lane is reserved and the operation is recovered or requeued. If the chain is behind the journal, the state is inconsistent and the process stops rather than guessing.

What fails alone and what fails together

The EntryPoint treats an account execution failure as a per-operation result: it emits a failed UserOperationEvent, charges gas, advances that lane, and continues with the next operation. A validation failure (bad signature, stale sequence, insufficient prefund) is different: it reverts the whole handleOps transaction and nothing in it is consumed.

Situation	Lane sequence	Other lanes in the bundle	Recovery
Operation executes successfully	Consumed	Continue	None
Operation execution reverts	Consumed	Continue	Optionally retry the intent on the lane’s next sequence
Operation validation fails	Not consumed	Entire `handleOps` reverts	Fix the cause and resubmit
Signed operation never reached a mined bundle	Not consumed	Independent lanes stay valid	The journal requeues it
Outer transaction times out or is evicted	Unknown until reconciled	Bundle stays intact	Rebroadcast and fee-bump at the same relayer nonce
Outer transaction mines and reverts	Not consumed	Nothing in that bundle executes	Relayer nonce is consumed; operations can be requeued
Process exits after journaling	Determined at restart	No new work starts first	Reconcile receipts, lane sequences, and the relayer nonce

Every bundle is simulated with eth_estimateGas before broadcast, so validation failures are normally caught before any gas is spent. MAX_OPS_PER_BUNDLE sets the size of the shared validation domain; keep it small when isolation matters more than amortized cost.

Why this is hard to replicate

Faster hardware and better RPC routing help every submission strategy. The difference here is structural: one funded address holds many independent operations in flight while keeping the custody surface of a single wallet. The relevant comparison is a fleet of hot wallets, which is what most teams run. A fleet can match the width. It cannot do so from one balance, one approval set, and one key. The baseline is not one transaction at a time. A single address can sign and broadcast nonces n, n+1, n+2, and onward and have all of them unresolved, and the producer mempool admits them as long as they arrive in order. The constraint is ordering: the outstanding transactions form one queue, and one that never lands strands every later nonce behind it.

	One hot wallet	Fleet of N hot wallets	Public ERC-4337 bundler	Nonce lanes
Submissions signed and unresolved at once	Many	Many per wallet	At most 4 per unstaked sender	`LANE_POOL_SIZE` (32 by default, 4096 maximum)
Outer transactions broadcast at once	Many	Many per wallet	Set by the bundler’s policy	`RELAYER_COUNT`
Are those submissions independent?	No: one ordered queue	Only across wallets, ordered within each	Yes	Yes: one sequence per lane
Balances and approvals to maintain	One address	N addresses, approved N times	One address	One address
Keys that can move funds	1	N	1	1; relayers hold gas only
Recovering the in-flight set after a crash	Re-derive it from the chain	Re-derive it per wallet	Handled by the bundler	Durable journal and deterministic reconciliation
Failure blast radius	Everything behind the gap	Everything behind the gap, per wallet	One operation	One lane for execution, one bundle for validation

Read the first two rows together. LANE_POOL_SIZE caps how many operations can be signed and unresolved at once; RELAYER_COUNT caps how many outer transactions are broadcast at once. Lanes provide a large pool of independent intents rather than a large number of simultaneous transactions. The approximate per-block submission width is RELAYER_COUNT × MAX_OPS_PER_BUNDLE.

Measured on Atlantic-2 against the same venue call, one address with sequential nonces landed 1 operation per second sending serially and 7 per second pipelining one request at a time, and reached 51 per second only by sending all 1,024 transactions in one JSON-RPC batch. A fleet of 8 hot wallets also landed 51 per second. Nonce lanes landed 60 to 64 per second from one address whose EVM nonce never moved, against a block-gas ceiling of about 73 for that call shape. The method, the run shapes, and the caveats are in Benchmarks. Six properties of the design produce those rows:

Capital, approvals, and protocol state stay on one address. Width comes from lanes, not from splitting funds. A new lane costs nothing to open and is valid at sequence 0 immediately.
The only key that can create a valid operation is the funded account’s. Relayer keys can be rotated, replaced, or lost at a cost bounded by their gas balances.
After the one-time delegation, the funded account’s EVM nonce does not move while submitting. Nothing an RPC drops or a producer rejects can strand the account.
The in-process bundling queue removes the ERC-7562 SAME_SENDER_MEMPOOL_COUNT limit and the dependency on a third-party bundler’s inclusion policy, while every EntryPoint check that protects funds still runs.
Signed operations and signed outer transactions are journaled and fsynced before broadcast, replacement reuses the relayer nonce, and restart reconciliation is deterministic: it refuses to create new work when the recorded state is ambiguous.
The signing path performs no nonce reads, so an unreliable pending view costs nothing. Fast blocks and instant finality keep each relayer’s receipt wait short, which is what makes RELAYER_COUNT × MAX_OPS_PER_BUNDLE a usable per-block width.

Submission concurrency is not execution parallelism. Independent lanes remove ordering between submissions. They do not make conflicting storage writes execute in parallel. A contract that funnels everything through one hot storage slot still serializes on that slot. See Optimizing for parallelization and the parallelization engine.

Block time and gas limits differ between today’s Twin Turbo Consensus and Sei Giga. Size a relayer pool against the network you submit to, and measure rather than assume.

Tutorial: run the reference implementation

The walkthrough below deploys the demo contracts, delegates a throwaway account, funds a relayer pool, and submits 24 operations across 32 lanes. One order is deliberately given an unfillable limit price so you can watch a revert land without disturbing its neighbors.

Prerequisites

Git with submodule support
Foundry with forge, anvil, and cast
Node.js 22 or newer, and npm
For the Atlantic-2 path: a fresh throwaway key funded from the Sei faucet

Clone and verify

Clone with submodules so the pinned account-abstraction, OpenZeppelin, and forge-std dependencies are checked out:

git clone --recurse-submodules https://github.com/sei-protocol/sei-nonce-lanes.git
cd sei-nonce-lanes

For an existing clone, run git submodule update --init --recursive.Install the Node dependencies and run every local check:

cd app
npm ci
npm run check
cd ..

forge fmt --check
forge test -vv

The Foundry suite runs against the real EntryPoint v0.8 bytecode from the pinned dependency, placed at the canonical address inside the test VM. It verifies that different lanes can land in any order, that an execution revert affects only its own lane, that an operation that is never submitted blocks nothing, that a gap on one shared lane reproduces sequential blocking, that one validation failure reverts the whole bundle, that lane 0 is rejected, and that a 50-lane bundle fits in one outer transaction.

Choose a target network

Start with a local Prague fork. It carries the deployed EntryPoint bytecode from Atlantic-2 but spends only Anvil funds.

Never use Anvil, Hardhat, tutorial, or shared test mnemonics on Atlantic-2 or Pacific-1. Their addresses and keys are public, and some are already delegated to sweeper code, so a successful funding transaction can still leave a zero balance. The fork below also runs as chain 1328, so an authorization signed against it is replayable on Atlantic-2 itself whenever the account’s nonce lines up. Regenerate every key and mnemonic before you point a fork’s .env at a public network.

Local Anvil fork (recommended first)
Atlantic-2 testnet

EIP-7702 requires a Prague-capable node. Keep this terminal running:

anvil \
  --fork-url https://evm-rpc-testnet.sei-apis.com \
  --chain-id 1328 \
  --hardfork prague

The repository compiles its contracts for Cancun because they use no Prague-only opcodes, but the local node must run Prague to accept the type-4 delegation transaction.Create the configuration and point it at the fork:

cp .env.example .env

.env

SEI_CHAIN_ID=1328
SEI_RPC_URL=http://127.0.0.1:8545

RELAYER_COUNT=4
RELAYER_START_INDEX=1

Set TRADER_PRIVATE_KEY to account 0’s private key from the Anvil startup output, and RELAYER_MNEMONIC to the mnemonic printed by that same Anvil process. Starting relayers at index 1 keeps the funded account and relayer identities distinct; the application rejects overlapping identities.Those are Anvil’s published credentials, so this .env must only ever point at the fork.Deploy the demo contracts from the repository root using Anvil’s unlocked account:

forge script script/Deploy.s.sol:Deploy \
  --rpc-url http://127.0.0.1:8545 \
  --broadcast \
  --unlocked \
  --sender 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

Generate fresh credentials. Never reuse a key or mnemonic that has appeared in a tutorial, a test framework, or a shared document:

cast wallet new            # funded account key
cast wallet new-mnemonic   # relayer mnemonic

Fund the address from the Sei faucet, then configure:

cp .env.example .env

.env

SEI_CHAIN_ID=1328
SEI_RPC_URL=https://evm-rpc-testnet.sei-apis.com

TRADER_PRIVATE_KEY=0x...
RELAYER_MNEMONIC="word word word ..."
RELAYER_COUNT=4
RELAYER_START_INDEX=0

Deploy with a funded key. The deployer can be the throwaway account, but it does not have to be:

forge script script/Deploy.s.sol:Deploy \
  --rpc-url https://evm-rpc-testnet.sei-apis.com \
  --broadcast \
  --interactives 1

--interactives 1 prompts for the key and does not echo it, so it never reaches your shell history, the process table, or an environment variable.

Copy the two printed addresses into .env:

.env

LANE_ACCOUNT_IMPL=0x...
VENUE=0x...

Mutating commands refuse to write to a remote Pacific-1 RPC unless ALLOW_MAINNET=1 is set explicitly, and they refuse any remote-chain write when TRADER_PRIVATE_KEY is Anvil account 0 or RELAYER_MNEMONIC is the Anvil mnemonic. Those guards catch only an accidental SEI_CHAIN_ID=1329 run and the two most common leaked credentials. They do not cover the separate Forge deployment command, and they do not make the demo production-ready.

Check the preflight

status is read-only. Run it before anything that writes:

cd app
npm run status

It prints the chain ID, whether code exists at the EntryPoint address 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108, the account’s current delegation, balances, its EntryPoint deposit, each relayer’s confirmed nonce and gas balance, the lane sequences, and the venue state.

Delegate the account

npm run delegate

This sends one type-4 transaction with an authorization for LANE_ACCOUNT_IMPL, signed and paid for by the account itself, so the account’s EVM nonce advances by two: once for the transaction, once for the authorization. The command reads the account’s confirmed nonce once and pins both the transaction nonce and the authorization nonce (nonce + 1) to that read, instead of letting the client fill them from a pending-nonce lookup. That matters because a wrong authorization nonce is not rejected: the EVM skips the authorization, the transaction still succeeds, and nothing is installed. The command therefore re-reads the designator after the receipt and fails if the delegation did not take effect.The command is idempotent: if the account already delegates to the configured implementation, it does nothing. If the account delegates to something else, it tells you before replacing it.

Fund the relayers and the EntryPoint deposit

npm run fund
npm run status

fund uses ordinary transactions to top each relayer up to RELAYER_FUNDING SEI and to bring the account’s EntryPoint.depositTo balance up to ENTRYPOINT_DEPOSIT SEI. The deposit is what the EntryPoint draws prefund from when it validates each operation. On a public network you can instead send SEI to relayer 0 and run npm run dispense, which waits for the balance and splits it across the pool. Use one bootstrapping path or the other, not both.

Submit the run

npm run submit

One submit process performs the complete run and exits. It runs the preflight, estimates the delegated call’s gas, reads each lane’s sequence once, signs 24 operations concurrently with no nonce RPCs, journals them, bundles them, drains the bundles through the relayer pool, and prints a report. By default, order 2 receives a limit price below the mark, so its operation reverts during execution while the neighboring lanes continue.

Read the report

The output below is illustrative; your addresses, blocks, and timings will differ.

=== preflight ===
chain          Sei Testnet (1328)
rpc            http://127.0.0.1:8545
entryPoint     0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 (… bytes)
trader         0xf39F…2266
delegated to   0x5FbD…0aa3
…
trader nonce   9  <- watch this, it must not move
journal        0 pending op(s)
relayer        0x7099…79C8  0.5 SEI
…

=== build ===
call gas       78125 (estimate 62500)
lane pool      32 lanes, 32 idle
signed         24 new ops in 52ms, without nonce RPCs
hash check     local digest matches EntryPoint.getUserOpHash

=== submit ===
24 ops -> bundles of <=4 -> 4 relayers

  mined   lanes [32,31,30,29]  block 187213  gas 612345
  mined   lanes [28,27,26,25]  block 187213  gas 598120
  …

=== per-order outcome ===
  #  lane  seq  exec      filled  land#  block     note
   0    32    0  ok           yes      1    187213
   1    31    0  ok           yes      2    187213
   2    30    0  reverted     no       0    187213  expected revert (limit under mark)
   3    29    0  ok           yes      3    187213
  …

=== summary ===
ops submitted        24
ops landed           24
  executed ok        23
  reverted on chain  1  (each consumed only its own lane)
bundles              6 across 2 block(s)
  pending recovery   0
  failed safely      0
journal pending      0
distinct lanes       24
relayers used        4
sign time            52ms
submit time          1846ms
throughput           13.0 landed ops/sec

trader EVM nonce     9 -> 9  UNCHANGED
total wall time      4210ms

What to look for:

trader nonce before and trader EVM nonce after must be identical. The tool calls the funded account the trader. Its key never entered a queue.
call gas is the measured delegated-call estimate plus 25 percent. A CALL_GAS_LIMIT floor appears in that line only when you set one; leave it unset unless you have a reason, because the EntryPoint reserves the declared limit before running each operation.
exec combines the bundle receipt with the venue’s isFilled read. reverted means the outer transaction landed, so the operation consumed its lane sequence, but the call failed inside the venue. not mined would mean the outer transaction never landed and nothing was consumed.
land# is the venue’s global landing counter. It shows the order in which operations actually executed, which has nothing to do with lane number. Lane acquisition is last-in, first-out, so a fresh 32-lane pool starts at lane 32; lane numbers carry no priority.
hash check confirms that the locally computed EIP-712 digest matches EntryPoint.getUserOpHash for the first operation, so client-side hashing matches consensus.

If a bundle is reported as PENDING or FAILED, the command exits non-zero and leaves the journal intact. Run npm run submit again once the RPC can answer receipt and nonce queries; the process recovers or replaces at the same relayer nonce before it creates new work. Do not delete the journal and do not send the relayer’s next nonce by hand.

Optional: real swaps on Atlantic-2

The repository includes a real-target path that routes tiny native SEI and native USDC swaps through the documented DragonSwap V1 deployment on Atlantic-2. It is hard-blocked on every other chain. Get testnet USDC from the Circle faucet, then:

# from the app directory, where the walkthrough left off
npm run swap:setup
npm run swap:submit

swap:setup uses ordinary transactions to approve a limited amount of USDC and to create and seed the WSEI/USDC pair if the factory has no live pair. swap:submit alternates SEI to USDC and USDC to SEI swaps through independent lanes and reports outcomes from EntryPoint events rather than one RPC read per swap. The same knobs apply:

ORDERS=3000 \
LANE_POOL_SIZE=3000 \
MAX_OPS_PER_BUNDLE=4 \
REVERT_ORDER_INDEX=2 \
npm run swap:submit

The account must hold enough of both assets for every input-side swap to execute regardless of landing order. Set REVERT_ORDER_INDEX=-1 when you want to measure maximum throughput.

Optional: see the baseline you are escaping

# from the app directory, where the walkthrough left off
npm run baseline

Using a gas-only relayer key so nothing of value is at risk, baseline measures the constraint directly. It sends nonce n + 1 while deliberately skipping n, waits to see whether that transaction can be included above a gap, fills the gap with nonce n, then checks whether the skipped-ahead transaction lands once the gap is closed. The verdict is one of four outcomes:

Verdict	What the RPC path did	What happened to the out-of-order transaction
`REJECTED at admission`	Refused the gapped nonce, typically with `bad nonce`	Refused synchronously, so the sender learns at once and no gap forms on this path
`ADMITTED then dropped`	Returned a hash, then discarded the transaction	Lost without an error; it did not land even after the gap was filled
`QUEUED, then included once the gap filled`	Held it and released it in nonce order	Waited, then landed after nonce `n` arrived
`ACCEPTED and included above a gap`	Included it out of order	Landed before nonce `n`; this path does not enforce nonce order

The probe measures gap handling only. How many consecutive nonces one sender can have outstanding is a separate question, answered in Why this is hard to replicate: many, as long as they arrive in order. The probe samples both the latest and pending nonce tags before, during, and after, and prints any rejection message verbatim, because the exact message is the finding. If the two tags already disagree before the probe starts, it warns you: either the account has work in flight or the node reports a mempool-derived pending nonce, and in both cases the gap it is about to create may not be a gap at all, so the verdict cannot be attributed to nonce ordering. Compare the result with a submit run, where 24 operations from one account are mutually independent and one failure strands nothing. The verdict depends on the path. In one session, two Atlantic-2 RPC endpoints answered differently: a dedicated provider queued the gapped transaction and released it once the gap filled, while the public endpoint returned a hash and then dropped it, so it never landed even after the gap was filled. Neither rejected it at admission. Probe the path you will actually use.

Tuning

Three knobs shape a run. They interact, so change one at a time and measure.

Lane pool size: the ceiling on in-flight operations

One lane holds at most one in-flight operation, so LANE_POOL_SIZE is the hard ceiling on unresolved UserOperations in a process. Larger pools permit more concurrently unresolved intents, add startup getNonce reads (batched with bounded concurrency so a public RPC does not rate-limit you), and increase the recovery state you must understand after a failure. ORDERS must not exceed LANE_POOL_SIZE; the application rejects that configuration instead of silently submitting fewer operations.

Bundle width: gas efficiency against isolation

MAX_OPS_PER_BUNDLE trades amortized outer-transaction overhead for the size of the shared validation failure domain. A width of 1 gives maximum isolation and the highest overhead. Execution reverts stay per-operation at any width. The relayer caps signed transaction gas below the block gas limit it read at startup and rejects a bundle whose estimate cannot fit.A bundle does not need the sum of its operations’ declared call gas. The EntryPoint checks before each operation that enough gas remains to honor that operation’s callGasLimit, and whatever an operation leaves unspent passes to the next one, so the outer transaction needs the gas the bundle actually consumes plus about one operation’s declared limit in reserve. Over-declaring still has a cost: v0.8 charges 10 percent of unused call gas beyond a 40,000-gas threshold, and each operation reserves prefund from the deposit against its declared limits rather than its measured cost, so an inflated limit ties up deposit that is only refunded afterwards.That is why CALL_GAS_LIMIT is unset by default. Both submit paths measure the real call gas for the chain and call shape and add 25 percent; the variable is only a floor, and it has an effect only when you set it above that measurement. Because the EntryPoint reserves each operation’s declared call gas before running it, a floor above the measurement costs block gas, and therefore operations per block, without changing the gas actually used.As a reference point, on Atlantic-2 with CALL_GAS_LIMIT=500000, the default in an earlier revision of the repository, the real-swap path sustained 77 operations per bundle; 78 no longer fit the 12,500,000 block gas limit in effect during that run and failed safely during simulation. Width 76 produced the best observed submission rate for that call shape, 47.7 landed swaps per second. These are measurements for one call shape, one configuration, and one network state, not protocol limits.The mock venue is a heavier call. In the benchmark session, with CALL_GAS_LIMIT unset, each place operation used about 331,000 gas of outer transaction gas, so 36 operations was the widest bundle that fit and 37 failed safely in simulation. Widths 8, 16, and 36 packed 4, 2, and 1 bundles into a 12,500,000-gas block; width 9, which should fit 4, landed 3. Wide bundles also queue behind each other, because only one 11,700,000-gas bundle fits a block. With more than about 8 relayers at width 32 or 36, receipt waits exceed the default BUNDLE_RECEIPT_TIMEOUT_MS; raise the timeout for those shapes instead of paying for fee-bumped replacements of bundles that land anyway.

Relayer count: concurrent outer transaction streams

Each relayer has one sequential outer transaction stream. Under favorable admission and inclusion conditions, the immediate submission width is roughly RELAYER_COUNT × MAX_OPS_PER_BUNDLE per block. That is a planning heuristic, not a throughput guarantee: RPC latency, block limits, state contention, gas, and producer policy still apply. Public RPC endpoints have rate limits; use a dedicated provider or your own node for anything beyond a demo.One relayer’s bundle cycle is five sequential RPC round trips (gas estimate, fee estimate, block number, broadcast, receipt poll) plus inclusion, about 1.5 seconds on a 120 ms endpoint. Below roughly 120 operations in flight the pool is the bottleneck and throughput scales with RELAYER_COUNT; above that, block gas is. In the benchmark session, 4 relayers landed 2.7, 8.9, 15.3, 24.3, 45.4, and 50.5 operations per second at widths 1, 4, 8, 16, 32, and 36, and width 4 landed 2.2, 8.9, 15.4, 27.9, and 47.2 per second with 1, 4, 8, 16, and 32 relayers.

Configuration reference

The application always loads .env from the repository root. The variables you are most likely to change:

Variable	Default	Meaning
`SEI_CHAIN_ID`	`1328`	`1328` (Atlantic-2) or `1329` (Pacific-1)
`SEI_RPC_URL`	viem chain default	HTTP endpoint; its reported chain ID must match before any write
`ALLOW_MAINNET`	`0`	Must be `1` for writes to a remote Pacific-1 RPC
`TRADER_PRIVATE_KEY`	required	The funded account that signs every UserOperation
`RELAYER_MNEMONIC`	required	Fresh BIP-39 mnemonic used only for gas-paying relayers
`RELAYER_COUNT`	`4`	Relayer workers, `1..256`
`RELAYER_START_INDEX`	`0`	First derivation index; offset it if the mnemonic also holds the funded account
`RELAYER_FUNDING`	`0.5`	Target SEI balance per relayer for `fund`
`ENTRYPOINT_DEPOSIT`	`1`	Target deposit in the EntryPoint for `fund`
`LANE_ACCOUNT_IMPL`	unset	Deployed `LaneAccount`; required by `delegate` and `submit`
`VENUE`	unset	Deployed demo target; required by `submit`
`ORDERS`	`24`	Operations per run; must not exceed `LANE_POOL_SIZE`
`LANE_POOL_SIZE`	`32`	`1..4096` lanes and the in-flight ceiling
`MAX_OPS_PER_BUNDLE`	`4`	`1..LANE_POOL_SIZE` operations sharing one validation domain
`REVERT_ORDER_INDEX`	`2`	Order that receives an unfillable limit price; `-1` disables
`CALL_GAS_LIMIT`	unset	Optional floor for each operation’s declared call gas; when unset, the live estimate plus 25 percent is used
`BUNDLE_RECEIPT_TIMEOUT_MS`	`12000`	Receipt wait before same-nonce replacement
`RECEIPT_POLLING_INTERVAL_MS`	`250`	Receipt poll interval, `10..60000`; viem’s own default is `4000`
`BUNDLE_MAX_ATTEMPTS`	`3`	Same-nonce attempts per process invocation
`REPLACEMENT_FEE_BUMP_PERCENT`	`25`	Fee increase per replacement, `10..1000`
`OPERATION_JOURNAL_PATH`	`app/.state/pending-ops.json`	Durable signed-operation journal

The repository README documents the full set, including the real-swap variables.

Benchmarks

app/bench/ measures the lane path against the baseline it replaces: one EOA sending ordinary transactions with sequential nonces. Every mode calls the same MockPerpVenue.place on the configured VENUE, so the numbers differ only in how the calls were submitted. The commands read the root .env, and the shell environment overrides it:

cd app

# Lane throughput for one run shape. Same safety path as submit, outcomes read
# from the bundle receipts, one JSON line appended to .state/bench/lanes-results.jsonl.
ORDERS=1024 LANE_POOL_SIZE=1024 MAX_OPS_PER_BUNDLE=16 RELAYER_COUNT=16 \
REVERT_ORDER_INDEX=-1 BENCH_LABEL="16x16" npm run bench:lanes

# The same over several "RELAYER_COUNT MAX_OPS_PER_BUNDLE" combinations.
BUNDLE_RECEIPT_TIMEOUT_MS=60000 npm run bench:sweep -- sat "32 8" "16 16" "16 36"

# One EOA with sequential nonces, every nonce taken from one confirmed read.
BENCH_MODE=serial        BENCH_TXS=30   npm run bench:baseline
BENCH_MODE=pipelined     BENCH_TXS=200  npm run bench:baseline
BENCH_MODE=batch         BENCH_TXS=1024 npm run bench:baseline
BENCH_MODE=pipelined-gap BENCH_TXS=100  BENCH_GAP_INDEX=50 npm run bench:baseline
BENCH_MODE=fleet         BENCH_TXS=64   BENCH_FLEET_SIZE=8 BENCH_FUND_SEI=4 npm run bench:baseline

# What the chain included, block by block, independent of any client clock.
REPORT_FROM_BLOCK=<first block> REPORT_TO_BLOCK=<last block> npm run bench:report
npm run bench:latency

The bench:baseline modes are the ways one address can drive a sequential queue. serial sends one transaction and waits for its receipt before the next. pipelined signs everything up front and broadcasts in nonce order without waiting. pipelined-gap does the same but never broadcasts the transaction at BENCH_GAP_INDEX, then repairs the gap. batch sends everything in one JSON-RPC batch request. fleet derives BENCH_FLEET_SIZE wallets from RELAYER_MNEMONIC, funds them from the account, and runs pipelined on each at once. bench:lanes shares the account-wide run lock with submit and swap:submit but keeps its own journal under app/.state/bench/, so a benchmark never replays the tutorial’s pending operations. If a submit run was interrupted, recover it with npm run submit first. The remaining BENCH_* and REPORT_* knobs are documented in the repository README.

Measured against the alternatives

Every row below comes from one measurement session on Atlantic-2. Conditions during the session: block gas limit 12,500,000; base fee 50 gwei plus a 1 gwei tip; about 2.0 blocks per second under load; 120 ms warm request latency to the configured endpoint. Each direct place transaction used 328,425 gas and each lane operation about 331,000 gas of outer transaction gas, so the block admits 36 to 38 operations however they are submitted: roughly 73 landed operations per second for this call shape. Chain-side rates divide landed operations by the block-timestamp span, which Sei stamps in whole seconds. Client-side rates divide by wall time from first broadcast to last receipt.

Submission	Landed ops/s, chain-side	Client-side	Block gas used, average
One EOA, serial send and wait (30 tx)	1.0	1.0	not recorded
One EOA, pipelined, one request in flight (200 tx)	6.9	6.7	not recorded
Tutorial lanes, 4 relayers × 4 per bundle (24 ops)	8.0	5.7	11%
Fleet of 4 wallets × 100 tx	26.7	24.8	not recorded
Fleet of 8 wallets × 64 tx	51.2	49.7	54%
One EOA, 1,024 tx in one JSON-RPC batch	51.2	47.3	68%
Lanes, 32 relayers × 8 per bundle (1,024 ops)	60.2	55.3	83%
Lanes, 16 relayers × 16 per bundle (1,024 ops)	64.0	54.6	81%
Lanes, 16 relayers × 36 per bundle (1,024 ops)	64.0	55.1	88%

What the numbers show:

Block gas, not the nonce model, set the ceiling. Lanes came closest to it, with 28 of 31 blocks at least 90 percent full in the 16 × 36 run, from one address whose EVM nonce never moved. A single ordered queue matched the fleet only when every transaction left in one JSON-RPC batch; one request at a time, it is bounded by the round trip, about 7 per second.
Small relayer pools are client-bound. Throughput scales with RELAYER_COUNT until roughly 120 operations are in flight, then block gas takes over. The relayer and width series are in Tuning.
A gap costs the whole queue. One lost transaction in the sequential queue (pipelined-gap, nonce 50 of 100) left the 49 transactions behind it accepted but unmined until the client resent it 15 seconds later. In the lane runs, the deliberately reverting order consumed only its own lane while the rest of its bundle landed.
RPC paths differ. npm run baseline gave two different verdicts for two Atlantic-2 endpoints in the same session.

These are measurements of one call shape, one network state, and one client machine, not protocol limits. Cost was about 0.02 SEI per landed operation at the effective 52 gwei. Rerun the benchmarks against the network and endpoint you will actually use; block time and gas limits differ between Twin Turbo Consensus and Sei Giga. The raw records under app/.state/bench/ include a journal for bench:lanes, which you should treat like pending-ops.json.

Adapting it to your contract

The demo’s MockPerpVenue is a stand-in that reverts on slippage so a failure is observable. Swapping it for a real target means encoding a different call. LaneAccount.execute(target, value, data) forwards any call, and the target sees the funded EOA as msg.sender:

import { encodeFunctionData } from 'viem';
import { buildOp, signUserOp, userOpHash } from './userop.js';

// Any call your contract accepts from the funded EOA.
const data = encodeFunctionData({
  abi: targetAbi,
  functionName: 'placeOrder',
  args: [market, side, size, limitPrice],
});

// One lane per in-flight intent. The pool tracks sequences locally.
const slot = lanePool.acquire();
if (!slot) throw new Error('lane pool exhausted; raise LANE_POOL_SIZE');

const unsigned = buildOp({
  sender: account.address, // the delegated EOA
  lane: slot.lane,
  seq: slot.seq,
  target: TARGET,
  value: 0n, // native SEI to forward, if the call needs it
  data,
  verificationGasLimit,
  callGasLimit,
  preVerificationGas,
  maxFeePerGas,
  maxPriorityFeePerGas,
});

const op = await signUserOp(account, unsigned, chain.id, ENTRY_POINT);
bundlingQueue.add({
  op,
  hash: userOpHash(op, chain.id, ENTRY_POINT),
  lane: slot.lane,
  seq: slot.seq,
  orderId,
  label: '',
});

The real-swap path in app/src/swap-submit.ts is a complete example of this against a live router, including forwarding native SEI as value. Check these before you trust a new target:

msg.sender and tx.origin. At the target, msg.sender is the funded EOA and tx.origin is the gas-paying relayer. Contracts that require tx.origin == msg.sender are incompatible. Audit each router, approval path, callback, reentrancy assumption, and authorization rule.
Gas on Sei. Storage writes cost materially more than on Ethereum. The application estimates the delegated call live and declares that estimate plus 25 percent, raised to CALL_GAS_LIMIT only when you set that floor higher. Do not copy Ethereum-sized static limits in either direction: too low runs out of gas, and too high reserves block gas your operations never use. See Gas and fees.
Storage contention. Lanes remove submission ordering, not execution conflicts. Analyze which storage slots your calls touch; see Optimizing for parallelization.
Lane policy. One lane per in-flight intent is the simplest correct policy. If some calls must stay ordered relative to each other, put them on one lane (or on ADMIN_LANE) rather than falling back to lane 0.

Before you adapt this

The repository is explicit about what it leaves out. Before this design touches real funds, add at least:

audited account and integration contracts;
hardware-backed or remote signing;
a real risk engine with an idempotent intent model;
durable, replicated queue and reconciliation storage;
metrics, tracing, alerting, and structured logs;
controlled deployment and delegation procedures;
RPC redundancy and chain-specific fee policy;
graceful shutdown and operator runbooks; and
load, fault-injection, and live-chain recovery testing.

EIP-7702 changes the code that executes at your address. Before delegating, verify the implementation source and deployed address, verify the target chain, inspect any existing delegation, and use a throwaway account for this demo. submit refuses to run if the current designator does not exactly match LANE_ACCOUNT_IMPL.

Treat .env, app/.state/, signed raw transactions, and RPC URLs containing credentials as sensitive. The journal does not contain private keys, but it contains signed UserOperations and replayable raw transactions until their nonces are consumed. Clone the repository for a teammate and create fresh keys; do not copy a working directory.

Troubleshooting

RPC chain ID does not match

Check both SEI_CHAIN_ID and SEI_RPC_URL. For a local fork, pass --chain-id 1328 to Anvil. The configured chain ID is part of the EIP-712 signature domain and cannot be guessed safely.

EntryPoint v0.8 … MISSING

The RPC has no code at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108. Confirm the chain and the fork source before deploying anything. The preflight checks for code presence, not byte-for-byte identity; verify canonical addresses independently before a real deployment.

Delegation mismatch

Run npm run status and compare delegated to with LANE_ACCOUNT_IMPL. Do not blindly replace an unexpected designator. Confirm the account, chain, and implementation first, then run npm run delegate deliberately.

Relayer has no gas

Run npm run fund, or send SEI to relayer 0 and run npm run dispense.

simulation failed: AA…

Common validation causes: AA24 is an invalid signature or the wrong EIP-712 chain or domain; AA25 is a stale or incorrect lane sequence; an insufficient EntryPoint prefund; or delegation to the wrong account implementation. Run npm run status and resolve the cause before widening bundles or retrying.

AA95 out of gas while widening bundles

AA95 is the EntryPoint’s report that the outer transaction had less gas left than an operation’s declared limits require. In general it points to an outer gas limit or estimation headroom that is too low, not to network capacity. While widening bundles, the usual cause is the block gas limit: simulation cannot find an outer gas amount under that limit that satisfies the check, and the relayer never signs above the limit it read at startup. Nothing in a bundle that fails simulation is broadcast or consumed. Rerun with a smaller MAX_OPS_PER_BUNDLE; the durable queue is repacked at the smaller width.

Journal lock is owned by another process

Only one lane-based process may use an account at a time, even when submit and swap:submit use different journals. Stop the other process. A lock whose recorded PID is no longer alive is removed automatically on the next run.could not acquire the lock … within 2000ms is different. The lock file exists but its contents could not be parsed, so the process cannot tell whether a live holder owns it, and it refuses to remove a lock it cannot attribute. A torn or truncated file left by a dead process and a live holder caught mid-publish produce the same message, and the message repeating across runs does not distinguish between them. Removing a lock that a live process holds lets two processes sign for the same account, which produces duplicate operations on the same lane sequences and conflicting relayer nonces.Before deleting a lock file by hand, confirm that no submit, swap:submit, or bench:lanes process is running against this account. Read the pid from the file if it is legible, and check the process table on every host that shares the state directory. Both locks live under app/.state/: the account-wide run lock (sender-<chainId>-<address>.lock, or SENDER_RUN_LOCK_PATH) and one .lock file next to each journal. Delete the file only after that check.

A bundle remains in pending recovery

Do not delete the journal and do not send the relayer’s next nonce manually. Run npm run submit again once the RPC can answer receipt and nonce queries. If the application reports partial lane consumption or a state it cannot reconcile, stop and inspect the EntryPoint events, every attempted transaction hash, the relayer’s confirmed nonce, and each lane sequence.

Resources

sei-nonce-lanes

Source, tests, benchmarks, and the full configuration reference.

EIP-7702: Set EOA account code

The delegation mechanism that keeps the funded address.

ERC-4337: Account abstraction

UserOperations, the EntryPoint, and two-dimensional nonces.

ERC-7562: Validation and mempool rules

The alt-mempool rules the in-process bundling queue sidesteps.

Finality and block tags

Why one confirmation is final and the pending view is unreliable.

Transaction types

Type-4 support and authorization list requirements on Sei.

Pimlico

A hosted ERC-4337 bundler and paymaster, if you want sponsorship instead of throughput.

Thirdweb EIP-7702

EIP-7702 delegation for consumer wallet flows.

Overview

Essentials

seid CLI

Frontend Development

Smart Contracts

sei-js Library

Videos

Ecosystem Tutorials

Reference

Hardware Wallets

Nonce Lanes: Concurrent Submission from One Account

Why one account is one queue

How it works

ERC-4337 nonce lanes

EIP-7702 keeps the funded address

Gas-only relayers carry what is left of the queue

One bundle, start to finish

What fails alone and what fails together

Why this is hard to replicate

Tutorial: run the reference implementation

Prerequisites

Read the report

Optional: real swaps on Atlantic-2

Optional: see the baseline you are escaping

Tuning

Configuration reference

Benchmarks

Measured against the alternatives

Adapting it to your contract

Before you adapt this

Troubleshooting

Resources

sei-nonce-lanes

EIP-7702: Set EOA account code

ERC-4337: Account abstraction

ERC-7562: Validation and mempool rules

Finality and block tags

Transaction types

Pimlico

Thirdweb EIP-7702

​Why one account is one queue

​How it works

​ERC-4337 nonce lanes

​EIP-7702 keeps the funded address

​Gas-only relayers carry what is left of the queue

​One bundle, start to finish

​What fails alone and what fails together

​Why this is hard to replicate

​Tutorial: run the reference implementation

​Prerequisites

​Read the report

​Optional: real swaps on Atlantic-2

​Optional: see the baseline you are escaping

​Tuning

​Configuration reference

​Benchmarks

​Measured against the alternatives

​Adapting it to your contract

​Before you adapt this

​Troubleshooting

​Resources

sei-nonce-lanes

EIP-7702: Set EOA account code

ERC-4337: Account abstraction

ERC-7562: Validation and mempool rules

Finality and block tags

Transaction types

Pimlico

Thirdweb EIP-7702

Why one account is one queue

How it works

ERC-4337 nonce lanes

EIP-7702 keeps the funded address

Gas-only relayers carry what is left of the queue

One bundle, start to finish

What fails alone and what fails together

Why this is hard to replicate

Tutorial: run the reference implementation

Prerequisites

Read the report

Optional: real swaps on Atlantic-2

Optional: see the baseline you are escaping

Tuning

Configuration reference

Benchmarks

Measured against the alternatives

Adapting it to your contract

Before you adapt this

Troubleshooting

Resources