* A special thanks to Filius from the GlueX team and the Barter team for continuous enlightenment on the solver workflow.

Your liquidity is only discoverable by those who are looking for it, and in the dark forest, those are seldom your friends.

Order flow is essential to making LPs profitable—yet getting trades from real users routed to a new Decentralized Exchange is unexpectedly complex. This piece will discuss the historical primitives for matching retail order flow with onchain liquidity pools. It will uncover how a new DEX can expose itself to Ethereum’s most profitable sources of non-toxic order flow in today’s landscape.

This is how to safely illuminate oneself in the dark forest.

If a developer writes an entirely new smart contract AMM from scratch, deploys it on Ethereum mainnet, and deposits liquidity, they will eventually see some trading volume.

Why is this? How can a completely arbitrary smart contract be found and used for trading?

There is the programmatic hunting of liquidity by searchers and arbitrageurs at play in the dark forest. We can distill this concept into a simple rule of law on Ethereum today:

If there is value to be extracted, searchers will find and exploit it.

For DEXes, this hunting of liquidity results in toxic order flow that works to make LPs unprofitable.

(See Ethereum is a Dark Forest)

Order flow from retail users and noise traders is an essential component of LP profitability—yet these trades do not follow this same law of magnetic discovery. Uninformed trades find their way to Decentralized Exchanges through various types of routers, which require special integrations to discover new liquidity pools. Unlike order flow from toxic searcher arbitrageurs, exposure to the order flow from retail routers is a non-trivial barrier new DEXes must overcome. These routers control the order flow essential to make DEXes profitable; hence, integrating with these routers determines the success of a new Decentralized Exchange.

The lifecycle of a trade is determined at the source—the user interface. This piece explores the different routing primitives behind Swap UIs and explains how they affect the function and success of onchain liquidity pools.

Liquidity Pools have their own frontend and users.

When AMMs first introduced deep liquidity onchain—each DEX was only discoverable to most users through a custom Swap UI.

Each DEX had a frontend, and each frontend routed only to that DEX.

There is no aggregation in this model. Users interact with onchain liquidity in the most direct way possible: manually comparing prices across different DEX UIs.

Trading UIs are sticky. Users care about branding, UX, and familiarity—not only price.

Lazy users get worse prices than users who check multiple frontends, and new DEXes must convince users to come to their Swap UI. A new DEX's success is determined by its ability to attract users directly rather than solely competing on price.

Today, while Uniswap's frontend offers strictly worse prices than other venues, it still retains many daily users.

This is a world where liquidity pools own their users—disincentivizing innovation.

1Inch introduced aggregation, a Swap UI that uses a single routing algorithm to route across several liquidity sources. Liquidity Pools and DEXes no longer own the order flow; a neutral routing algorithm does.

New liquidity pools must integrate into an aggregator’s centralized routing algorithm. Once integrated, liquidity pools compete for a user’s order flow based on the price they offer them.

However, getting integrated into centralized aggregators is not easy.

1inch and the like are not greatly incentivized to integrate new liquidity pools, especially non-standard complex designs. UIs are sticky, so aggregators own their users’ order flow. Price improvements would need to be vast for 1Inch users to leave the platform. Hence, new liquidity pool integrations are seldom the priority for centralized aggregators. Wallet Swap UIs like MetaMask Swaps, APIs like LiFi, and telegram bots like Banana Gun are all routers that require integrations by a centralized team. Since centralized routers own their users’ order flow, they can place growingly strict requirements for integrating new liquidity sources.

These integration requirements include things like

• The integration must be simple and standard. Complex AMM mechanisms that require extra work to simulate price or reverts are discouraged. Querying offchain systems to transact causes extra friction and are non-standard to integrate.

• The pool must have some minimum TVL or consistent and vast price improvement across several assets before being considered for integration.

