For a long time, the dominant story in fintech was globalization. Visa and Mastercard expanded across markets. SWIFT connected banks across borders. E-commerce, tourism, and global trade made international payment networks more important.

The implied assumption was that local payment systems would fade. As economies became more connected, payments would converge around a few global rails.

But that is not what happened. China built Alipay, WeChat Pay, and UnionPay. India built UPI. These systems are not temporary substitutes for Visa and Mastercard. They are different answers to a more specific question:

How should money move inside a country?

The answer increasingly depends on local regulation, merchant economics, banking infrastructure, and political priorities. The world is not moving toward one global payment interface. It is splitting into regional and national financial networks.

The Convergence Assumption

Global payment networks have powerful network effects. The more merchants accept Visa and Mastercard, the more useful the cards become for consumers. The more consumers carry them, the more important they become for merchants.

SWIFT created a common messaging layer between banks. Correspondent banking helped institutions move money across jurisdictions. International travel and e-commerce raised the value of payment methods that worked everywhere.

Put together, the direction of travel seemed obvious.

One world. One set of rails. One dominant financial interface.

Regional Financial Blocs

In practice, some of the most advanced, and some of the smallest, payment markets now lean less on global card networks for daily commerce than anyone expected. The pattern repeats across very different economies:

These are not fringe systems. UPI alone clears more than 700 million transactions a day in India and carries the bulk of the country's retail digital payments. Pix reaches roughly 91% of Brazil's adult population, barely five years after the central bank launched it. At that scale, the local network is not the alternative to the card, it is the default.

This is not just a user-interface difference. It changes the economics of payments.

A merchant accepting a local QR payment or instant bank transfer may get lower fees, faster settlement, and deeper integration with domestic banks. Regulators get more visibility. Local institutions keep more of the value chain.

For a coffee shop, a taxi driver, or a small merchant, international acceptance is usually not the main problem. The main problem is accepting money cheaply, instantly, and reliably from local customers. Local payment systems are often better optimized for exactly that job.

Payment Networks Follow Politics

Payment systems do not evolve like messaging apps. Information wants to be free. It crosses borders without touching monetary policy. Money wants to be governed. A message can move anywhere. A payment cannot.

Payments are tied to taxation, banking regulation, consumer protection, sanctions, AML rules, capital controls, identity, and monetary sovereignty. So payment infrastructure naturally becomes political infrastructure.

India is a good example. UPI is not just a better payment interface. It is a domestic payment system built by NPCI, an entity regulated by the Reserve Bank of India, and it gives India more control over digital payments inside the country. Brazil's Pix follows a similar pattern. It is not only a fintech product but central bank infrastructure that changed how Brazilians move money domestically.

Russia is the most extreme case and the one that completes the picture. When Visa and Mastercard suspended operations there in 2022, cards issued in Russia stopped working abroad and foreign-issued cards stopped working inside the country. That made the political nature of global card networks impossible to ignore. But the more telling part is what came next: Russia leaned on Mir, its own card scheme, and on SPFS, its domestic alternative to SWIFT. Fragmentation, in other words, is not only something that happens to a country. It is something a country builds on purpose.

China shows the same logic from another direction. Alipay and WeChat Pay are not only payment apps. They are part of a broader domestic digital ecosystem where payments, identity, commerce, messaging, and financial services are tightly integrated.

This is why payments pull apart in the first place. A global card network optimizes for interoperability. A national payment system optimizes for domestic adoption. A wallet ecosystem optimizes for retention. A central bank optimizes for control and stability.

No single system can optimize for all of these at once. Payments fragment not because the technology is worse. They fragment because the incentives are different.

Why Visa Isn't Losing

The rise of local payment systems does not mean Visa and Mastercard are losing. It means their role is becoming more specific.

A local QR system can be better for domestic payments. But the moment a user leaves the country, the value of a globally accepted card becomes obvious. Tourists need to pay hotels, restaurants, airlines, and car-rental companies. Cross-border e-commerce needs payment methods that work across borders. Merchants who serve global customers need global acceptance. This is where Visa and Mastercard remain extremely strong.

