Cross-Rollup Atomicity: Shared Sequencers, State Locks, and 2PC

Shared ordering is not cross-rollup atomicity

A shared sequencer can give several rollups a common ordering layer. That is valuable. It reduces sequencing fragmentation, improves pre-confirmation latency, and creates a better time base for cross-rollup applications. It does not, by itself, guarantee that a transaction executed successfully on Rollup A will also execute successfully on Rollup B. Ordering decides the relative position of inputs. Execution still happens inside each rollup’s VM, account model, gas rules, contract logic, and settlement pipeline.

For an AllSwap-style cross-chain routing interface, that distinction is critical. A user does not ask for “two independent rollup transactions.” The user asks for one outcome: debit on chain A, credit on chain B, and a verifiable refund path if the route fails. If a shared sequencer only confirms input order, but one execution layer fails because of gas, state conflicts, contract pause, stale oracle state, or proof delay, the user can still end up with split state: funds locked on one chain and no final credit on the other.

This article analyzes the missing layer between shared sequencing and real cross-rollup atomicity: conditional state locks, execution receipts, timeout rules, and a two-phase commit style state machine that can turn “ordered together” into “commit together or abort together.”

Sequencing, execution, and settlement are separate systems

The model here is cross-rollup atomic interoperability. It is not a centralized exchange ledger and it does not assume that AllSwap has already implemented a shared sequencer path. The system has five roles:

- User or router `U`: submits a cross-rollup intent, such as lock on chain A, swap on chain B, receive on chain C. - Shared sequencer `Q`: orders transactions for multiple rollups and may provide pre-confirmations. - Rollup execution layer `E_i`: independently executes local transactions and produces local receipts or state roots. - Settlement layer `L1`: accepts rollup batches, validity proofs, or fraud proofs. - Coordination contract `C`: tracks conditional locks, receipts, deadlines, commit, abort, refunds, and penalties.

The minimal atomicity target is:

`commit(T) = all(success_i) OR rollback(all prepared_i)`

Here `T` is a cross-rollup transaction. `success_i` means participant rollup `i` has committed its local transition. `prepared_i` means rollup `i` has entered a reversible prepared state. The shared sequencer can help all rollups observe the same transaction order, but it cannot prove local success and cannot roll back each VM. A correct protocol has to separate ordering, execution receipts, settlement evidence, and rollback rights.

Conditional state locks are the minimum primitive

Classic two-phase commit has a prepare phase and a commit phase. In rollups, the database row lock becomes a chain-level conditional state lock. On chain A, the asset should not immediately leave the user’s recoverable control; it should enter `locked(intentId, amount, timeout)`. On chain B, the target operation should not be treated as final; it should produce `prepared(intentId, receiptRoot)`. Only when all participant chains produce valid prepare receipts should a coordinator or application contract trigger commit. If any participant fails or the deadline expires, all prepared states must move to abort or refund.

The flow is:

1. `order(intentId)`: the shared sequencer places the cross-rollup intent in a global order. 2. `prepare_i(intentId)`: each rollup performs local checks and enters a conditional lock. 3. `receipt_i = prove(prepared_i)`: the rollup produces a verifiable prepare receipt. 4. `commit(intentId)`: all required receipts are present, so the transaction commits. 5. `abort(intentId)`: one participant fails or times out, so all prepared locks are released or compensated.

The important constraint is that prepare must be reversible. If chain A transfers the asset completely to a market maker during prepare, and chain B later fails, the system is relying on credit compensation, not atomicity. A prepare step should lock assets, reserve balances, freeze object versions, or commit to minimal state. Irreversible external side effects belong in commit, not prepare.

This sacrifices some capital efficiency. It is still the price of having a machine-checkable failure boundary.

Why shared sequencers still need receipts

Astria and Espresso-style systems aim to give multiple rollups access to a shared sequencing or confirmation network. Astria describes a sequencing layer where many rollups can share one decentralized sequencer network. Espresso’s confirmation-layer framing emphasizes fast, verifiable agreement on inputs across composable chains. These are input-consistency systems.