These constraints advocate for standardization and status quo of DEXes, severely discouraging experimentation. Despite these constraints positioned by centralization, the user’s order flow has gone from being owned by the liquidity pool UI to being owned by a credibly neutral router. Meta-aggregators like Llama Swap are a bit of an exception to this- but it still doesn’t break the monopoly centralized routers have on DEX integrations.

Order Flow Auctions (OFAs) significantly reshaped Ethereum’s Order Flow Landscape. Multiple routing algorithms compete to settle a user’s trade in an auction. No longer does a single router own the rights to a user’s order; multiple routers compete for that order flow based on price execution.

CoWSwap, the primary example of an order flow auction, has quickly become the primary choice for users trading onchain because of the incentive alignment it introduces.

Multiple independent routing algorithms (solvers) compete on price and execution to settle a user’s trades. Nobody owns the order flow—everyone must compete for it on fair grounds.

Solvers are well incentivized to integrate new liquidity sources due to the high competition for best price. OFAs replace the monopoly on order flow with open and fair competition between routing algorithms. It is up to Decentralized Exchanges to expose themselves in these order flow competitions through a series of rails and solutions discussed below.

Note: All OFAs' current implementations still have significant trust assumptions and centralization points; overcoming these will be a theme in the coming years.

Solvers are often debated nomenclature; for this piece, we refer to them as middlewares for fulfilling a user’s trade intent; this includes both fillers and routers. From the perspective of a DEX, we are primarily interested in solvers that are routing order flow to onchain liquidity pools—akin to competing routing algorithms.

Solvers often operate on multiple OFAs, so a single Solver integration might expose a liquidity pool to order flow from CoWSwap, 1Inch Fusion, and UniswapX traders simultaneously.

It is essential for a Decentralized Exchange to understand the constraints of solvers and then design around them. These constraints are applied mainly by the OFAs and blockchains on which they operate.

CowSwap (Referee)

1. User initiates trade request

2. Solvers submit bids to CoW Protocol over a fixed period.

3. The winning solution is picked, and the winning solver is granted permission to execute the users’ batch.

1inch Fusion/UniswapX (No Referee)

1. User originates intents, starting a Dutch-Auction

2. Solvers race to execute users’ trades if they abide by the Dutch Auction price.

The 1inch Fusion winner is selected automatically based on who was able to offer the highest priority fee or forward their solution directly to a builder. UniswapX and 1inch Fusion also allow solvers to win exclusivity if the solver was the same one that provided the quote with which the intent originated. We can notice the tradeoffs presented to the solver:

• CoWSwap has a longer delay between when a solution is submitted and when it can be executed, requiring less urgency for submitting solutions but less control over execution time. This makes solvers have a higher preference for liquidity sources with more price stability and more deterministic execution.

• 1Inch Fusion/UniswapX requires faster solving and racing execution to compete. The tradeoff is that the solver has more control over the time between a solution being computed and it being executed. These venues also give some preference to ‘direct fills’.

These constraints make using specific onchain/offchain sources of liquidity more preferable than others, not always purely based on price. Understanding the solver workflow is essential in building a successful Decentralized Exchange in the intent-centric era.

Standardization, collaboration, and reinventing composability.

Integrating novel liquidity pools is cumbersome. There is no standard process for simulating trades over DEXes: complex dynamic fees, time-based mechanisms, edge-case reverts, and unclear payload generation all make integrating new DEXes difficult.

Today, solvers integrate liquidity pools in isolation. For 1000s of novel AMMs to co-exist, we cannot require 100s of solvers to integrate each pool individually.

There are proposed solutions for standardizing novel AMMs for solver integrations:

• Propeller Heads proposed EIP 7815, introducing a standard interface for DEXes that provides standard external functions for solvers to simulate trades at the smart contract level. This reduces the work it takes for an individual solver to query a new liquidity pool by standardizing the liquidity pool interface.

