# Nonce lanes and ordering

Source: https://docs.settlemint.com/docs/architects/components/infrastructure/advanced-accounts/nonce-lanes-and-ordering
How DALP maps UserOperations to ERC-4337 nonce lanes, why three distinct work states matter, and the trade-offs between strict, grouped, and independent ordering.



A smart-account execution layer has one core tension: it must accept authorized work durably and drain it without violating nonce order or exceeding capacity. Getting this wrong causes one of two failures. Silent drops: the platform discards a submission. False serialization: independent work queues behind unrelated operations and the whole flow looks slow.

DALP resolves this with a two-dimensional nonce space and a small set of ordering policies. The policy reflects whether two operations share a real causal dependency, not an arbitrary choice. If you are designing a multi-step token flow, that distinction determines whether your steps run in parallel or queue behind each other.

## Three states, not one queue [#three-states-not-one-queue]

Most reasoning errors here come from treating "the queue" as a single thing. The platform tracks three distinct states, and conflating them is the common design error.

Accepted work is the durable intake record. When the platform accepts a submission it writes a durable record. This answers "did the platform drop it?" independently of whether the work can be prepared or packaged into a bundle right now. The record survives restarts, is bounded only by authorization and org scope, and is never silently discarded.

Preparing work is bounded by shared capacity: simulation RPC slots, signing key access, and mempool submission bandwidth. A submission moves from accepted to preparing when capacity is available. 500 accepted submissions from one account will eventually prepare. They cannot all prepare at once, but the platform does not reject them at intake just because they exceed what a single bundle can hold.

Ready work is what can become an on-chain bundle. Bundle size, gas limits, and the EntryPoint nonce sequence constrain it. The EntryPoint consumes sequence numbers in order per key, so ready work must respect that order or the bundle reverts.

"Not yet ready to bundle" is not "rejected." The queue is not the bundle.

## How the 2D nonce encodes ordering scope [#how-the-2d-nonce-encodes-ordering-scope]

Understanding the nonce structure helps you reason about which operations can run in parallel. ERC-4337 nonces are 256 bits split as `(key << 64) | sequence`. The key (uint192) identifies a lane. The sequence (uint64) must increment without gaps within that lane. DALP uses ERC-7579 validator-scoped keys, so the key packs the validator address and a subKey:

```
nonce = ((validatorAddress || subKey) << 64) | sequence
```

The EntryPoint tracks sequences independently per sender and per key. Two operations with different nonce keys have no ordering constraint relative to each other, even from the same sender. That independence is what makes lanes useful.

Per-partition coordination is keyed by `(sender address, chain id, nonce key)`. On first use DALP cold-starts the sequence by reading `EntryPoint.getNonce(sender, key)`. Reservations carry a TTL (default five minutes) so a failed or abandoned operation releases its slot instead of blocking the lane.

## Ordering policies and when to use each [#ordering-policies-and-when-to-use-each]

DALP exposes three policies. Choose based on whether your operations share a causal dependency.

**Transaction** gives each UserOperation its own independent lane. The subKey is derived deterministically from the transaction identifier. No ordering constraint exists between any two submissions. Use this policy when operations are fully independent, for example parallel token transfers to different recipients.

**Group** assigns all UserOperations that share an explicit `orderingKey` to a single lane. Everything in the group stays sequenced, and work in different groups runs in parallel. Use it when step A must precede step B (a grant that must follow a role creation) but the flow has no dependency on unrelated flows running at the same time.

**Wallet** places all of a wallet's operations on subKey `0x0`, giving one globally ordered lane per wallet. This enforces FIFO: every operation waits behind the one before it. Use it only when the product genuinely requires total ordering, because it serializes everything.

The lane policy is either strict (always subKey `0x0`, enforced FIFO regardless of the chosen policy) or independent (deterministic subKey derivation per seed, or an explicit subKey, which enables the parallelism that transaction and group policies provide).

## Why this matters for product flows [#why-this-matters-for-product-flows]

Consider a token-creation flow: create the token, assign roles, optionally attach a price feed. If those steps have no causal dependency, each can claim an independent lane and prepare in parallel, and all three settle quickly. Force them onto one wallet lane and they queue sequentially, making the flow look slow. The cause is not a slow bundler. The ordering model does not match the work.

An organization submitting 500 authorized submissions should not see those requests rejected at intake because they exceed a single bundle. The platform accepts them, prepares them in batches bounded by capacity, and drains them across lanes. Acceptance is not gated on bundle capacity.

## Trade-off summary [#trade-off-summary]

Choose the most relaxed policy that your causal dependencies allow.

| Ordering scope | Parallelism | Causal safety | Typical use                                  |
| -------------- | ----------- | ------------- | -------------------------------------------- |
| Transaction    | Maximum     | None          | Independent transfers, parallel mints        |
| Group          | Per-group   | Within group  | Multi-step flows with internal dependencies  |
| Wallet         | None        | Total         | Strict FIFO requirement, audit-critical work |

Stricter than the work requires is not safer. You trade throughput for a constraint the work does not have. A looser choice risks an on-chain revert: a dependent operation reaches the EntryPoint before its prerequisite. Pick the most relaxed option that your causal dependencies allow.

## Related pages [#related-pages]

* [Advanced accounts concept](/docs/architecture/concepts/account-abstraction) for the smart-account execution route and the boundary between routing, identity, and policy.
* [UserOperations](/docs/architects/components/infrastructure/advanced-accounts/user-operations) for the structure and lifecycle of a UserOperation before it reaches intake.
* [Bundlers](/docs/architects/components/infrastructure/advanced-accounts/bundlers) for how DALP's controlled bundler differs from a public ERC-4337 bundler.
* [Advanced accounts design](/docs/architects/components/infrastructure/advanced-accounts/advanced-accounts-design) for validator-scoped keys and the ERC-7579 module model.