Execution consistency is a different problem. Rollup A may run an EVM environment, Rollup B may use a different state model, and Rollup C may be constrained by a separate data-availability and settlement cadence. A contract call that prepares successfully on A tells us nothing about account locks, object versions, gas limits, or oracle state on B. The shared sequencer sees transaction data and order. It does not directly observe final local state.

Cross-rollup 2PC therefore needs at least three receipts:

- Ordering receipt: proves the intent occupied a particular shared-sequencer slot or confirmation batch. - Execution receipt: proves that a given rollup entered `prepared` or `committed`. - Settlement receipt: proves that the execution result can survive the rollup’s settlement or challenge process.

Without execution receipts, ordering is only intent. Without settlement receipts, execution may be only local optimism. Without deadlines, failed paths can remain locked indefinitely.

Receipts must also bind ordering context. A local `prepared(intentId)` is only meaningful across rollups if it references the shared sequencer slot, batch hash, or confirmation certificate. Otherwise, a coordinator could splice a local receipt from one context into a different cross-rollup transaction. A minimally useful receipt should bind `intentId`, `rollupId`, `globalOrderRoot`, `localStateRoot`, `phase`, and `deadline`.

There is a further distinction between a local receipt and an externally verifiable receipt. A rollup node can emit a local execution log quickly, but another chain may not be able to trust it until the corresponding batch, proof, or fault-proof window reaches an acceptable checkpoint. The protocol has to decide whether a local prepared receipt is enough to move forward, whether it must be backed by a sequencer confirmation, or whether it needs settlement-layer evidence. That choice is economic as much as technical. A small transfer can rely on faster evidence if a bond covers the failure radius. A large treasury movement should wait for stronger evidence.

State-lock data structure

A cross-rollup state lock should not be a single boolean. It needs enough structure to make failure attributable:

- `intentId`: unique cross-rollup transaction identifier; - `participants`: rollups and contracts involved; - `phase`: `ordered`, `prepared`, `committed`, `aborted`, or `expired`; - `deadline`: latest valid commit or abort time; - `assetLocks`: assets or permissions locked on each chain; - `receiptRoots`: prepare and commit receipt roots; - `refundTo`: refund or compensation account; - `slashableBond`: solver, relayer, or coordinator bond.

This data model is what turns a stuck swap into a diagnosable state. If rollup B fails to submit a prepare receipt by the deadline, rollup A can release the lock to `refundTo`. If a coordinator has all receipts but refuses to commit, its bond can be slashed. If a rollup submits a forged receipt, responsibility moves to that rollup’s proof or settlement system.

State locks also need garbage collection. Cross-rollup protocols can easily leave failed intents behind. If each expired intent permanently occupies contract storage, an attacker can create state bloat with low-value transactions. A better design separates hot lock state from archival evidence: active locks remain in contract storage; completed or expired intents retain only replay protection and indexable events.

The lock also needs a clear ownership model. A user lock, a solver lock, and an AMM inventory lock are not the same asset from a risk perspective. If a solver fronts liquidity, the user may be complete while the solver still waits for rebalancing. If an AMM pool is locked, other users may experience worse prices even though their own swaps are unrelated. A route-scoring engine should therefore distinguish user-facing finality from back-office rebalancing finality. Treating both as one “pending” state hides capital cost.

Shared sequencers, encrypted mempools, and MEV

Shared sequencing changes MEV. If several rollups expose transactions to one ordering layer, cross-rollup arbitrage, liquidation, and routing opportunities become visible earlier. Radius-style encrypted mempool work, including PVDE and SKDE discussions, tries to make sequencers commit to order before seeing transaction contents. That reduces the ability of the ordering layer to sandwich users.

This is related to atomicity, but it is not the same. Encrypted ordering helps with fairness. Two-phase commit and state locks help with execution consistency. Blind ordering does not make execution reversible. Unified ordering does not make local state transitions globally committed.

There is also a settlement issue. A shared sequencer may provide soft confirmations before rollup data is published to the DA layer and before the settlement layer accepts the state root. For low-value interactions, that may be a reasonable UX trade-off. For asset release, a soft confirmation should usually be treated as a prepare signal, not a final commit signal. If the shared-sequencer confirmation diverges from later DA or settlement evidence, applications that released assets too early inherit the loss.