• GlueX is a Solver Network composed of offchain integration tooling. Liquidity Pools are translated into offchain Python functions that any solver can leverage for simulations and execution. A one-time integration for a liquidity pool into the Solver Network makes the liquidity pool accessible to all solvers operating on that network. This severely reduces the need for repeated integration work by standardizing the offchain simulation logic for a new liquidity pool across several solvers.

• Khalani Network proposes collaborative solving as a solution to the integration complexity. Solvers should specialize and collaborate instead of trying to be generalists competing. Not every solver should integrate every pool. Instead, custom liquidity pools can spin up their own solvers, and instead of competing for the entire route, they can share sub-routes to “collaboratively solve” a user’s trades with other solvers. This, in effect, is another form of standardization, but at the communication layer between solvers.

Solving the discoverability of liquidity pools across the network of routers, optimizers, and solvers is the key to unlocking the Decentralized Exchange Renaissance.

Still, solvers have a large gap and high sensitivity in execution certainty. What is simulated locally does not have the guarantee of executing the same onchain. When interacting with a new liquidity pool, a solver accidentally hitting an edge-case revert is detrimental to their business and can directly cause punishment like slashing on CoWSwap. DEXes should be as deterministic as possible.

DEX designers can take precautions to give more stable estimates to solvers. For example, at the smart contract level, they can ensure revert cases are as predictable as possible by avoiding conditionals with complex state dependencies. Offchain solutions can also be leveraged to give more transaction determinism.

Application-Specific sequencing (ASS) is the general idea of an application expressing some control flow over the transactions entering it. With greater control flow comes the option to provide some level of determinism to takers (users, traders, solvers).

The use of state-lock means DEXes can guarantee execution to solvers and traders while compromising on atomic composability and asynchronous execution and introducing a more sophisticated transaction workflow. Even if an order takes X blocks to execute—ASS can be used to help predetermine and guarantee price execution.

ASS solutions often introduce extra dependencies to transact over applications—such as outsourcing execution to another network. This breaks the typical transaction workflow for solvers—creating a barrier to easy order flow integrations offered through widespread and unfiltered composability.

If an application is big enough, it will likely demand niche integrations that require breaking changes to traditional workflows. Today, only the big players have the luxury of existing outside the standards.

Latency, Transaction Workflow, and Determinism in Offchain Systems

When DEXes introduce offchain dependencies for transaction ordering, execution, and pricing—solvers must now interact with these offchain networks to interact with liquidity pools. This interaction introduces latency, which complicates the solver’s transaction workflow BUT can give better degrees of determinism and quality to their execution.

We point to HOT AMM as a hybrid example of application-specific sequencing that attempts to achieve all the good and none of the bad.

Solvers request quotes from an offchain service—these quotes can be submitted asynchronously to the mempool with a guaranteed price for a set of time, providing determinism and a familiar transaction workflow. A simple call-and-response API minimizes latency and communication overhead, allowing solvers to specify the latency they expect for a response. Additionally, and most importantly, the liquidity pool simultaneously exposes a fully composable AMM, which contains no offchain dependencies with which to integrate.

HOT is an example of a system designed with the state and constraints of OFAs in mind—we can observe how designing around the modern intent landscape allowed for HOT AMM to quickly rise as a dominant pool for CoWSwap ETH/USDC order flow—with only a fraction of the liquidity as competing venues.

Order flow pipelines can become unbendable. We must build them in a way that allows and encourages new liquidity pool designs. Otherwise, we will strangle innovation at the DEX level. We need more exploratory DEX design.

The onchain economy is quickly evolving and growing increasingly diverse. One-size-fits-all AMMs and order books will never address the vast array, constraints, and profiles of a diverse set of decentralized LPs and traders.

We need more DEXes and non-monopolistic distribution, routing, and discoverability systems to let new entrants thrive. As we discover what standardizing DEX integrations means, we should ensure we do not standardize what a valid DEX is. We must keep the design space open and free—and reject convenience.

One thing is clear: We are in an intent-centric era of DeFi. What that means is not set in stone yet.