Local payment systems shine when both sides of a transaction sit inside the same financial environment. Global card networks earn their keep when the payer and the merchant do not. So the question was never whether QR payments replace cards. The better question is where each network holds the strongest advantage.

Stablecoins as an Interoperability Layer

Fragmentation creates a new problem. If every country builds better domestic payment infrastructure, local payments improve, but moving money between these systems gets harder.

This is the interoperability problem.

Historically, the answer was correspondent banking. A bank in one country holds relationships with banks in others. Messages move through SWIFT. Funds settle through accounts, intermediaries, and balance-sheet relationships. It moves enormous volume on the order of $150 trillion a year, but it is slow, expensive, and out of reach for many corridors. For cross-border payments in particular, it can still cost $25 to $35 per transaction and take two to five days to settle.

Stablecoins introduce a different model. They do not need to replace local payment systems, and in many cases they should not. A user doesn't need to understand blockchains to receive money in a local bank account. A merchant doesn't need to think about wallets, gas fees, or private keys. Local payment systems should keep doing what they do best: distribution, identity, compliance, and last-mile access.

The more interesting role for stablecoins is settlement between systems. One local network handles the user experience on one side. Another handles it on the other. Stablecoins move the value in between. Framed this way, stablecoins are not competing with every domestic payment system. They are competing with parts of correspondent banking. They become a settlement layer for a fragmented financial world.

The numbers are still early but pointed at exactly that job. Stripped of trading and automated flows, real stablecoin payment volume was around $390 billion in 2025, more than double the year before, with the majority originating in Asia. That is tiny next to the $150 trillion that correspondent banking moves, but it is aimed squarely at the slowest, most expensive part of it.

It is worth being honest about why this has not already happened at scale. The hard part is not moving a stablecoin across a blockchain; that is the easy part. The hard part is the edges, converting local currency into a stablecoin and back again. Someone has to run those on- and off-ramps, absorb the exchange-rate spread, hold the local banking relationships, and satisfy regulators on both ends. The friction that correspondent banking carries does not vanish. It moves to the conversion points. Whether stablecoins win this role depends less on the technology and more on whether that conversion layer can be made cheap, compliant, and reliable across enough corridors.

Conclusion

Payments are not becoming one global system. They are becoming many local and regional systems connected by settlement layers.

This is not a failure of globalization. It is a more realistic architecture for money. Money is local at the edges because regulation, identity, merchants, banks, and consumers are local. Money needs to be global in the middle because people travel, migrate, trade, and send value across borders.

The winners in payments may not be the companies that convince the whole world to use one interface. They may be the companies that make many different financial networks feel like one.

The age of global payment consensus is ending. The age of financial interoperability is beginning.

World computer is a new way to describe how blockchains enable new forms of applications. Instead of developing an application and running it on your personal server, you can create and run it on a world computer. Your program will keep living even after you or your company die, as long as the world computer lives.

Blockchains are so-called world computers that provide decentralized infrastructure for decentralized applications. (More about world computer at world computer day)

While developer experience is different in crypto, developer practices are not completely new. Applications need observability tools. While it's easy to configure the observability of off-chain components, on-chain logic requires a slightly different approach.

Observability in centralized services

Observability in centralized services revolves around three core pillars: logs, metrics, and traces. Modern observability tools like Datadog APM, New Relic, Splunk, and Grafana help developers implement and manage these pillars.

• Logs: Logs record system events and errors, and provide insights for debugging and analysis. Tools like Splunk and Datadog help aggregate and search logs efficiently. (Collected by Splunk or Datadog, visualized in dashboards.)

• Metrics: Metrics track performance indicators like CPU usage and response times. Grafana and New Relic visualize these metrics for better monitoring. (Collected via New Relic or Prometheus, visualized in Grafana.)

• Traces: Traces follow the flow of requests across services, help developers detect bottlenecks, and improve performance. Tools like Datadog APM, OpenTelemetry, and Jaeger enable tracing in simple and distributed applications. (Instrumented with Datadog APM or OpenTelemetry and analyzed in Jaeger.)

  

By combining these tools, developers gain insights into application performance and security. Datadog has a portal with great resources if you want to learn more about application observability.