Where state split happens

The first failure mode is local execution failure. The shared sequencer ordered the transaction, but one rollup cannot prepare because of gas limits, paused contracts, account-lock conflicts, stale object versions, or oracle changes. The mitigation is static simulation before prepare, verifiable execution receipts after prepare, and automatic abort after the deadline.

The second failure mode is receipt delay. A rollup entered prepared state, but the receipt was not delivered to the coordinator in time. If the deadline is too short, valid transactions abort unnecessarily. If it is too long, user funds and market-maker inventory remain locked. Timeout parameters must account for block time, proof time, DA publication, and settlement delay.

The third failure mode is coordinator behavior. A solver or relayer may submit only receipts that benefit it, delay commit after market conditions change, or disappear after locking user funds. Permissionless receipt submission, slashable bonds, and idempotent commit/abort functions reduce this risk.

The fourth failure mode is settlement reversal. A rollup may produce a local prepared receipt that is later challenged or invalidated on the settlement layer. If cross-rollup commit happens before enough settlement confidence, another chain may enter an irreversible state based on a receipt that will not survive. High-value routes should wait for stronger settlement evidence or require a bond that covers rollback loss.

The fifth failure mode is deadlock. Several cross-rollup intents may lock overlapping pools, accounts, or objects. Traditional databases use wait-for graphs to detect cycles. A rollup system can model dependencies through `intentId`, resource ID, and deadline. The conservative rule is to grant conflicting locks according to global order. That sacrifices concurrency but gives deterministic liveness.

The sixth failure mode is partial commit. A coordinator gathers prepare receipts from A and B, but the commit message succeeds on A and fails on B because of gas or congestion. Commit must therefore be idempotent. Anyone should be able to replay `commit(intentId)` or `abort(intentId)` until the transaction reaches a terminal state. A new intent should not be created just to “try again,” because that bypasses the original lock and can create duplicate release risk.

The seventh failure mode is liquidity-locking attack. An attacker can submit many small but realistic intents, force multiple pools into prepared state, then withhold one receipt or let deadlines expire. The result is not theft; it is inventory paralysis. Defenses need dynamic bonds priced by locked notional, lock duration, and resource conflict.

An eighth failure mode is inconsistent abort semantics. Chain A may abort by unlocking funds, chain B may abort by deleting a claim, and chain C may abort by minting a compensation asset. If these actions are not semantically equivalent, the system can finish in an “aborted” phase while still leaving economic residue. The coordination layer should define what abort means for each participant before accepting the route. Otherwise, the abort path becomes a second, less-tested settlement protocol.

What this means for AllSwap routing

AllSwap does not need to expose a 2PC diagram to every user. It does need to price atomicity internally. A cross-rollup route can be classified into four levels:

- `best-effort`: independent execution, failure handled by external compensation or manual recovery; - `sequenced`: shared sequencer gives input ordering, but execution rollback is not guaranteed; - `prepared`: destination chains can provide conditional locks and prepare receipts; - `atomic-settlement`: all participants have verifiable commit/abort and refund rules.

This affects [AllSwap fees](/fees) and route choice. The cheapest route is not always the safest route. For large orders, a prepared or atomic-settlement path may justify higher fees and longer waiting time. For small low-risk transfers, a user may rationally prefer a faster sequenced route.

A route score can be modeled as:

`routeScore = priceScore + latencyScore - atomicityPenalty - refundPenalty - liquidityLockPenalty`

`atomicityPenalty` depends on support for prepare, commit, and abort. `refundPenalty` depends on whether failed execution has onchain evidence. `liquidityLockPenalty` captures how long funds or market-maker inventory are conditionally locked. A route with only shared ordering should not receive zero atomicity penalty.

The user-facing explanation can stay simple: faster settlement with weaker failure recovery, or slightly slower settlement with stronger refund evidence. The backend still needs a complete state machine. Every cross-rollup swap should be queryable by phase, prepared participants, submitted receipts, remaining deadline, refund target, and slashable bond.

This also affects solver competition. Solver A may quote a lower price through a best-effort path, while Solver B quotes slightly higher with prepare receipts, a bond, and an onchain refund path. The router should not mechanically choose A. Cross-chain routing is optimizing for successful settlement and verifiable recovery, not only execution price.