* A special thanks to Filius from the GlueX team and the Barter team for continuous enlightenment on the solver workflow.

Your liquidity is only discoverable by those who are looking for it, and in the dark forest, those are seldom your friends.

Order flow is essential to making LPs profitable—yet getting trades from real users routed to a new Decentralized Exchange is unexpectedly complex. This piece will discuss the historical primitives for matching retail order flow with onchain liquidity pools. It will uncover how a new DEX can expose itself to Ethereum’s most profitable sources of non-toxic order flow in today’s landscape.

This is how to safely illuminate oneself in the dark forest.

If a developer writes an entirely new smart contract AMM from scratch, deploys it on Ethereum mainnet, and deposits liquidity, they will eventually see some trading volume.

Why is this? How can a completely arbitrary smart contract be found and used for trading?

There is the programmatic hunting of liquidity by searchers and arbitrageurs at play in the dark forest. We can distill this concept into a simple rule of law on Ethereum today:

If there is value to be extracted, searchers will find and exploit it.

For DEXes, this hunting of liquidity results in toxic order flow that works to make LPs unprofitable.

(See Ethereum is a Dark Forest)

Order flow from retail users and noise traders is an essential component of LP profitability—yet these trades do not follow this same law of magnetic discovery. Uninformed trades find their way to Decentralized Exchanges through various types of routers, which require special integrations to discover new liquidity pools. Unlike order flow from toxic searcher arbitrageurs, exposure to the order flow from retail routers is a non-trivial barrier new DEXes must overcome. These routers control the order flow essential to make DEXes profitable; hence, integrating with these routers determines the success of a new Decentralized Exchange.

The lifecycle of a trade is determined at the source—the user interface. This piece explores the different routing primitives behind Swap UIs and explains how they affect the function and success of onchain liquidity pools.

Liquidity Pools have their own frontend and users.

When AMMs first introduced deep liquidity onchain—each DEX was only discoverable to most users through a custom Swap UI.

Each DEX had a frontend, and each frontend routed only to that DEX.

There is no aggregation in this model. Users interact with onchain liquidity in the most direct way possible: manually comparing prices across different DEX UIs.

Trading UIs are sticky. Users care about branding, UX, and familiarity—not only price.

Lazy users get worse prices than users who check multiple frontends, and new DEXes must convince users to come to their Swap UI. A new DEX's success is determined by its ability to attract users directly rather than solely competing on price.

Today, while Uniswap's frontend offers strictly worse prices than other venues, it still retains many daily users.

This is a world where liquidity pools own their users—disincentivizing innovation.

1Inch introduced aggregation, a Swap UI that uses a single routing algorithm to route across several liquidity sources. Liquidity Pools and DEXes no longer own the order flow; a neutral routing algorithm does.

New liquidity pools must integrate into an aggregator’s centralized routing algorithm. Once integrated, liquidity pools compete for a user’s order flow based on the price they offer them.

However, getting integrated into centralized aggregators is not easy.

1inch and the like are not greatly incentivized to integrate new liquidity pools, especially non-standard complex designs. UIs are sticky, so aggregators own their users’ order flow. Price improvements would need to be vast for 1Inch users to leave the platform. Hence, new liquidity pool integrations are seldom the priority for centralized aggregators. Wallet Swap UIs like MetaMask Swaps, APIs like LiFi, and telegram bots like Banana Gun are all routers that require integrations by a centralized team. Since centralized routers own their users’ order flow, they can place growingly strict requirements for integrating new liquidity sources.

These integration requirements include things like

• The integration must be simple and standard. Complex AMM mechanisms that require extra work to simulate price or reverts are discouraged. Querying offchain systems to transact causes extra friction and are non-standard to integrate.

• The pool must have some minimum TVL or consistent and vast price improvement across several assets before being considered for integration.

