Inside Order Flow Auctions
Intents, Batches and Blocks
tl;dr
Order flow auctions (OFAs) are a new evolution in decentralized finance that aim to make trading more efficient and fair. OFAs work by aggregating multiple users' transactions into batches optimized and settled by third parties.
This batch auction process provides benefits like mitigating miner extractable value (MEV), improving price discovery, lowering fees, and unlocking fragmented liquidity. Different types of OFAs focus on goals like price optimization (RFQ auctions), routing efficiency (frequent batch auctions), and block space usage (block aggregators).
However, effectively delivering these outcomes depends heavily on how OFAs are designed. Pivotal decisions around permissioning, order types, data transparency, and incentive structures shape capabilities and trade-offs. A key philosophical choice is transactions versus flexible intents.
OFAs face challenges in preventing manipulation, given speed advantages and misaligned incentives. Thoughtful mechanism design considering game theory is critical. Examples like CowSwap and MEV-Blocker demonstrate OFAs in action.
Looking ahead, well-constructed OFAs could unlock substantial efficiency and composability improvements in DeFi trading. However, balancing factors like centralization risks, strategic behavior, and equitable access will be crucial to realizing benefits.
By aggregating and optimizing orders in decentralized batch auctions, OFAs have transformative yet nuanced potential to overcome inefficiencies in decentralized exchange. However, their complex design considerations must be holistically addressed.
We discuss all the above in detail.
Order flow auctions (OFAs) have rapidly gained prominence as a critical evolution in DeFi and on-chain trading. By aggregating and optimizing multiple users' transactions or orders together into batches, OFAs aim to reduce wasted value, minimize fees, mitigate predatory behavior, and improve price discovery.
However, effectively delivering these outcomes depends heavily on the specific mechanics and incentive designs encoded into OFA architectures. Given
the acceleration of adoption,
the complexity of configurations,
the lack of standards and
the transformative potential of OFAs,
it is crucial we openly discuss considerations around their technical design and embedded economic philosophies.
Analyzing key decisions like order types, optimization goals, and batching parameters, among many other factors, provides insights into the capabilities, tradeoffs, and strategic priorities of different OFA frameworks.
What are Order Flow Auctions?
Order flow auctions are mechanisms that aggregate multiple users' orders or transactions together into batches to be executed and settled by third parties. The goal is to return more value to the users compared to having their orders executed individually throughout the transaction supply chain, where value often gets leaked.
In an order flow auction, users' orders are gathered first before being sent to an auctioneer. The auctioneer puts all the orders into a single auction batch. Information about the batch of orders is then shared with bidders, who are third parties that want to execute the transactions. The bidders proceed to optimize the execution of the entire batch of transactions in the auction based on predefined criteria set by the auction mechanism. For example, the criteria could be to maximize miner extractable value or minimize costs for users.
After optimizing the batch, the bidders submit bids for executing the transaction batch to the auctioneer. The auctioneer reviews all bids and selects a winning bid based on the optimization criteria. Finally, the winning bid is executed, meaning the entire batch of transactions is pushed on-chain in an optimized form that returns more value to users.
The key benefit of order flow auctions is reducing the leakage of value that normally occurs when transactions are executed individually. By batching many transactions together, there is more potential to optimize execution in ways that return value to users that they would have lost if their transactions were settled individually. For example, transactions can be reordered to reduce sandwich attacks, avoid frontrunning, or route trades through lower fee routes.
Overall, order flow auctions introduce a competitive bidding process for transaction execution. This helps discover better pricing and execution strategies that benefit end users. Order flow auctions are an evolution in decentralized finance transaction settlement that aims to reduce wasted value and improve outcomes for users.
What are the different types of OFAs?
Generalized OFAs
Generalized order flow auctions (OFAs) are designed to handle arbitrary transactions beyond just swaps. By supporting a wider range of transactions, they have a much larger addressable market. These types of OFAs aim to provide flexibility rather than optimizing for a particular use case.
For example, a platform like Suave allows developers to define customizable auction rules using smart contracts. This means the rules can be tailored to support transactions across different domains, not just within decentralized finance. The goal is to create an open and permissionless platform where anyone can spin up an OFA optimized for their particular needs.
By supporting generalized computations, these types of OFAs can interconnect transactions across different blockchains and protocols. However, enabling such broad applicability comes at the cost of efficiency. Generalized systems require complex designs to account for many edge cases and transaction types.
Specialized OFAs
In contrast, specialized OFAs optimize for a narrow target domain like decentralized exchanges. By tailoring the design for a specific use case like swaps, these systems can achieve much higher efficiency and performance. However, their addressable market is smaller since they only focus on one application area.
For example, Uniswap X oversees OFAs specialized for swaps on Uniswap's decentralized exchange. All the parameters are finely tuned for the swapping use case. This allows Uniswap X to provide the best possible execution quality and price improvement specifically for trades on Uniswap.
Specialized OFAs can leverage off-chain components customized to their domain. They do not need as much on-chain flexibility since they only have to support a limited transaction type. The tradeoff is these systems cannot easily interconnect or support other blockchain applications.
In summary, generalized OFAs prioritize flexibility, while specialized OFAs prioritize optimization for their target domain. There are clear tradeoffs between the breadth of applicability and the depth of optimization.
Further, there are three specific types of OFAs:
#1: RFQ (request for quote) auctions
RFQ auctions are a type of order flow auction optimized for price discovery. In an RFQ auction, a user requests quotes for executing a specific trade, such as swapping token A for token B. This request is sent to various liquidity providers who respond with their best price quote for fulfilling that trade.
The providers submitting quotes have access to aggregated liquidity pools and inventory not available on automated market makers. This allows them to offer improved pricing or larger sizes compared to publicly listed prices. The user collects these quotes and can select the best one for trade execution.
RFQ auctions incentivize liquidity providers to reveal their best possible prices in order to win the trade. The competition pushes prices toward the marginal cost of execution. This price discovery results in better pricing and slippage for trades compared to accepting listed prices on AMMs.
RFQ auctions are best suited for large size trades where quoting liquidity can unlock better pricing than atomically executing against an AMM. They are also useful for discovering prices in fragmented or illiquid markets.
For example, a trader wanting to swap 1M USDC for WBTC could submit an RFQ to a variety of liquidity providers. Instead of paying 1%+ slippage at listed prices, the bids may come back at 0.5% or less. The trader chooses the best quote for optimal price improvement.
While RFQ auctions are focused on price discovery, additional transaction details could be provided to allow liquidity providers to optimize other parameters beyond just pricing. For example, information about desired timing, acceptable routes, or total costs could enable bidders to craft quotes personalized for those needs rather than just the best price in isolation.
There is also an opportunity to chain or cascade RFQ auctions from provider to provider. The initial requester may not know the full set of liquidity providers to reach the deepest pools. Allowing winning bidders to run their own RFQ with other providers could tap into further liquidity through a multi-hop process.
RFQ auctions gain even more power when bundled with other transaction types in a batch auction. Rather than just individual trades, aggregating transactions into batches unlocks cross-asset arbitrage and other optimization strategies that can mutually improve pricing across all trades in the basket.
Here is a step-by-step process of how RFQ auctions work:
Step 1: The user generates a request for quote (RFQ) specifying their desired trade details. This includes information like the source asset, destination asset, trade size, and optional parameters like timing.
Arhat wants to trade 10 ETH for USDC. He generates an RFQ specifying:
Source asset: 10 ETH
Destination asset: USDC
Trade size: 10 ETH
Timing requirement: Execution within 5 minutes
Step 2: The RFQ is broadcast to a selected set of liquidity providers who have indicated they can provide quotes for that asset pair.
The RFQ is broadcast to liquidity providers like Coinbase, Binance, Uniswap, and others who provide ETH/USDC quotes.
Step 3: Each liquidity provider analyzes the RFQ trade details along with their current inventory, liquidity pools, and market conditions. Based on their capabilities, they provide a binding quote with prices and/or fees for executing that trade.
Provider A checks its books and sees it can currently buy ETH at $1800/ETH. It quotes Arhat a rate of 18,090 USDC for 10 ETH (charging 0.5% fee).
Provider B has a better ETH inventory and quotes 18,036 USDC for the 100 ETH (0.2% fee).
Step 4: The user collects and compares quotes from all respondents. They evaluate dimensions like price, slippage, fees, timing, and other terms.
Step 5: The user selects the best overall quote that optimizes their goals. They confirm acceptance of that quote with the liquidity provider.
Step 6: The liquidity provider executes the trade on behalf of the user per details in the accepted quote. The assets are exchanged at the quoted prices.
Step 7: Settlement occurs, with the user receiving their swapped assets. The liquidity provider earns a profit on any bid-ask spread above their costs.
Step 8: Metrics like number of respondents, spread of quotes, and winning price is recorded to inform future auctions and provider selection.
This RFQ auction process incentivizes liquidity providers to reveal competitive prices to win the trade. Users get better pricing by aggregating quotes rather than taking listed prices. The auction is repeated for each new RFQ generated by users.
#2: Frequent Batch Auctions
Frequent batch auctions are another type of order flow auction that aggregate and settle multiple transactions in batches at regular intervals. They combine price discovery with optimized trade execution.
In a frequent batch auction, user transactions are collected over a short time window rather than settled immediately. For example, trades may be accumulated over 30-60 seconds. This aggregation of transactions creates an opaque batch or "dark pool".
Bidders are then allowed to analyze the batch of transactions and respond with an optimized strategy for executing the entire batch as efficiently as possible. This could involve identifying mutually beneficial trades to route through each other rather than to an AMM.
After bids are received, the auction operator batches the transactions and executes them on-chain per the winning strategy. All trades in the batch receive the same pricing and routing treatment.
By aggregating many trades into regular batches and optimizing across them, frequent batch auctions allow matches between trades that reduce fees and slippage. Liquidity demand is also consolidated into discrete blocks, smoothing out spikes.
For example, a DEX could run frequent batch auctions every minute, settling all trades in that window optimally. This provides better pricing and user experience than having users transact individually on-chain or via an AMM.
Frequent batch auctions require care around timing windows, matching logic, and upfront commitment from users to the batch outcome. But they unlock significant efficiencies at scale while retaining decentralized settlement.
Here is a step-by-step process of how frequent batch auctions work:
Step 1: A time window for the batch auction is established, such as 30-60 seconds. As users place orders, they are accumulated into an opaque batch rather than settled immediately.
DEX D runs batch auctions every 1 minute. At 12:00 PM, a new batch opens.
Arhat placed an order to buy 10 ETH with USDC. Ryan wants to sell 5 ETH for DAI. The orders are pooled in the open batch.
Step 2: When the time window closes, the batch of transactions is finalized, and a snapshot is taken. No new orders are added. The details of the transaction batch are shared with participating liquidity providers and/or arbitrageurs.
The batch contains:
Arhat: Buy 10 ETH with USDC
Ryan: Sell 5 ETH for DAI
Step 3: These bidders analyze the aggregated orders in the batch to identify efficient execution strategies across the set as a whole. Bidders return bids with transaction sets that optimize parameters like pricing, fees, or slippage for the batch.
Liquidity providers analyze the batch and see Arhat’s USDC can route to Ryan.
Provider P submits a bid to:
Sell 5 ETH from Ryan to Arhat for USDC
Ryan now has USDC
Buy 5 ETH for Arhat from AMM with his remaining USDC
Arhat receives 10 ETH total
Step 4: The auction operator selects the optimal bid that maximizes the defined goals. This becomes the transaction set that will execute. All transactions are committed to the selected set. The orders cannot be modified or withdrawn.
Step 5: The auction operator submits the transaction set as one atomic bundle to the blockchain for decentralized execution. Transactions in the batch all receive the same pricing and execution based on the cleared auction results.
DEX D selects P’s bid for maximum efficiency
Orders executed per P’s strategy:
5 ETH sold from Ryan to Arhat for USDC
Ryan now has USDC
5 ETH bought from AMM for Arhat with remaining USDC
Arhat receives full 10 ETH order
Batch settled on-chain
Step 6: After settlement, metrics are computed to evaluate auction performance and inform future optimization. The process restarts with a new empty batch and time window.
This frequent batching concentrates orders into discrete bundles to unlock optimizations across transactions rather than settling them independently. The periodic mechanisms drive efficient outcomes.
#3: Block Space Aggregator Auctions
Block space aggregator auctions focus on optimizing the utilization of scarce block space by consolidating transactions from multiple users into batches. The goal is to maximize efficiency and minimize wasted space and fees.
In a block space aggregator auction, transactions are accumulated from users over a time window and bundled together. Bidders submit optimized transaction orderings and strategies for executing the batch in a way that frees up block space for additional transactions.
For example, transactions may be reordered to avoid propagating contract state that enables follow-on transactions to reuse this data. Transactions can also be layered to replace sequences from multiple users with just one transaction.
By tightly packing transactions, these auctions increase the effective capacity of block space. More transactions per block mean lower fees per transaction as fixed block rewards get distributed over more activity.
Any profits earned from optimizing the transactions are shared back with the users who supplied the transactions, unlike traditional MEV extraction, which retains profits.
For instance, a block space aggregator could batch transactions from a dApp to roll up transfers into a single balance update. This saves space while allowing some profits to flow back to the dApp's users.
The key challenges include having sufficient transaction volume to enable optimization, fairly compensating users, and minimizing failed transactions due to interdependence within batches.
But judiciously applied, block space aggregators can create more efficient use of limited block space and bandwidth - benefitting dApps and users through lower fees and better usage of the blockchain.
Here is a step-by-step process of how block space aggregator auctions work:
Step 1: A block space aggregator collects transactions from various users and applications into a pending batch over a defined time period. When the batch window closes, the transaction data is finalized, and a snapshot is taken of all transactions.
Aggregator A collects transactions over 15 seconds into Batch 1.
Batch 1 contains:
Arhat sending 5 ETH to Ryan
Ryan sending 3 ETH to Charlie
Charlie sending 1 ETH to Dan
Step 2: The details of the batch are shared with bidding miners/validators and/or arbitrageurs who will assemble and submit block proposals. These bidders analyze the transaction data to identify strategies for optimizing usage of block space. This includes reordering, layering transactions, identifying redundancies, etc. Bidders submit block proposals with a transaction ordering and execution strategy that maximizes efficiency for the given batch. This creates more available space.
At 15 seconds, Batch 1 is finalized and sent to miner bidders.
Miner M analyzes the batch and sees the transactions can be layered to save space:
M batches Arhat's payment to Ryan with Ryan's payment to Charlie into one txn.
Step 3: The block space aggregator evaluates the proposals based on metrics like gas savings or total transactions fit. The most optimal proposal is selected. The transactions are committed as-is to the selected proposal. Users cannot modify or withdraw transactions. The winning bidder assembles their proposed block with the transaction batch and submits the sealed block to the blockchain.
Step 4: Any gas savings or profits generated from the optimization are shared back to the users according to predetermined criteria. The process repeats for the next time window with a new batch of transactions from users/applications.
A evaluates proposals and selects M's block, which saves gas by layering two transactions.
M's proposed block with Batch 1 is added to the blockchain.
The gas savings are shared back with Arhat, Ryan, and Charlie since their transactions were batched.
By optimizing the usage of limited block space across transactions, these auctions aim to maximize block throughput and minimize wasted capacity and fees.
Key Design “Decisions” for Order Flow Auctions
The key design decisions in OFAs are the most important architectural choices, mechanism configurations, and parameters that need to be determined when developing an OFA system.
Order Type Selection: A core design choice is whether the auction will be based on transactions or intents (discussed further in detail). Transactions contain all the settlement details encoded on-chain. Intents only specify the desired assets or outcome, allowing the settlement to be optimized later. Intents create more flexibility but require users to trust the optimization.
Settlement Rights: The auction designer must determine who has privileges to settle the transactions or intents. It could be open to anyone, restricted to authorized participants based on criteria like staking or limited to a single centralized provider. More open settlement rights increase competition but reduce control.
Optimization Objective: The optimization criteria guiding bidder behavior needs to be established. This includes metrics like maximizing returns to users, minimizing trading fees, or maximizing liquidity provision. The objective shapes bidding strategies and auction outcomes.
Information Revelation: Rules need to be set around what data is revealed to bidders and when. Keeping intent/transaction details private initially avoids front-running but allows less optimization. More transparency provides efficiency gains but risks misuse of information.
Key Design “Considerations” for Order Flow Auctions (OFAs)
On-chain vs Off-chain Components: A major design decision for OFAs is determining which elements should be on-chain versus off-chain. On-chain components leverage the decentralization and security of the blockchain but suffer from limits on computational complexity and latency. Off-chain components can enable more complex logic and optimizations, but introduce centralization risks as they are controlled by particular parties.
For example, Uniswap X uses off-chain systems for its initial RFQ price discovery. This provides lower latency and precision. However, it depends on a select set of market makers, creating a centralized element. Fully on-chain systems like Suave aim to avoid such centralization but may sacrifice efficiency. The ideal design likely combines both on and off-chain elements.
Permissioning: Another key consideration is permissioning - determining who is allowed to participate in the OFA auctions. More open permissionless systems promote decentralization but can encounter issues like "winner's curse" where unsophisticated actors win auctions only to lose money. More permissioned systems restrict participation to professional market makers, improving efficiency but raising barriers to entry.
Designers have to strike a balance here, either through reputation systems or a hybrid approach where some slots are reserved for open participation. Permissioning ties closely to the on-chain vs off-chain decision too, as off-chain systems tend to be more permissioned.
Information Revelation: OFA designers also have to determine when data is revealed to auction participants. If all information is revealed upfront, it reduces the value of that data. But revealing information only to the winner risks excluding actors and enables frontrunning. A hybrid approach where some data is public and some private preserves value while allowing broad participation.
The timing of data revelation matters too - revealing it before bids are placed reduces its value compared to after. OFAs have to carefully structure information flow to balance transparency and value preservation.
Credible Neutrality: Finally, designers must ensure the auction mechanism itself is credibly neutral - that the auctioneer cannot unfairly exploit its role. Various cryptographic techniques and trust mechanisms like trusted execution environments can address this. However, it remains challenging in permissionless environments.
These decisions and considerations around order types, settlement rights, optimization goals, information flow, and others, as mentioned in the previous table, fundamentally impact the capabilities, trade-offs, vulnerabilities, and performance characteristics of the order flow auction design. There are no perfect solutions, only appropriate tradeoffs based on the goals and context of the specific OFA implementation.
Why Are We Stressing on OFA Designs?
There are a few key reasons why it is important to discuss and understand the design decisions for OFAs:
OFAs are gaining adoption: As DeFi grows, OFAs are emerging as an important tool for things like redistributing miner extractable value (MEV) back to users and enabling decentralized exchanges. Their adoption is accelerating.
Design impacts usability: The way OFAs are designed can significantly impact their resulting user experience, efficiency, decentralization, and security. Poor design choices can limit their effectiveness.
There are many permutations: OFAs have many components like permissioning, on/off-chain logic, auction format, etc. There are endless possible configurations, making design complex.
Lack of standards: Since OFAs are still emerging, best practices and standards are still developing. Discussing designs openly helps establish norms and patterns.
OFAs enable new models: new paradigms like intents over transactions require analysis to unlock their full potential while avoiding pitfalls.
In summary, we believe that by openly discussing OFA designs, we can establish best practices to unlock the full transformative potential of this important DeFi primitive.
Intents vs. Transactions
Among the most pivotal OFA design decisions is the choice between utilizing transaction orders or intent orders.
Transactions
Transactions contain all the settlement details encoded into the transaction itself that gets submitted to the blockchain. This includes information like the source assets, destination assets, quantities, account addresses, and other fields required to execute the payment, trade, or other activity.
The transaction submitter has defined exactly how the settlement will occur on-chain. The submitter predetermines all the counterparties and flows. This provides certainty but lacks flexibility for optimization.
Intents
Intents only encode the minimal details required to describe the desired outcome of the transaction. This includes inputs like the source asset and quantity but leaves settlement specifics like counterparty addresses, routes, and other execution details unspecified.
By only specifying intent, the settlement itself can be optimized for efficiency by the auction operator based on current market conditions and other transactions in the batch. But users give up direct control over the final settlement in pursuit of better overall execution.
The choice between using intents or transactions is a critical design decision in order flow auctions (OFAs) that has significant implications on its capabilities and tradeoffs:
Transactions contain all the settlement details encoded on-chain, such as asset quantities, counterparty addresses, and execution logic. This provides users certainty over exactly what will execute but offers little flexibility for optimization. The transaction submitter predetermines the execution.
Intents only specify minimal details like the desired assets and quantities. Execution specifics are left unspecified, allowing the OFA to optimize settlement based on current conditions and other pooled orders. But users give up direct control over execution in pursuit of efficiency.
Discussing intents vs transactions is crucial because the choice impacts:
Flexibility: Intents enable more composability and optimization freedom versus fixed transactions.
User control: Transactions allow full control by users, while intents require pre-committing to the optimized settlement.
Decentralization: Intents can leverage off-chain components, unlike on-chain transactions.
Incentives: Transactions focus on on-chain efficiency and intents on user value.
Liquidity: Intents access wider private liquidity versus limited on-chain assets.
The intents vs transactions debate highlights how OFA designs encode different philosophies on decentralization, optimization scope, user sovereignty, and execution transparency. This makes it a crucial topic of discussion for OFA development.
When you try to simplify the Intents vs. Transactions debate around key design decisions in OFA architectures, these are what you are trading off:
Flexibility vs Control
Maximizing Opportunity vs Minimizing Risk
Liquidity Breadth vs Settlement Finality
Composability vs Pre-determination
Efficiency vs Decentralization
Private Order Books vs On-Chain Settlement
Abstraction vs Concreteness
Functional Outcomes vs Technical Details
Looking Ahead vs Locking In
Opening Up Design Space vs Committing to Specifics
Focusing on the What vs Focusing on the How
The main tradeoff seems to be between flexibility/optimization enabled by intents versus control/security ensured by transactions.
The Final Aspect of OFA Design
The choice between optimizing and settling orders individually versus aggregating orders into batches is a fundamental architectural decision in OFA design.
Individual Transaction Bidding: Bids are placed and evaluated for each transaction separately.
Batch of Transactions Bidding: Multiple transactions are grouped together, and bids are placed for the entire batch.
Further, Let’s Explore Some More Specific Categories.
OFA via a Private RPC: A private Remote Procedure Call (RPC) network is a secure communication channel that allows for direct interaction with blockchain nodes. In the context of OFA, a private RPC is used to facilitate and auction off order flow in a secure and efficient manner.
How it Works: Traders send their orders to the private RPC network, where they are then auctioned off to the highest bidder (usually arbitrageurs or other traders looking for MEV opportunities). The winning bidder gets the right to include the transaction in a block, potentially capitalizing on MEV opportunities, while the original trader benefits from potentially better trade execution and a share of the MEV captured.
For example, Flashbots and Eden Network enable MEV extraction on a proprietary basis, while solutions like MEV-Blocker redistribute a portion of MEV back to users. Private RPCs give OFA operators more control over transaction ordering and optimization.
Intent-based OFA APIs: Intent-based OFA APIs allow developers to integrate OFA functionalities directly into their applications, enabling end-users to participate in order flow auctions seamlessly.
How it Works: Traders express their intent to trade by sending their orders to the OFA API. The API then conducts an auction, determining the best way to execute the trade while capturing MEV opportunities. The results of the auction are then returned to the trader or directly executed on their behalf.
Solutions like Propeller, Wall Chain, and DFlow enable creation of intent-based orders that can be aggregated, optimized, and settled by an off-chain OFA operator. This unlocks benefits like composability and access to off-chain liquidity.
DEX with Integrated OFA: Some decentralized exchanges (DEXs) have integrated OFA directly into their platforms, providing users with an all-in-one solution for trading and participating in order flow auctions.
How it Works: When a user places a trade on a DEX with integrated OFA, their order is automatically entered into an auction. The DEX’s algorithms determine the best way to execute the trade, capturing MEV opportunities and optimizing for factors like price and slippage. The user receives the outcome of the trade directly through the DEX interface.
For example, Uniswap v3's concentrated liquidity enables better order matching. CowSwap leverages batched auctions to provide integrated MEV protection and fair pricing. These demonstrate exchange-level OFA customization.
In summary, each category of OFA implementation offers unique advantages and caters to different user needs. Whether through a secure private RPC network, flexible intent-based APIs, or convenient integrated DEX solution, OFA protocols play a crucial role in optimizing trade execution and mitigating the impacts of MEV in the DeFi ecosystem.
Challenges and Game Theory in OFAs
Order Flow Auctions exhibit complex game theory dynamics between participants competing for profit. This emerges due to misaligned incentives between users creating transactions, block proposers, arbitrageurs, and other actors.
For example, front-running is a common strategy where traders seek to capitalize on pending transactions by entering their own before the original executes. Sandwich attacks place simultaneous buy and sell orders ahead of a predicted trade to earn the spread. These exploit advanced knowledge of transactions.
Miner extractable value (MEV) also stems from game theory around transaction ordering and inclusion. Miners face incentives to maximize fee revenue by reordering and censoring transactions in ways that harm users.
OFA designs have to account for participants rationally responding to incentives around extraction, exploitation, and manipulation afforded by the asymmetry of information and speed advantages. This strategic behavior can undermine intended mechanisms without proper incentive alignment.
Collusion Risks: Collusion does not require secrecy to be sustainable. In fast-paced environments, MEV auctions, arbitrageurs, and small groups can coordinate if it aligns with profit maximization.
For example:
When Uniswap v3 launched in May 2021, it introduced concentrated liquidity and multiple fee tiers. This increased capital efficiency for liquidity providers. However, few arbitrage bots were ready to take advantage of v3 at launch.
Collusion: With so few arbitrageurs on v3 initially, there was an opportunity for excessive profits from arbitrage. Rather than competitively bid up the percentage of profits paid to miners (95-99% on v2), this small group of v3 arbitrage bots openly colluded on Discord to suppress their bids.
They coordinated to only pay around 60% of their sizable arbitrage profits to get included in blocks, pocketing the remaining 40% extra profit. This was despite over a dozen participants - a relatively large pool to be blatantly colluding in public. The arbitrage bots threatened to "grief" and trigger losses for any bot that refused to join the collusion ring. They tracked each other's addresses and monitored the Uniswap v3 activity. Bots that weren't cooperating faced retaliation.
Maintaining the Collusion: New bots were coerced into cooperation when they came online. Incumbents would message them demanding they join the collusion or else face retaliation and zero profits. This coordination continued for some time. By sharing information and alternating which blocks they targeted, the arbitrage bots maintained artificially high profit margins on v3, well below the competitive baseline. They persisted despite public awareness, leveraging encryption and speed advantages.
The potential for overt collusion demonstrates the severity of misaligned incentives. As seen in the Uniswap V3 arbitrage bot example, participants can coordinate to manipulate auctions for excessive profit even when acting publicly and transparently. Speed advantages combined with financial incentives led bots to openly collude on Discord to suppress bids. This extracted additional value at the expense of other network participants.
Some Additional Thoughts on Game Theory and OFAs
While the core auction mechanisms of OFAs are important, incentives and strategic behavior can undermine these mechanisms if not accounted for properly in the design. Simply assuming participants will act neutrally or competitively is insufficient, given the profit motives and demonstrated manipulation.
In a way, OFA designers are enacting game theory on a higher level with users and actors in the roles of players. The goal is to construct a "game" where good intent and honest participation end up being the equilibrium strategy for these players. But as we've seen, misalignments produce incentives that lead to "cheating" - front-running, MEV extraction, collusion, etc. So, designing the right game is critical.
Conclusion
Order flow auctions (OFAs) aim to create more equitable and efficient markets through their auction-based mechanisms for transaction settlement. By aggregating and optimizing orders into batches:
OFAs consolidate liquidity and facilitate uniform clearing pricing, preventing arbitrage across trades in the same auction. All users get the same prices. This fairer pricing stems from aggregating orders into joint auctions rather than having users transact independently into divergent markets.
Batching opaque orders makes MEV strategies like front-running harder to exploit, while joint optimization across transactions can lower total fees. Reducing information leakage pre-settlement combined with redistributing any MEV extracted back to users disincentivizes predatory behaviors. MEV-Blocker showcases redistributing MEV profits to users.
The auction bidding process incentivizes liquidity providers to reveal competitive prices to attract batch order flow, surfacing better prices compared to fixed AMMs. Auctions elicit actual supply and demand dynamics. Uniswap's concentrated liquidity enhances price discovery via focused liquidity ranges.
Optimized settlement of batched orders allows aggregation of duplicate transactions, lowering validation fees for users. Congestion is reduced by smoothing transaction demand spikes over batch auction windows.
The availability of pooled liquidity is increased by concentrating orders into unified auctions. Private liquidity can also be accessed off-chain. dYdX leverages historical order data to expand virtual liquidity for trades.
More specifically, Intent-centric architecture could shape the future landscape specifically for order flow auctions (OFAs):
With Intents, the OFA just receives the outcome the user wants without execution details. This gives OFAs flexibility to fill the intent however they want - across DEXs, CEXs, off-chain, etc. Modularity enables optimization.
Intents support expressing conditional logic and relationships between transactions. For example, an intent could consist of a multi-transaction arbitrage trade contingent on pricing thresholds. This expands what OFAs can support.
Intents provide a uniform format for multi-chain transactions. An OFA could fill an intent across chains, enabling atomic arbitrage, composable lending, and other cross-chain use cases.
By abstracting intent from execution, OFAs can tap into any liquidity source on or off-chain rather than just on-chain DEXs. This expands price discovery capabilities.
Intent-based OFAs unlock new efficiencies, customization, and user experiences not possible in transaction-centric designs. They enable OFAs to expand in scope and possibilities. While still early, promising examples of OFAs demonstrate their potential to rectify market inefficiencies, conflicts, and leakage - creating a more balanced decentralized exchange.
Find L2IV at l2iterative.com and on Twitter @l2iterative
Author: Arhat Bhagwatkar, Research Analyst, L2IV (@0xArhat)
References:
Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.
I think there's something wrong with the example of Frequent Batch Auctions:
- 5 ETH sold from Ryan to Arhat for USDC (A: +5ETH-USDC; R -5ETH+USDC);
- 5 ETH bought from AMM for Arhat with USDC (A: +10ETH-USDC);
- 5 ETH sold to Ryan for DAI (R: 0ETH+USDC-DAI)
Eventually Ryan's position is not satified, i.e. -5ETH & + DAI