On an asset page such as [/assets/usdc](/assets/usdc), atomicity level also affects asset semantics. A user may not yet hold the final asset; they may hold a pending claim, prepared receipt, or solver-backed IOU. Showing all of these as “arriving” hides risk. Better state labels are `ordered`, `prepared`, `settling`, `refundable`, and `completed`.

Retry logic must be explicit. If cross-rollup commit fails, the system should not create a new intent to retry, because the new intent bypasses old locks and receipts. Anyone should be able to replay idempotent commit or abort for the same `intentId` until it reaches a terminal state.

Checkpoint choice should depend on value. Small routes may accept shared-sequencer soft confirmation plus bonded coverage. Large routes should wait for DA publication, rollup state roots, or L1 settlement evidence. Putting every order into one waiting window damages both safety and UX.

A practical UI can hide most of this complexity, but the API should not. Each route quote should carry machine-readable fields such as `atomicityLevel`, `maxLockTime`, `refundEvidence`, `bondCoverage`, and `settlementCheckpoint`. Wallets and professional users can use those fields directly. Retail users can see a simpler warning only when the route meaningfully changes their recovery rights.

The same data helps support and incident response. When a route stalls, the operator should be able to say whether it is waiting for a prepare receipt, a commit retry, a settlement checkpoint, or an abort deadline. Without that state, every failed cross-rollup swap looks like a generic bridge delay, and the team cannot separate liquidity issues from proof issues or coordinator issues.

That difference matters most during market stress, when delayed settlement and unclear refunds create the largest user losses.

Atomic routing should make that recovery path explicit before execution begins.

Open problems

Cross-rollup receipt standards are not mature. EVM events, OP Stack interop messages, IBC packets, Move object events, and Solana account proofs have different semantics. A general 2PC coordinator needs a common receipt abstraction before it can work across ecosystems.

The market has not converged on soft-confirmation risk pricing. Shared sequencers can give valuable fast confirmations, but high-value asset release may still need DA or settlement evidence. Routers need dynamic waiting policies based on amount, asset type, and chain risk.

State locks consume liquidity. Stronger atomicity can tie up user funds, solver inventory, and AMM balances. Systems must price lock duration and opportunity cost instead of pretending atomicity is free.

The coordinator market is underdeveloped. Who submits receipts, who pays gas, who posts bonds, and who gets slashed after failure are economic questions, not just protocol details.

Cross-VM rollback semantics are inconsistent. EVM contracts can lock ERC-20 balances. Move systems may lock object capabilities. SVM environments rely on account write locks. A common `prepare/commit/abort` interface needs stricter application standards than ordinary cross-chain messaging.

References

[1] Astria Documentation, Astria, 2026, https://docs.astria.org/

[2] Astria GitHub Repository, Astria, 2026, https://github.com/astriaorg/astria

[3] Espresso Network Repository, Espresso Systems, 2026, https://github.com/EspressoSystems/espresso-network

[4] Espresso FAQ, Espresso Systems, 2026, https://www.espressosys.com/faq

[5] The Espresso Sequencer, Espresso Systems, 2025, https://hackmd.io/@EspressoSystems/EspressoSequencer

[6] OP Stack Interop Message Passing Overview, Optimism Docs, 2026, https://docs.optimism.io/app-developers/guides/interoperability/message-passing

[7] Radius SKDE: Enhancing Rollup Composability with Trustless Sequencing, Radius, 2024, https://ethresear.ch/t/radius-skde-enhancing-rollup-composability-with-trustless-sequencing/19185

[8] Based Espresso: ad-hoc shared sequencing for all L2s, Espresso Systems, 2024, https://hackmd.io/@EspressoSystems/BasedEspresso

[9] Astria: The Shared Sequencer Network, Astria, 2024, https://hackmd.io/@astriaorg/HJ6cCpp9T

[10] Bernstein, Hadzilacos, Goodman, Concurrency Control and Recovery in Database Systems, 1987, https://www.microsoft.com/en-us/research/publication/concurrency-control-and-recovery-in-database-systems/