These constraints advocate for standardization and status quo of DEXes, severely discouraging experimentation. Despite these constraints positioned by centralization, the user’s order flow has gone from being owned by the liquidity pool UI to being owned by a credibly neutral router. Meta-aggregators like Llama Swap are a bit of an exception to this- but it still doesn’t break the monopoly centralized routers have on DEX integrations.

Order Flow Auctions (OFAs) significantly reshaped Ethereum’s Order Flow Landscape. Multiple routing algorithms compete to settle a user’s trade in an auction. No longer does a single router own the rights to a user’s order; multiple routers compete for that order flow based on price execution.

CoWSwap, the primary example of an order flow auction, has quickly become the primary choice for users trading onchain because of the incentive alignment it introduces.

Multiple independent routing algorithms (solvers) compete on price and execution to settle a user’s trades. Nobody owns the order flow—everyone must compete for it on fair grounds.

Solvers are well incentivized to integrate new liquidity sources due to the high competition for best price. OFAs replace the monopoly on order flow with open and fair competition between routing algorithms. It is up to Decentralized Exchanges to expose themselves in these order flow competitions through a series of rails and solutions discussed below.

Note: All OFAs' current implementations still have significant trust assumptions and centralization points; overcoming these will be a theme in the coming years.

Solvers are often debated nomenclature; for this piece, we refer to them as middlewares for fulfilling a user’s trade intent; this includes both fillers and routers. From the perspective of a DEX, we are primarily interested in solvers that are routing order flow to onchain liquidity pools—akin to competing routing algorithms.

Solvers often operate on multiple OFAs, so a single Solver integration might expose a liquidity pool to order flow from CoWSwap, 1Inch Fusion, and UniswapX traders simultaneously.

It is essential for a Decentralized Exchange to understand the constraints of solvers and then design around them. These constraints are applied mainly by the OFAs and blockchains on which they operate.

CowSwap (Referee)

1. User initiates trade request

2. Solvers submit bids to CoW Protocol over a fixed period.

3. The winning solution is picked, and the winning solver is granted permission to execute the users’ batch.

1inch Fusion/UniswapX (No Referee)

1. User originates intents, starting a Dutch-Auction

2. Solvers race to execute users’ trades if they abide by the Dutch Auction price.

The 1inch Fusion winner is selected automatically based on who was able to offer the highest priority fee or forward their solution directly to a builder. UniswapX and 1inch Fusion also allow solvers to win exclusivity if the solver was the same one that provided the quote with which the intent originated. We can notice the tradeoffs presented to the solver:

• CoWSwap has a longer delay between when a solution is submitted and when it can be executed, requiring less urgency for submitting solutions but less control over execution time. This makes solvers have a higher preference for liquidity sources with more price stability and more deterministic execution.

• 1Inch Fusion/UniswapX requires faster solving and racing execution to compete. The tradeoff is that the solver has more control over the time between a solution being computed and it being executed. These venues also give some preference to ‘direct fills’.

These constraints make using specific onchain/offchain sources of liquidity more preferable than others, not always purely based on price. Understanding the solver workflow is essential in building a successful Decentralized Exchange in the intent-centric era.

Standardization, collaboration, and reinventing composability.

Integrating novel liquidity pools is cumbersome. There is no standard process for simulating trades over DEXes: complex dynamic fees, time-based mechanisms, edge-case reverts, and unclear payload generation all make integrating new DEXes difficult.

Today, solvers integrate liquidity pools in isolation. For 1000s of novel AMMs to co-exist, we cannot require 100s of solvers to integrate each pool individually.

There are proposed solutions for standardizing novel AMMs for solver integrations:

• Propeller Heads proposed EIP 7815, introducing a standard interface for DEXes that provides standard external functions for solvers to simulate trades at the smart contract level. This reduces the work it takes for an individual solver to query a new liquidity pool by standardizing the liquidity pool interface.