Observability in decentralized services

Developers of centralized applications use tools like Datadog, New Relic, or Prometheus to monitor performance across layers: application (code execution and APIs), operating system (CPU, memory, and disk I/O), and hardware (health and network performance).

In contrast, decentralized application (dApp) developers have no control over the execution environment since their code runs on the "world computer" (a virtual machine shared across network nodes). Instead, they adopt alternative strategies:

Indexing:

Since smart contract developers don't control the runtime environment and it's not trivial to directly query the world computer, they rely on indexing tools to track events, state changes, and transaction traces. Indexed data can be queried for insights, debugging, and analytics.

• Data Warehouses and Cloud Indexing Tools: Platforms like Dune index logs, metrics and traces, and decode them into human-readable format. Dune and traditional data warehouses like BigQuery or Clickhouse provide infrastructure to query indexed and decoded data.

• Local Indexing Tools: Tools like Sim, Envio and Ponder enable indexing of contract events and metrics locally. They provide faster access and greater control over data.

Simulation and Forking:

To test and debug smart contracts, developers use simulations and forks to reproduce real blockchain environments.

• Cloud-based Simulations:
  Services like tenderly make it easy to simulate contract transactions and visualize how things will play out without deploying smart contracts to the mainnet. sim and shadow take simulations further by letting users instrument their transactions for better observability.

• Local Forking and Simulation:
  Most of the EVM developers run local copies of blockchain nodes to test contract logic. Foundry is a powerful tool for local forking and simulation in EVM development. Foundry lets developers fork any EVM network and create a local replica of the blockchain state, simulate contract interactions and possible on-chain scenarios.

Logs and Traces in Blockchain Data:

In traditional systems, observability relies on logs, metrics, and traces, collected from your app, server, and infrastructure. On-chain, you don’t control the infrastructure - so you observe what the blockchain records.

Final Thoughts

Local forking and simulation are straightforward for small EVM chains, but become far more complex on high-throughput blockchains like Solana or parallelized systems. Analyzing smart contract behavior at that scale often requires navigating hundreds of terabytes of data. As blockchains evolve into true world computers, cloud-based indexing and simulation will become critical for observability.

To build reliable, scalable applications on decentralized infrastructure, developers need the same level of visibility they’ve come to expect in traditional systems - only now, it has to work on an open, shared, and immutable runtime. The world computer requires world observability.

• Hyperliquid validated the app-chain thesis in an unexpected way.

• Most of the newly launched blockchains are VC funds in disguise.

Application-specific chains are born from the idea that blockspace is purchased by applications operating on a particular chain or layer. On shared blockchains, applications compete for blockspace and pay gas fees alongside many other applications, leading to significant congestion and high competition. This congestion drives fees up, and the resulting cost is passed on to end-users. In contrast, on an application-specific chain, the application can better manage the fees imposed on end-users and control congestion during volatile periods. (Read this blog for more details)

Blockchain congestion is a serious challenge for perpetual exchanges, which depend on fast and reliable transactions for trade settlement, liquidations, and funding rate updates. Application-specific chains mitigate these issues by offering dedicated blockspace. They also have more control over transaction ordering, which can affect user experience and reduce MEV leakage.

Example: Taylor Swift concert tickets were sold for $20k on Ticketswap (Secondary Market), which means that Taylor Swift left a lot of money on the table by not selling her tickets for a higher price. Who should claim the extra money?

1. A person who resold the ticket on Ticketswap (searcher)

2. Ticketswap - resale platform (application)

3. Taylor Swift (LPs or users that made the trade)

If resellers need to pay high-priority fees to sell their tickets for a higher price then all money goes to Ticketswap, which many see unfair. Maybe Taylor should get that money? What about the person who made the sale? 

In the current blockchain architecture, most of the profit earned from the ticket resale is not going to Taylor, reseller, or Ticketswap. All the profit goes to an infrastructure provider (e.g., AWS) hosting Ticketswap because the infrastructure provider (sequencer) decides which user buys the desired ticket. Traditional appplications have control over the transaction ordering, but in most crypto applications, the underlying blockchain or rollup sequencer decides the execution order in the hosted applications. Building on a platform fully controlled by the application makes more sense for gaining control over transaction ordering.

