On State Locks, State Deltas, and What Everyone Is Getting Wrong About Application-Specific Sequencing

A Broad Explanation of MEV and the Value of Accessing State

Any state with utility / value that decreases upon each sequential access goes through the MEV (or PGA) crucible, where it's priced relative to what others are willing to pay for it.

MEV relays reduce the externalities of the competition (e.g., spam) by increasing the predictability of sequencing. This consequently reduces the expectation of profit from probabilistic approaches (e.g., spam again) to accessing state while it's still valuable.

Application-Specific Sequencing

Application-specific sequencing, however, is different. While MEV relays reduce the utility of redundant attempts to access contested state, ASS has the potential to make state non-contested. While this can be achieved with state locks (yuck), the more interesting pattern is to sequence state deltas rather than state absolutes.

Sequencing state deltas can be done without disrupting composability by inverting the typical model and applying a lock on the state delta (typically a transaction) rather than the state itself.

A Hypothetical Example: State vs. State Delta Locks

Envision state with a current value of 100. Imagine that this state is inside a smart contract with byte code specifying that if its value reaches 150 or higher, the next actor to interact with it will be paid $100.

• State Lock: Blocks all actors who aren't on a "whitelist" from changing the value. This means whoever gets the $100 is on the whitelist, but it also disrupts composability since only those on the whitelist can increase the state's value from 100 → 150. This is what people mean when they say that state locks disrupt composability.
• State Delta Lock: Locks multiple accesses together so that if one access happens, another must also happen. Envision a transaction that increases the value of the state by +60. The state delta lock would take that transaction and then "lock" it together with another transaction that withdraws the $100. The state delta lock ensures that if the $100 withdrawal doesn't happen then neither does the +60 increase to state.

By locking the state delta rather than the state itself, composability is preserved. Other entities can still access the state, potentially with their own state delta locks. In the delta model, we are effectively saying that "it isn't the state itself that's valuable, but rather the state delta, without which the $100 withdrawal wouldn't be possible.

Practical Applications of State Delta Locks

What's interesting is that state delta locks typically happen at an entirely different part of the "transaction supply chain". Unlike absolute state locks, which are hardcoded into smart contracts, state delta locks capture / internalize value by atomically bundling transactions. This usually happens at the frontend or wallet level of the stack and therefore does not require any updates to the app's or wallet's smart contract.

Challenges and Solutions

One challenge with state delta locks is that the actual value of the state can change, which may reduce the value of our state delta lock. For instance, if at the time our transaction lands the state's value is 100 then our +60 will put it over the 150 threshold and we'll be rewarded with $100, but if for some reason the state's value is only 80 then our +60 will put the post-tx state at 140 and the $100 withdrawal we locked with the state delta will fail.

This may seem like a tricky problem, but oftentimes it can be solved with some simple smart contract logic.

FastLane's Atlas, which sequences and bundles metatransactions from different actors into a single atomic transaction, introduces two tools to address this issue:

1. Execution Hooks: Smart contract logic that runs before, after, or between bundled metatransactions (aka operations), validating or adjusting the absolute state - or potentially changes it - prior to executing metatransactions. Continuing the example above, this allows skipping the $100 withdrawal metatransaction if the state's value is less than 150, since we know it will fail. In practice, this prevents wasted gas on failed MEV-collecting attempts without degrading the user experience or undoing the execution success of the actor responsible for the initial state delta.
2. Redundant Solutions: If one solution fails (i.e., doesn’t pay the app its bid), the entrypoint contract reverts that metatransaction and executes the next-highest bidding solution, iterating until a solution succeeds. In practice, if a solver makes an MEV bid higher than the profit they actually receive, they can safely revert their metatransaction without impacting the execution of the actor responsible for the state delta—other solvers' metatransactions will still be executed.

Use Cases

State delta locks unlock potential across various domains:

• OEV (Oracle Extractable Value)
• MEV Refunds
• RFQs
• Gas Abstraction
• Generalized Intents (Note that although intents can be defined arbitrarily, state delta locks typically hinder the capacity for one intent to be used as a solution for another intent)

Benefits

• Independent of MEV Supply Chain Actors: State delta locks work and internalize value within a single transaction, eliminating the need for builders, validators, or MEV transaction relays. Since sequencing happens entirely within a single transaction, no transaction-level sequencing guarantees are required. Additionally, censoring the value capture inherently censors the value creation, making censorship unprofitable.
• EVM Compatibility: This sequencing mechanism works on all EVM chains because, from the perspective of the sequencer, builder, or validator, it appears as a single transaction. Atlas is currently live on Base, Arbitrum, BNB, and Polygon, where it is being used for MEV Refunds, OEV, RFQs, and other use cases.
• Permissionless Solving: By iterating over solutions and requiring solvers to pay their metatransaction's share of the total transaction's gas cost, solving remains permissionless.
• Eliminates Probabilistic Spam: Intra-transaction state delta locks effectively address the limitations of MEV relays in reducing spam. While MEV relays reduce spam targeting known, valuable state, they struggle with spam targeting state created by probabilistic (may exist or sequence unknown) deltas. Intra-transaction state delta locks are an effective way of safely disincentivizing probabalistic spam without needing to trust unaligned (or nonexistent for most L2s) actors in the MEV supply chain.

Limitations

• Not Compatible with Solana: The SVM doesn’t allow partial reverts, making state delta locks unusable.
• Inapplicable to Off-Chain MEV: CeFi-DeFi arbitrage, for example, involves deltas on a CEX rather than on-chain.
• No Free Reverts: Failed metatransactions still incur gas costs. (Because of the lack of free reverts and the fact that it is the only MEV-refunding / intent solution today that works for apps without the participation of other parts of the MEV supply chain such as a block builder or sequencer, Atlas is typically marketed to apps on L2s and high-throughput L1s)

A Disruptive Paradigm

This approach likely doesn’t match the typical mental image that many have of an application-specific sequencer, despite being the only one in production today. Its non-conformity to the status quo is precisely what makes it so disruptive in the infrastructure-dominated MEV supply chain. State delta locks shift power from relays, block builders, and other infrastructure to frontend and wallet-level entities, aligning incentives with users where it belongs—all without disrupting composability.

Already live on Base, Arbitrum, BNB, Polygon, and Monad devnet, this mechanism supports use cases such as MEV refunds, OEV, and RFQs. As teams begin to explore this paradigm, its potential to reshape DEXs, lending markets, prover markets, token sniping bots, bridges, gaming, and more is becoming increasingly clear.

Unlike many "hot narratives" that fade anticlimactically, application-specific sequencing is real, available today, and surprisingly easy to integrate. We've only scratched the surface of what’s possible.