• GlueX is a Solver Network composed of offchain integration tooling. Liquidity Pools are translated into offchain Python functions that any solver can leverage for simulations and execution. A one-time integration for a liquidity pool into the Solver Network makes the liquidity pool accessible to all solvers operating on that network. This severely reduces the need for repeated integration work by standardizing the offchain simulation logic for a new liquidity pool across several solvers.

• Khalani Network proposes collaborative solving as a solution to the integration complexity. Solvers should specialize and collaborate instead of trying to be generalists competing. Not every solver should integrate every pool. Instead, custom liquidity pools can spin up their own solvers, and instead of competing for the entire route, they can share sub-routes to “collaboratively solve” a user’s trades with other solvers. This, in effect, is another form of standardization, but at the communication layer between solvers.

Solving the discoverability of liquidity pools across the network of routers, optimizers, and solvers is the key to unlocking the Decentralized Exchange Renaissance.

Still, solvers have a large gap and high sensitivity in execution certainty. What is simulated locally does not have the guarantee of executing the same onchain. When interacting with a new liquidity pool, a solver accidentally hitting an edge-case revert is detrimental to their business and can directly cause punishment like slashing on CoWSwap. DEXes should be as deterministic as possible.

DEX designers can take precautions to give more stable estimates to solvers. For example, at the smart contract level, they can ensure revert cases are as predictable as possible by avoiding conditionals with complex state dependencies. Offchain solutions can also be leveraged to give more transaction determinism.

Application-Specific sequencing (ASS) is the general idea of an application expressing some control flow over the transactions entering it. With greater control flow comes the option to provide some level of determinism to takers (users, traders, solvers).

The use of state-lock means DEXes can guarantee execution to solvers and traders while compromising on atomic composability and asynchronous execution and introducing a more sophisticated transaction workflow. Even if an order takes X blocks to execute—ASS can be used to help predetermine and guarantee price execution.

ASS solutions often introduce extra dependencies to transact over applications—such as outsourcing execution to another network. This breaks the typical transaction workflow for solvers—creating a barrier to easy order flow integrations offered through widespread and unfiltered composability.

If an application is big enough, it will likely demand niche integrations that require breaking changes to traditional workflows. Today, only the big players have the luxury of existing outside the standards.

Latency, Transaction Workflow, and Determinism in Offchain Systems

When DEXes introduce offchain dependencies for transaction ordering, execution, and pricing—solvers must now interact with these offchain networks to interact with liquidity pools. This interaction introduces latency, which complicates the solver’s transaction workflow BUT can give better degrees of determinism and quality to their execution.

We point to HOT AMM as a hybrid example of application-specific sequencing that attempts to achieve all the good and none of the bad.

Solvers request quotes from an offchain service—these quotes can be submitted asynchronously to the mempool with a guaranteed price for a set of time, providing determinism and a familiar transaction workflow. A simple call-and-response API minimizes latency and communication overhead, allowing solvers to specify the latency they expect for a response. Additionally, and most importantly, the liquidity pool simultaneously exposes a fully composable AMM, which contains no offchain dependencies with which to integrate.

HOT is an example of a system designed with the state and constraints of OFAs in mind—we can observe how designing around the modern intent landscape allowed for HOT AMM to quickly rise as a dominant pool for CoWSwap ETH/USDC order flow—with only a fraction of the liquidity as competing venues.

Order flow pipelines can become unbendable. We must build them in a way that allows and encourages new liquidity pool designs. Otherwise, we will strangle innovation at the DEX level. We need more exploratory DEX design.

The onchain economy is quickly evolving and growing increasingly diverse. One-size-fits-all AMMs and order books will never address the vast array, constraints, and profiles of a diverse set of decentralized LPs and traders.

We need more DEXes and non-monopolistic distribution, routing, and discoverability systems to let new entrants thrive. As we discover what standardizing DEX integrations means, we should ensure we do not standardize what a valid DEX is. We must keep the design space open and free—and reject convenience.

One thing is clear: We are in an intent-centric era of DeFi. What that means is not set in stone yet.