Hyperliquid is a perfect example of an application that controls its infrastructure. Instead of relying on a shared blockchain, Hyperliquid can manage congestion and has ability to apply sequencing rules. Hyperliquid prioritizes, cancels and makers over takers by running cancels and post-only orders first. (0xRainandCoffee talks about more sequencing rules in this post).

Aevo is another decentralized derivatives exchange developed on it's own infrastructure. Aevo's app-chain is built using a more familiar OP-stack technology. According to L2beat, almost 40% of all L2-chains are OP-stack. Aevo validated the app-chain thesis using a more common blockchain technology. In OP-stack chains, a single sequencer orders transactions and produces blocks. Centralized sequencer concentrates control, raising questions about decentralization and trust assumptions. Despite these trade-offs, OP Stack’s approach to rollup construction is accepted as a compelling balance of scalability and speed for developers building application-specific and general-purpose rollups.

Many people point out that Hyperliquid's blockchain is "run by four validators," which makes it less decentralized than other shared blockchains. Hyperliquid is compared to a centralized exchange because of this controversy. But in the end, traders use the product with a superior experience built on an app-chain.

The benefits of managing dedicated infrastructure for blockchain applications are clear. Why, then, aren’t more projects pursuing this path? Instead, we see a large number of general-purpose blockchains launching each month.

The feedback loop for the development of applications is short. Developers can quickly iterate and see if their ideas work; if they don't, they can fail fast. Creating an ecosystem and investing in other applications carries less risk. If one application in your portfolio didn't work, you can still count on others. And if you started as an application-chain, why stop with one application when you can host more and collect fees from them.

If we look at most of the newly launched blockchains from this prism, evaluating them as Venture Funds makes more sense. Similar to Venture Capitalists, blockchains host hackathons, pitch nights, and networking events for founders in their ecosystems. Different blockchains have their own advantages

• Technological edge: Monad, MegaEth, Scroll

• Geographical edge: Kaia, Ton, Base, Tron

• Brand edge: Soneium, ApeChain

• Distribution edge: Base, Ink, Ton

According to the Forbes article, ~2% of VCs earn 95% of VC profits, and 10% are truly profitable, while many report phantom profits that don’t benefit their investors. According to the Dune Index the top 6 blockchains account for ~94% of blockchain adoption (as of 29 December 2024).

While direct comparisons between VC funds and blockchains are imperfect, newly launched chains are likely to follow similar rules. Some will succeed with substantial portfolios, while others may fail to raise their next round.

Projects like Hyperliquid and Aevo demonstrated the benefits of controlling dedicated blockchains and building application-specific infrastructure. With abundant blockspace and strong capital inflows into blockchain ecosystems, we’re seeing a shift where developers can leverage modular infrastructure for more use cases. This trend creates an ideal environment for developers, who now have more resources and flexibility to build blockchain applications.

Global consensus is a critical feature of many blockchain architectures. It ensures the entire network agrees on the validity of transactions and the state of the blockchain. However, this mechanism has become one of the primary bottlenecks in scaling blockchains and expanding the on-chain economy. The reliance on global consensus is a bottleneck because not every transaction requires the entire network’s validation. For instance, the whole world doesn’t need to know that you bought a coffee at your local cafe. As blockchain networks grow, relying on a single global consensus across all applications becomes resource-intensive and time-consuming.

Various teams across blockchain space are working on distinct solutions, each focusing on different parts of the blockchain infrastructure stack. All of these efforts form a movement against global consensus. This post is how I see different pieces coming together to scale the on-chain economy.

Rollups are scaling solutions that process transactions off-chain and then submit the transaction data to the main blockchain in a compressed format. This reduces the load on the main blockchain while maintaining security through the global consensus of the base layer. There are many different architectures developed by various teams (e.g., Op Stack, ZkVM, MoveVM, SVM etc.).

Currently, it is hard for a single blockchain to support all on-chain activity; that is one of the reasons users are fragmented across different rollups and chains. While it is just a matter of time until a particular blockchain or rollup will solve scaling challenges and support one gigagas transactions, the number of new rollups and blockchains will not go to zero. Some rollups may prioritize faster transaction throughput by sacrificing certain levels of decentralization, while others may focus on privacy or specific use cases like gaming or finance. Rollups will remain as important scaling solutions and cultural extensions of Ethereum (and other blockchains) as various communities and use cases will require customized solutions.

In a multi-chain world intents represent a shift in how users interact with blockchains. They enable expression of high-level goals or "intents" rather than specifying each transaction step. This approach decouples user actions from direct transaction execution. Intents are similar to how databases optimize query execution, where users define the desired outcome, and the system plans the most efficient path to achieve it. In the same way that a database determines the best way to retrieve data, specialized actors in the blockchain ecosystem analyze the intent and execute the optimal series of transactions (e.g., swap into WETH, then bridge to Blockchain X using Bridge Y), reducing the need to wait for a global consensus on each step.

Different projects like Reservoir, Gelato or Safe are developing infrastructure to enable intents and seamless cross-chain interactions. These tools allow users to define their desired outcomes and have the network of decentralized actors fulfill them automatically. Users can specify high-level intents like "swap a token", "manage liquidation", "pay multiple employees" or "distribute tokens", and the network handles the execution when the conditions are met.

Account abstraction plays a crucial role in intent-based infrastructure by decoupling the process of initiating transactions from the rigid structure of crypto wallets. Interfaces like ERC-4337 and ERC-5189 are examples of standards that enable account abstraction. With abstraction, wallets no longer require direct user signatures for each transaction; instead, they can delegate execution to other parties, such as solvers, relayers, or fillers, who can optimize paths and manage gas costs.

Solvers play a central role in intent-based infrastructure by optimizing and executing user-defined intents. These specialized actors analyze the high-level goals set by users, such as moving assets across chains, and determine the most efficient series of steps to achieve them. Solvers compete or collaborate to find the optimal path, considering gas costs, liquidity, and execution speed.

Solvers are crucial not only for optimizing and executing intents but also for providing liquidity. By aggregating and routing transactions, solvers ensure sufficient liquidity is available for various operations, such as token swaps or cross-chain transfers. Their role in the network includes sourcing liquidity from different pools, exchanges, or protocols and facilitating efficient trade execution. Liquidity provision is essential for maintaining smooth and effective transaction flows in DeFi where high liquidity is necessary to execute large and complex transactions.

Solvers are often seen as bad actors that only bring negative externalities to blockchains, because they can also extract MEV. Still, they also help stabilize the market, reduce slippage, and enhance the overall efficiency of blockchain operations.

Application-specific sequencing refers to the concept of having custom transaction ordering mechanisms for different applications. You can check my post to learn more about transaction sequencing in general. Instead of relying on a single, global transaction sequence, individual applications can adopt their own sequencing methods that optimize for their unique needs. This differs from the current state in the Ethereum ecosystem, where Application Sequencing is coupled with Consensus-level Sequencing. Different blockchain infrastructure stacks provide different trade-offs for transaction sequencing.

Higher reliance on solvers for on-chain interactions will require a more robust sequencing framework to prevent the leaking of value created by users to networks of solvers.

Credible account is a term introduced by project OneBalance.

"Each account can be thought of as a rollup which allows users to conveniently manage their state and reliably request state transitions on any chain. This is achieved through the introduction of two key concepts:"

1. Accounts on credible commitment machines

2. Resource locks

The framework is developed to enable seamless user experience and abstract complexities of cross-chain transactions. Instead of managing many different wallets across different chains, one credible account simplifies interaction with on-chain applications.

There will be many different projects solving the problem of multi-chain user experience in the future. It is not clear yet if OneBalance is the best solution, but it is clear that moving from protocol-centric world to account-centric world (one account for all chains) is a critical piece of the movement against global consensus.

The global consensus bottleneck is a fundamental challenge in the blockchain ecosystem, but solutions like rollups enable more scalable and efficient systems. Intents, credible accounts, and application-specific sequencing are crucial in creating a seamless user experience in a multi-chain world.

Intents allow users to interact with blockchains more intuitively by expressing high-level goals rather than specific transactions. Solvers play a vital role by providing liquidity, creating execution paths for intents, and minimizing slippage. Credible accounts simplify account management across many chains, while application-specific sequencing enables dApps to tailor transaction ordering to their needs. Together, these pieces of infrastructure form a movement against global consensus. They reduce complexity, enhance efficiency, and enable a more user-friendly and accessible on-chain economy.

• "The whole world doesn't need to know that you bought coffee at your local restaurant" is a quote from OneBalance introduction.

• The quote "Movement agains global consensus" is inspired by this tweet.

The first part of the post describes the taxonomy of fairness-aware sequencing mechanisms, and the last section discusses recent work on fair ordering using verifiable sequencing rules.

This taxonomy was inspired by a Flashbots forum post from Quintus, where he classifies sequencing rules based on their runtime complexity. Transaction sequencing by block builders can be described as a Knapsack problem. Mikerah from Hashclock has a good explanation of this problem in their post.
Rational block builders solve an optimization problem to maximize their profit by constructing the most valuable block. We cannot expect builders to execute rules which cannot be solved in polynomial time. Hence, the taxonomy from Quintus explores this topic and classifies the rules to underline their feasibility.

Most of the discussions around sequencing rules come from the problem of MEV and trading on decentralized exchanges. Rational block builders will always manipulate ordering to maximize profit. This implies that more sophisticated market participants will keep extracting profit from less involved traders. More research is conducted on returning MEV back to users and the notion of trade fairness. Flashbots is transitioning its focus from solely enhancing validator profits towards returning MEV rebates for transaction creators using MEV-share.

This paper started a new wave of discussions by presenting a new sequencing mechanism (Verifiable Greedy Sequencing Rule). While it is impossible to find a sequencing rule that would prevent block builders from obtaining risk-free profit, verifiable sequencing rules provide provable execution price guarantees.

The verifiable sequencing rule is not the first attempt to enshrine trade execution fairness in Ethereum. Aequitas and Themis are the result of research on order-fair consensus in permissionless setting. Taxonomy 2.0 is an attempt to summarize the state of knowledge around sequencing rules and evaluate sequencing mechanisms beyond verifiable sequencing rules.

Fairness in EVM blockchains can be enforced at a consensus-level. There is research that distinguishes order fairness as the third consensus property, along with consistency and liveness. Aequitas, Wendy, Quick, and Themis are examples of algorithms in this group.

Fairness is defined by the arrival time of transactions and does not involve trade fairness. Receive-order fairness, block-order fairness, and differential fairness tighten the formal definition of fairness. One of the main reasons we need to introduce more formal definitions is that different blocks have different views of the mempool. Determining which transaction came first in a distributed environment is more complex.

One interesting finding in consensus-level research is the Condorcet paradox, which parallels fair-ordering and majority voting theory. "Condorcet paradox (or voting paradox) is a situation where majority rule behaves in a way that is self-contradictory." Simply put, it is possible to create a situation where nodes cannot decide which transaction should go first and deterministically construct a block using consensus-level algorithm. This parallel can also be applied to verifiable sequencing rules (more details in the last section).

Many rollups depend on centralized sequencers. These sequencers are responsible for transaction ordering. Most of the current research evaluates sequencing rules on this level of the application stack. Since this layer is often centralized, sequencers can use a first come first serve (FCFS) policy similar to centralized exchanges. This strategy frequently generates latency competition, where parties invest in latency reduction to be competitive in arbitrage trading.

First come first serve is not the only algorithm used by sequencers. This paper compiled a list of six ordering mechanisms applied in practice.

• Priority gas ordering mechanism: Sequencers solve the Knapsack problem using approximation algorithms and ordering public mempool transactions by gas price.

• Flashbots mechanism: Players participate in the transaction ordering mechanism by sending transactions through a private channel. Flashbots relayer builds the block by solving the Knapsack problem and including public and private candidate pool transactions.

• Random ordering mechanism: Transactions are included in a block randomly. The inclusion rate follows a uniform distribution.

• First input first output mechanism: Transactions are ordered using a local or pseudo-global timestamp.

• Dictatorship/Permissioned mechanism: The sequencer applies custom ordering rules. The rules can include arbitrary logic.

• Metadata mechanism: transactions are ordered by hashes using a generated field nonce.

Each ordering mechanism has its own effect on the validator's profit or trade fairness. Mechanisms such as priority gas ordering or flashbots auctions are designed to maximize validators' profits. The verifiable greedy rule can ensure that a given transaction receives an execution price as good as if this transaction were the only transaction in the block.

With many different rules, centralized sequencers can still violate mev-resistant properties such as timestamp-integrity, mempool privacy and extract MEV from protocols.

Dapps can introduce application-specific rules to ensure fair execution of transactions. Most of the trades on Ethereum are executed on AMMs where application-level transaction ordering is tightly connected with consensus-level and sequencer-level ordering rules. However, there are different attempts to influence transaction ordering on the application level.

Gas auctions were the primary mechanism for determining transaction ordering in blocks for a long time. Gas auctions involve a bidding process where users compete to process their transactions first. Users submit bids indicating the gas price they are willing to pay to have their transactions processed. Transactions with higher gas prices are prioritized by miners and included in blocks more quickly.

An Auction-Managed Automated Market Maker is the new concept introduced in this paper. Authors propose a new way "to minimize liquidity provider losses to arbitrageurs while maximizing fee revenue from retail flow." The new mechanism adopts a two-stage approach where

1. "Potential managers bid for the right to set and earn the trading fee in a future block."

2. "Liquidity providers respond by adding or removing liquidity."

The new mechanism directly affects sequencing dynamics by introducing a notion of a "pool manager" who has an "exclusive right to capture some arbitrage profit from a pool." This benefit gives them an advantage in the block builder auctions.

Application developers don't have enough levers to enforce application-level transaction ordering. Auction-Managed Automated Market Maker is one of the recent examples showing promises in this research line.

Off-chain application-level sequencing algorithms abstract the optimal ordering of transactions away from the blockchain's constrained computational environment. Instead of solving complex optimization problems themselves, block builders can outsource solving NP-complete ordering problems to off-chain solvers.

In a batch auction, trade orders are grouped into "batches" and then offered for bidding to solvers who compete to find the most efficient execution method. The benefit of a batch auction is the ability to execute more sophisticated optimization algorithms to find the most optimal price for the trade. Off-chain optimizers do not have the time-sensitive requirements of block builders and have access to better computational resources to run optimization algorithms. CowSwap, 1inch fusion, and UniswapX are all examples of batch auctions.

Priority queues organize transactions based on predefined criteria, such as gas price, transaction size, or urgency. Priority queues are also a way to handle "all the bundles sequencers receive, and choosing how to feed them to the builder." Titan employs four different queues that handle transactions with varying priority levels.

Priority queues are part of sequencer-level ordering mechanisms. I have deliberately included them in the application-level group to underline that the lines between sequencer logic and application logic are blurred in decentralized applications.

Verifiable sequencing rules became a go-to solution in many sequencing discussions. Provable execution guarantees are a significant improvement for sequencer design. One way to execute this rule is to apply it separately for each AMM pool. Swaps in each AMM pool can be ordered among themselves using the greedy verifiable rule. This technique prevents the sandwiching of transactions executed in each specific AMM pool.

We need to note that this rule does not work when transactions contain several swaps. It is possible to construct a Condorcet cycle by including conflicting swaps in the same transaction. Figure 3 shows a simplified example where there is no clear way to decide if txn 1 should be followed by txn 2 or txn 3. Based on the dex.trades history from the first four months of 2024 on Dune, 18.7% of dex trades are placed in multi-swap transactions. While they do not necessarily cause a Condorcet paradox, sequencers need to find different ways to provide mev-resistant guarantees.

I wrote this post while I was writing my thesis on sequencing rules, where I tried to evaluate the effect of different sequencing rules on trade execution fairness. This taxonomy was my attempt to understand sequencing rules before trying to simulate any of them. Please, leave your comments or share different examples.