Blockchain security isn't optional.

Protect your smart contracts and DeFi protocols with Three Sigma, a trusted security partner in blockchain audits, smart contract vulnerability assessments, and Web3 security. Get Your Smart Contract Audited Today

Introduction

This article is the 2nd part of the series where we explore the different designs of Automated Market Makers (AMMs) deeply describing the existing solutions on the market and what problems led to creating the solutions we have today.

In our previous article, we did a comprehensive overview of 30+ protocols currently functioning in the AMM space. We went through the history of AMMs starting with early Bancor v1 and Uniswap v1 developments which rely on Constant Function Market Makers (CFMMs) and finishing with providing a quick overview of new AMMs which allow for more customizations (like Uniswap v4) or the protocols that give more flexibility for Maximal Extractable Value (MEV) retention.

We deeply recommend reading the first part to understand the architecture flows of different AMM designs and why at first glance the “simple” task of swapping the assets led to progressive innovations in the crypto space.

In this article, we are going to explore the two architecture models and how they help to address current problems in the AMM space. These two models are order books and intents. Moreover, we will explore the current problems we have with AMMs from both user’s and developer’s point of view.

While order books have been around for a long time coming from Traditional Finance (TradFi), they bring new ideas into the AMM space such as hybrid Central Limit Order Book (CLOB) + AMM design of decentralized exchange (DEX).

On the other hand, intent is a completely new concept that can fix lots of problems such as poor UX or execution inefficiency.

We will explore those two models deeply focusing on the problems they solve, solutions they offer, architecture designs, and protocols operating in this space. Finally, we will discuss early-stage proposals for AMM designs and the specific problems they address.

There are a lot of solutions around AMMs, but first of all, what are the current problems in the AMM DEX space?

Current Problems in AMM DEX Space

Limitations of AMMs from LPs’ Point of View

AMMs are a great invention for addressing multiple problems in DEX space, however, they also come with some challenges related to mechanism design or incentives alignment.

Impermanent Loss

One of the biggest concerns for liquidity providers (LPs) in AMMs is impermanent loss (IL). IL occurs when LPs provide liquidity to a pool, and the value of their assets fluctuates compared to when they initially deposited them. The greater the price change, the higher the risk of impermanent loss. This results in a lower dollar value upon withdrawal compared to simply holding the asset without providing liquidity to AMM.

The main problem here is that LPs cannot escape IL, it will always be there because of the AMM design, LPs risk their assets to IL, but they’re getting rewards in return.

However, there are some protocols like Smilee Finance that address IL as a feature rather than a problem and come up with interesting solutions called “Impermanent Gains” where traders can take long or short positions on asset price volatility without the risk of liquidation, effectively transforming the concept of impermanent loss into a potential profit mechanism.

Other protocols that target liquidity providers on AMMs to hedge the IL risk are Panoptic or GammaSwap. Check out our detailed guide on the DeFi options landscape.

Low Capital Efficiency

Another issue with AMMs is that they don't always use all the available liquidity efficiently. This means that a lot of the liquidity isn't being used for trades. For example, in Uniswap V2 liquidity is distributed evenly across all price ranges (0 to infinity) which leads to low capital efficiency. In particular, for pegged assets. Think about USDC and USDT, they’ll trade 99% of the time around 1.000.WhywouldanyoneprovideliquidityonaUSDC−USDTpairata1.000. Why would anyone provide liquidity on a USDC-USDT pair at a 3,000 per USDC range?

In contrast, Uniswap V3 allows LPs to allocate their capital within specific price ranges, significantly enhancing capital efficiency. This means that LPs can concentrate their liquidity where trading activity is expected to be highest, earning more fees on their investment while minimizing the amount of capital at risk.

However, this model also introduces the challenge that liquidity is only active when the market price is within the specified range set by the LP. If the price moves outside this range, the liquidity becomes inactive and cannot earn fees, which can lead to periods where available liquidity is not utilized effectively.

Because of this, traders might end up with prices that aren't quite what they expected (slippage) and might not be able to buy or sell as much as they wanted. This can be a problem in pools with not a lot of liquidity or poorly distributed liquidity.

Loss-Versus-Rebalancing

Loss-Versus-Rebalancing (LVR) refers to the difference in value between an LP's portfolio in an AMM and a rebalancing portfolio that actively trades to capture price movements in the market.

This concept highlights how LPs can incur losses due to stale prices in AMMs compared to more liquid trading venues, such as centralized exchanges (CEXs). Specifically, when LPs provide liquidity to an AMM, they may end up executing trades at less favorable prices due to price slippage, which is the difference between the expected price of a trade and the actual price at which it is executed.

Most AMMs rely on internal pricing mechanisms that are slower to reflect real-time market changes. This creates price discrepancies that arbitrageurs can exploit. By buying assets at lower prices on the AMM and selling them at higher prices on other platforms, arbitrageurs correct the price but at the expense of liquidity providers. This forces LPs to sell their assets at a loss compared to what they could have received through dynamic portfolio rebalancing.

While many liquidity providers may be unaware of LVR, this silent threat can decrease their earnings by 10-12% annually. This significant financial loss can have a substantial impact on the profitability of large liquidity pools.

Limitations of AMMs from Users’ Point of View

Sandwiching and Frontrunning

Users can fall victim to two primary forms of malicious trading strategies: front-running and sandwich attacks. These tactics exploit the transparent nature of blockchain transactions and the mechanics of AMMs to profit at the expense of unsuspecting traders.

Front-running happens when a malicious actor, often using a bot, watches for large or significant trades in the mempool. Once they identify a transaction that could move the market price, they quickly submit their own trade with a higher fee to validators. This ensures their trade is processed first, allowing them to profit from the price movement caused by the original trade.

A sandwich attack is a specific type of front-running strategy that involves two transactions: one placed before and another after the victim's trade. This method aims to profit from the price changes caused by the victim's order.

These activities not only result in increased costs for users due to slippage but also undermine trust in decentralized trading platforms and can lead to substantial financial losses for regular traders.

Poor UX and UI

Some AMM interfaces can be overly complex, making it difficult for users to find essential functions like swapping tokens or providing liquidity. The lack of a clear and intuitive user interface can lead to frustration and errors.

For example, Uniswap v3 requires users to unbind their entire liquidity position to modify it. This means that to adjust the price range of your liquidity provision, you'll need to remove all your liquidity and then add it back with the desired new range.

Moreover, in Uniswap V2 you must deposit both assets of a pool to provide liquidity, even if you only want to provide liquidity for a single asset. Uniswap V2 relies on a Constant Product Market Maker Model (CPMM) model, which means the price of an asset in a pool is determined by the ratio of the two deposited tokens. If someone could just add one token, it would throw off this balance and lead to inaccurate pricing. It adds extra complexities to the user experience.

Jargon and complex terms can also intimidate new traders who are unfamiliar with DeFi. This confusion can discourage them from participating and lead to mistakes. Many newcomers also struggle with managing multiple networks, contract addresses, and wallets when swapping assets, creating additional challenges for those new to crypto.

Order Books

A central limit order book (CLOB) is a real-time display of all active buy and sell orders for a specific asset on a trading platform. It's essentially a ledger that provides traders with insights into market dynamics, including supply, demand, and potential price movements.

Each CLOB is divided into two sides:

  • Bids: Buy orders, where traders specify the price they're willing to pay for a cryptocurrency.
  • Asks: Sell orders, where traders indicate the price at which they're willing to sell.

The amount refers to the quantity of cryptocurrency being bought or sold, while the "price" is the value per unit.

To gain more control over their trades, traders often use limit orders. A limit order allows a trader to buy or sell a cryptocurrency at a specific price or better. For instance, a buy limit order (bid) is executed when the market price reaches or falls below the specified price. Similarly, a sell limit order (ask) is executed when the market price reaches or rises above the specified price.

Order depth measures the total quantity of buy and sell orders at various price levels. A deeper CLOB indicates higher liquidity, meaning that large orders can be executed without significantly impacting the price. Not-so-deep CLOB suggests lower liquidity and potential price volatility.

The balance between buy and sell orders in a CLOB significantly impacts price volatility. A sudden influx of sell orders can create a "sell wall," which can put downward pressure on the price. Similarly, a surge of buy orders can create a "buy wall," which can support the price.

History of Order Books

A central limit order book (CLOB) is a real-time display of all active buy and sell orders for a specific asset on a trading platform. It's essentially a ledger that provides traders with insights into market dynamics, including supply, demand, and potential price movements.

Each CLOB is divided into two sides:

  • Bids: Buy orders, where traders specify the price they're willing to pay for a cryptocurrency.
  • Asks: Sell orders, where traders indicate the price at which they're willing to sell.

The amount refers to the quantity of cryptocurrency being bought or sold, while the "price" is the value per unit.

To gain more control over their trades, traders often use limit orders. A limit order allows a trader to buy or sell a cryptocurrency at a specific price or better. For instance, a buy limit order (bid) is executed when the market price reaches or falls below the specified price. Similarly, a sell limit order (ask) is executed when the market price reaches or rises above the specified price.

Order depth measures the total quantity of buy and sell orders at various price levels. A deeper CLOB indicates higher liquidity, meaning that large orders can be executed without significantly impacting the price. Not-so-deep CLOB suggests lower liquidity and potential price volatility.

The balance between buy and sell orders in a CLOB significantly impacts price volatility. A sudden influx of sell orders can create a "sell wall," which can put downward pressure on the price. Similarly, a surge of buy orders can create a "buy wall," which can support the price.

History of Order Books

Order Books in TradFi

As we discussed in the previous section, an order book is simply a real-time display of buy and sell orders for a digital asset, providing valuable market insights.

CLOBs have evolved significantly over time. Before electronic trading, they were physical ledgers maintained by market makers. With the progress of electronic trading systems in the 1970s and 1980s, CLOBs became more efficient and accessible. The internet further improved CLOBs, allowing traders to view and interact with them in real-time. In the 1990s and 2000s, with the wide integration of the internet, CLOBs became increasingly accessible to a wider range of traders. Exchanges and trading platforms enabled individuals to view and interact with CLOBs in real-time, promoting fair and open markets.

Order Books in Crypto

There is one big difference between CLOBs for stocks and CLOBs for crypto. While stock trading is primarily centralized, crypto trading can occur on both centralized and decentralized platforms, often utilizing automated market makers.

Crypto markets, particularly for less popular tokens, often lack the liquidity seen in traditional stock markets. This liquidity disparity can result in wider spreads between buy and sell orders on crypto CLOBs. As a consequence, executing large trades in crypto can be more difficult without causing significant price fluctuations.

Centralized CLOBs vs. Decentralized CLOBs

Centralized CLOB (cCLOB) and decentralized CLOB (dCLOB) represent different approaches to crypto trading.

cCLOBs are common in TradFi, as we have written above. Here, an exchange acts as the middleman, matching buy and sell orders, keeping an order book, and settling trades for participants. The exchange also holds the assets being traded.

In dCLOBs, the order book is distributed across a network of nodes, eliminating the need for a central authority, if order book is running on-chain. Participants interact directly with the blockchain, executing trades through smart contracts. Moreover, participants retain control over their assets, with settlements occurring automatically on the blockchain. A fully decentralized CLOB is still a relatively new concept enabled by DeFi evolution.

CLOB vs. AMM

The debate over "CLOB vs. AMM" started in 2022-2023 and remains a hot topic. Order books haven’t been widely used in DeFi until recently, and even now, their decentralized version isn’t as well understood as the AMM model. This is because AMMs have historically been easier to implement on account-based blockchains like Ethereum. They come with lower transaction costs, faster settlements, and simpler designs.

In order book exchanges, liquidity is spread across the different prices where users are willing to buy or sell. Matching these orders requires complex operations and concurrent matching engines, making them challenging and expensive to run on account-based ledgers (used by Ethereum, Solana, and most blockchains). However, UTXO-based ledgers (like those used by Bitcoin and Cardano) naturally support the concurrency needed for order book matching, making them more suitable for this model.

The differences in how prices are set in AMMs and CLOBs have a significant impact on capital efficiency. In constant-product AMMs, prices are determined along an infinite curve. However, capital isn’t always actively used across all price ranges. For example, it’s highly unlikely that Ethereum will trade at 1 USDC within the next week, yet the AMM’s formula still allocates capital for such unlikely scenarios. Additionally, if the AMM doesn’t generate enough fees, LPs may experience impermanent loss.

CLOBs, on the other hand, rely on limit orders to provide liquidity. These orders sit in the order book as buy or sell offers, concentrating liquidity within specific price ranges. When buy (bid) and sell (ask) orders are close together, the spread narrows, making the market more liquid. If the orders overlap, trades can execute with little to no slippage, making CLOBs ideal for highly traded "fat-tail" assets like Bitcoin and Ethereum. However, when liquidity is low, spreads widen, and the lack of sufficient limit orders can make it harder to fill trades. In contrast, AMMs excel at price discovery for "long-tail" assets with lower trading volumes due to their flexible pricing mechanism.

Uniswap v3’s concentrated liquidity lets LPs specify a price range, such as 0.99–0.99–1.01 for USDC/USDT, ensuring their capital is fully utilized within that range to maximize fees. Unlike CLOBs, these AMMs aggregate constant product curves, offering flexibility for extreme price swings. This ensures trades execute even during events like the LUNA/UST collapse, maintaining liquidity in volatile markets.

AMMs have revolutionized market-making by automating the process. Users can simply deposit assets into a pool, distributing them across an indefinite (constant product) or specified price range (concentrated liquidity), making it easy to bootstrap pairs without technical expertise.

In contrast, CLOB market making is complex, requiring active management of limit orders and liquidity distribution, typically handled by institutional players or sophisticated traders. While concentrated liquidity can resemble a CLOB at advanced levels, average users can still benefit from its capital efficiency without needing intricate strategies.

AMMs and CLOBs differ in their incentive structures. AMMs rely on swap fees and liquidity incentives. If fees don't offset IL, liquidity decreases, leading to more slippage and lower trading activity. Incentives attract liquidity, improving slippage and trading volume, creating a virtuous cycle. However, protocols must balance incentives and revenue to avoid inflationary tokenomics.

CLOBs, on the other hand, charge taker fees for market orders and may reward maker fees for limit orders. Without impermanent loss, incentives are less critical but can still help bootstrap liquidity for tokens with wide spreads using governance tokens.

CLOBs excel in trading efficiency but are limited to token pairs. In contrast, AMMs optimize liquidity and can support multi-token pools, like a 3/4pool. For example, trading USDT to DAI in a CLOB requires swapping through USDC, reducing efficiency. An AMM can pool USDC, USDT, and DAI, enabling direct, capital-efficient trades across all three tokens.

MEV attacks are often cited as a challenge for AMMs, particularly concerns around frontrunning and sandwiching. However, these are not inherent issues. Solutions like zk proofs (e.g., Osmosis) and trusted enclaves (e.g., Secret Network) are addressing these risks by encrypting transaction data.

Similarly, while most CLOBs are off-chain and have security risks, this is not intrinsic to their design. Both AMMs and CLOBs are evolving: AMMs to mitigate MEV risks and CLOBs toward on-chain functionality. Notably, MEV attacks, including frontrunning, can also affect market orders on CLOBs.

Both CLOBs and AMMs have their advantages and disadvantages. However, some developers decided to bring the best out of 2 systems and combine them into a single hybrid model. Let’s talk about that in the next section.

Hybrid CLOB AMM Design

Most decentralized exchanges are typically classified as either AMMs or CLOB-based platforms. However, a growing number of platforms are blurring the lines between the two or offering entirely new approaches.

For instance, platforms like Serum and Polkadex provide both AMM and order book trading features. This design addresses common AMM issues—such as failed trades, gas wars, and limited order control.

Similarly, platforms like Onomy Protocol push the DEX model further by enabling asset trading across multiple blockchains, eliminating the need for separate DEXs and wallets for each chain. Onomy's hybrid DEX (ONEX) incorporates a traditional order book for handling limit and stop orders, while trades within existing spreads are completed via the AMM. This approach maximizes user returns, minimizes slippage, and reduces vulnerability to front-running attacks.

There is no unified hybrid CLOB AMM design, as it is different in every protocol that utilizes both AMM and CLOB. Let’s look at the main example of the app utilizing Hybrid CLOB AMM DEX design — Vertex Protocol.

Vertex Protocol

Vertex is a vertically integrated DEX on Arbitrum featuring spot, perpetual, and integrated money markets. Vertex combines an on-chain trading venue and risk engine with an off-chain sequencer to create a Hybrid Orderbook-AMM DEX. The on-chain components, managed by Vertex’s protocol smart contracts on Arbitrum, include its core offerings: spot trading, perpetuals, and a money market. These are integrated into a unified system for efficient trading and risk management. In this article, we only cover spot trading, so we will explore Vertex only in this direction.

The key components of the Vertex model are On-Chain Trading and Risk Engine, Off-Chain Sequencer, Integrated Clearinghouse, and Unified Trading Stack.

Threaded together with an EVM-compatible clearinghouse (i.e., on-chain risk engine), the core pillars produce a default cross-margined DEX on Arbitrum where users don’t have to sacrifice the control of self-custody for the performance and product features of CEXs.

Three Sigma’s Security Audit for Vertex

Vertex’s innovative hybrid order book + AMM model required a robust security framework to ensure fund safety, efficient execution, and seamless trading.

Three Sigma conducted an extensive 14-week audit, focusing on Vertex’s spot and perpetual markets, cross-margin system, and risk engine.

Our audit identified and addressed key vulnerabilities, including:

  • Oracle exploitation risks – Strengthened price feed mechanisms to prevent manipulation.
  • Liquidity pool manipulation – Implemented additional checks to secure clearinghouse functions.
  • Reentrancy vulnerabilities – Applied protections to prevent unauthorized recursive calls.

By collaborating closely with the Vertex team, we helped fortify its security infrastructure, ensuring resilient and efficient trading for its users.

At Three Sigma, we specialize in securing cutting-edge DeFi protocols. If you're building a next-gen exchange, lending platform, or staking protocol, reach out today to safeguard your project from emerging threats.

Get in touch with us to secure your protocol.

CPAMM and Risk Engine

Vertex’s integrated AMM employs the xy=k formula. The AMM resides on-chain within the protocol layer, functioning as the default state controlled by smart contracts. Known as “Slo-Mo Mode,” it operates alongside the Vertex order book, acting as a passive market maker via smart contracts rather than APIs. The AMM’s pooled liquidity is combined with that of automated traders via the off-chain sequencer, providing users with a unified source of liquidity. This ensures trades are always executed at the best available price, which may involve a combination of LP positions and limit orders sourced by the sequencer.

The main benefits of Vertex’s hybrid model include:

  • AMM ensures there’s always baseline liquidity for trade execution.
  • Supporting both passive LP liquidity and active limit orders, benefiting assets with high or low liquidity.
  • Users can trade directly on-chain without the sequencer if preferred.
  • The AMM allows passive LPing and facilitates the trading of long-tail DeFi tokens.
  • Transactions occur at the Arbitrum protocol layer, offering reduced gas fees compared to Ethereum L1.

As Vertex expands multi-chain in its second iteration, the AMM will support native spot assets from other EVM-compatible chains, broadening the range of tradable assets and enhancing its appeal to retail traders seeking a CEX-like experience.

Vertex Sequencer

The Vertex sequencer is an off-chain CLOB that operates as an independent node, with plans for decentralization through Vertex governance.

This order book is a key advantage of Vertex, enhancing liquidity by integrating positions from pairwise LP markets. An HFT-friendly API allows traders to connect to the order book, execute automated strategies, and trade against both the order book and AMM liquidity with lightning-fast speeds. Vertex achieves performance on par with CEXs, with order-matching execution speeds between 5-15 ms, bypassing the latency limitations of distributed node consensus.

In case of downtime or other issues, the AMM layer serves as a backup, ensuring that users can still trade against the AMM without needing the order book. This guarantees that transactions settle on-chain regardless of the sequencer’s status. For instance, if the sequencer fails, users would experience a Uniswap-like environment, but with cross-margined accounts, integrated products like spot, perpetuals, and a money market, along with lower fees on Arbitrum.

Initially, the sequencer operates as an independent node run by the Vertex team, supporting a throughput of 15,000 TPS and latency of 5-15 ms.

While the sequencer handles order matching, other actions, such as collateral withdrawal, account liquidation, and AMM swaps, require on-chain risk checks. All orders require explicit signatures from both parties before execution on-chain.

The average daily spot volume on Vertex is around 10 million dollars, which puts Vertex in the top 10 most popular DEXs on Arbitrum.

The main reason Vertex adopted a hybrid design is resilience and operational reliability. Without the AMM, a sequencer failure would halt trading entirely, negatively impacting user experience and liquidity. Despite the performance of the off-chain CLOB, certain actions (e.g., collateral management and liquidation) rely on on-chain processes, which AMMs inherently complement.

Main Risks

Hybrid DEX design doesn’t come without its trade-offs, as is the case with every mechanism design. One of these trade-offs is that hybrid DEXs don’t eliminate slippage completely; it still exists. Hybrid DEXs can experience slippage due to the interaction between AMM pools and order book mechanics. Large trades, in particular, can cause significant price changes, especially if liquidity is not well-distributed or if the order book lacks depth.

Some hybrid models rely on off-chain components for order matching, which can introduce centralization risks if a single entity controls these systems. This centralization can undermine the decentralized nature of DEXs and create vulnerabilities such as price manipulation or downtime if the off-chain infrastructure fails.

Hybrid DEXs often combine different trading strategies and liquidity models, which can lead to complexity. This complexity may confuse users, making it harder for them to navigate between the AMM and order book functions. Users might also struggle to develop effective trading strategies or provide liquidity appropriately.

What are Intents on DeFi?

Intents History

Users currently interact with Ethereum by crafting and signing transactions, specific messages that instruct EVM to execute state transitions. However, this process can be complex, requiring users to navigate smart contracts, manage nonces, and hold specific assets for gas fees. This complexity leads to poor user experience and inefficiencies, as users often make decisions without adequate information or tools.

Intents aim to simplify this process. Unlike transactions, which specify a single computational path, intents are signed messages that define constraints, allowing third parties to create transactions on a user’s behalf without surrendering full control. This flexibility lets users outsource transaction creation while maintaining oversight.

Intents also offer significant efficiency benefits. Multiple intents can be bundled into a single transaction, enabling operations like matching overlapping intents to reduce gas costs. They also support advanced use cases, such as cross-domain intents, alternative replay resistance schemes, and flexible gas payment options, including third-party sponsorship or payments in diverse tokens.

Essentially, an intent represents a person’s desired outcome. Intents have always existed, long before humans engaged with software, money, or barter systems. Every day, people subconsciously generate intents in their minds.

What has evolved is the variety of mechanisms available to fulfill these intents. From the first barter systems to modern options like fiat currencies, traditional finance, Bitcoin, and Ethereum, the tools have multiplied. These mechanisms are diverse, each offering unique properties and trade-offs. They are also non-exclusive, allowing individuals to choose the most suitable option for each specific intent.

Ethereum DEX volume is slowly growing over time, reaching 86 billion dollars in January 2025.

Meanwhile, the total volume of the top three intents solutions, including CoW Swap, Uniswap X, and 1inch Fusion, exceeded 10.5 billion dollars in January 2025, representing approximately 12% of the total DEX volume on Ethereum (DeFiLlama).

Intents Architecture

Intent-centric architectures prioritize user intent as the fundamental building block. Users define desired end states, and the system fulfills them within given constraints. This approach offers essential dApp features like generalized intents, counterparty discovery, solving, and settlement, as well as novel dApp capabilities such as scalability, information flow control, customizable ordering and settlement, and compositional identity. It also enforces a declarative paradigm for applications and enables decentralized market structures where users shape markets through their intents and actions.

Blockchain architectures like Ethereum offer a key feature: programmable settlement, enabling fully decentralized applications where intents, counterparty discovery, and execution happen on-chain. This suffices for simpler dApps like token creation, DAOs, and AMM-based DEXs such as Uniswap v3. However, more complex applications often cannot function entirely on Ethereum and instead adopt other architectures, where the final transaction is settled on Ethereum, but intent handling and execution rely on centralized web2 components.

To address centralization risks, some dApps deploy their own sovereign blockchains to handle additional requirements while maintaining Ethereum for settlement. While this mitigates centralization, it introduces trade-offs, such as reduced composability, increased complexity, and greater operational burdens for dApp teams, who now manage entire blockchains rather than just applications.

Intent-centric architectures solve these challenges by natively supporting four key elements: generalized intents, decentralized counterparty discovery, decentralized solving, and on-chain settlement. These architectures generalize the handling of intents, allowing any dApp to leverage them without being tied to a specific domain or security model.

By enabling fully composable intents, solvers can create solutions from diverse and complex combinations of intents, such as fungible token trades, NFT swaps, or mixed transactions. This approach eliminates fragmentation across blockchains, standardizing interactions and enabling dApps to work seamlessly across security models.

Architectures like Solana, Polkadot, and Avalanche introduce variations in consensus, sybil resistance, and privacy while maintaining Ethereum-like traits. However, applications remain fragmented across blockchains, forcing users to navigate domain-specific systems. Intent-centric architectures unify these experiences, enabling cross-domain composability through a standardized framework for intents.

By adopting a single language and interface for intents, intent-centric architectures offer a simpler, more efficient ecosystem for users and developers, enabling greater interoperability and innovation.

Bitcoin's scriptable settlement enabled basic dApps like currency issuance and payments. Ethereum's programmable settlement offered more flexibility for dApps like tokens, DAOs, and simple DeFi. However, limitations led to new architectures for advanced use cases like NFT marketplaces and complex DEXs.

The third generation, intent-centric architectures, builds on previous generations by enabling all their applications while achieving end-to-end decentralization. These architectures also introduce novel features such as local and global scalability, configurable settlement, compositional identity, and information flow control. These innovations pave the way for entirely new types of dApps, expanding beyond what existing architectures can support.

Summing up, we can identify 3 different stages of intent-centric architectures: scriptable settlement, programmable settlement, and modern architectures.

Protocols Utilizing Intents

CoW Swap

CoW Swap is an intent-based application by allowing users to specify their desired trade outcomes, delegating execution to permissionless third-party agents called solvers. These solvers compete in batch auctions, aggregating user orders and offering the most optimal execution route to maximize user surplus (assets received after the swap). Execution combines off-chain matching with on-chain swaps, and solvers are rewarded for successful order execution.

Unlike other AMMs, CoW Swap leverages Coincidence of Wants (CoW) to match overlapping user intents directly, bypassing liquidity pools. This reduces gas costs and improves efficiency. Additionally, since orders avoid the public mempool, CoW Swap mitigates MEV issues, further optimizing user swaps.

CoW Swap uses a batch auction system to group and settle orders together, unlike the traditional sequential order execution. This batch auction serves as CoW Swap’s core pricing mechanism. Orders are collected and sent to solvers (off-chain agents), who compete to execute them through either off-chain matching or on-chain DEXs.

Solvers analyze user inputs like price and slippage tolerance to optimize trading routes. Orders with matching intents are settled directly off-chain, while unmatched orders are executed through AMMs or DEX aggregators. The protocol then validates the solvers' solutions, selects the one that maximizes user surplus and finalizes the transaction on-chain.

Here’s how a batch auction works:

  1. Users submit their orders as intents off-chain.
  2. Orders are grouped into a batch and sent to the solver network.
  3. Solvers compete to find the best execution routes.
  4. Matching orders are settled off-chain between users.
  5. Unmatched orders are executed via AMMs or DEX aggregators.
  6. The protocol ranks the solvers’ solutions and executes the best one on-chain.

Solvers in CoW Swap compete to provide the best batch auction settlement by first identifying the Coincidence of Wants (matching trades) and then settling remaining orders through AMMs or DEX aggregators with minimal slippage.

The workflow of a solver begins with receiving the batch and optimizing settlements, aiming to offer the best clearing price and maximize user returns. The protocol selects the best solution, which is then executed on-chain. The winning solver earns COW tokens as an incentive. Solvers must be on an allowlist or provide a bond on CoW Improvement Proposal. Misbehavior, like failing to optimize user outcomes, results in bond slashing. Smaller solvers can be vouched for by bonding pool owners.

CoW Swap plans to enhance decentralization by introducing a permissionless solver model with two key features: smart contract validation and asset staking. Validation is a criterion for solver eligibility that will be embedded directly into the smart contract. Solvers will stake assets as a safeguard against malicious behavior, with penalties for misconduct.

This permissionless approach is expected to strengthen CoW Swap’s solver network, fostering competition among solvers. This has allowed CoWSwap to facilitate over $3.5 billion just over the last month (excluding trades routed through aggregators).

Aperture Finance

Aperture Finance is a DeFi protocol focused on simplifying user experience with an intent-based system. Through a GPT-like chatbox, users can express their goals in natural language. Solvers optimize and execute these requests efficiently and cost-effectively. Aperture serves as a versatile DeFi platform with broad applications. Aperture is creating a Layer 2 solution to support intents across EVM and non-EVM chains, leveraging advancements in AI. Its system has four key components: orchestrator, solver, sequencer, and fulfiller.

Aperture’s key value lies in simplifying how users articulate transactional goals. By leveraging modern LLMs, users can express their intents in natural language, which Aperture translates into actionable blockchain logic through its Intents DSL (Domain Specific Language). The Intents DSL is a specialized programming language designed to efficiently interpret and process user intents into blockchain events. Using a chatbot-like interface, Aperture can translate and verify user intents and convert them into valid on-chain logic for execution.

For example, a user might input: "Rebalance my ETH-DAI positions on Optimism L2 and Ethereum, allocating 60% to top-performing pools and 40% evenly across other pools."

The system processes this request and executes it seamlessly, enhancing user experience and transaction efficiency.

Aperture Finance uses the Solver DAO Network which is a specialized application layer built on Aperture’s Intents Infrastructure, allowing Solver DAOs to focus on creating and solving unique intent-based use cases without managing underlying execution.

Solver DAOs access user intents from Aperture’s Clearing House by staking APTRandAPTR and ETH. These DAOs can range from large professional solvers with proprietary solutions to networks of smaller solvers. New intent solutions may originate from Aperture or third-party Solver DAOs. These DAOs contribute by submitting the business logic needed to enable new use cases, making them accessible via Aperture’s interface or a custom interface created by the DAO. Aperture DAO also supports Solver DAOs with $APTR grants to encourage innovation.

Solvers compete by their methods of posting solutions, whether through smart contracts for scalability, off-chain scripts for speed, or manual submissions for specific intents (e.g., large OTC deals with longer timelines). Solvers with proprietary methods can use Aperture’s ZK Verification to build trust in off-chain solutions without revealing their approach, attracting more users and revenue. Moreover, solvers can crowdfund their staking requirements via vaults, offering a revenue-sharing model to contributors. Solver DAOs may create open-source vault contracts to bootstrap funding and attract stakeholders.

By combining AI, user-centric intents, and core DeFi primitives Aperture has managed to settle roughly $5 billion of volume. Solvers handle execution complexity, ensuring secure and fulfillment of user intent requests. Leveraging ZKPs, Aperture verifies Solver integrity and ensures fair rewards, delivering a seamless and trustworthy DeFi experience.

Across

Across is an intents-powered interoperability protocol enabling fast, low-cost cross-chain value transfers without compromising security. It addresses the limitations of current interoperability solutions and the challenges posed by the fragmented rollup and L2 ecosystem, where developers and users face complex, siloed systems.

Instead of relying solely on message passing, Across employs an intents-based architecture as the solution to these interoperability challenges, simplifying cross-chain interactions.

Intents architecture allows for fast order fulfillment by decoupling order execution from message verification. Relayers are paid once the protocol verifies that the user intent is fulfilled, with user funds held in escrow during this process. While relayers must temporarily loan funds between order execution and verification, the benefits of slower settlement, cheap, and secure verification, outweigh this cost.

Across' intent-based architecture is a 3-layer system:

  • Request for Quote Mechanism: Users define their desired outcomes without detailing the technical steps.
  • Network of Competitive Relayers: A decentralized network of third-party relayers competes to fulfill user orders.
  • Settlement Layer: Funds are escrowed, the request is verified, and relayers are paid upon successful completion.

Users request quotes from relayers to fill their orders, signing without an on-chain transaction. The current RFQ implementation does not support gasless orders or cross-chain swaps yet, but these are planned upgrades. Quoting uses fixed fees, and relayer competition is based on speed.

The relayer claims the order, executes the signed order, and brings the transaction on-chain. The user’s assets are escrowed in the SpokePool. The relayer then calls fillRelayV3 on the destination SpokePool, transferring their assets to the user. They also choose the repayment chain, affecting relayer fees paid to liquidity providers.

Over a 60-minute window, the Dataworker verifies fill events and aggregates them into a repayment bundle. If there are no disputes, the Dataworker executes the bundle on the HubPool and routes repayment to SpokePools. Relayers are repaid after a short delay.

Across supports RFQ systems external to the platform with different mechanics. While Across implements its own RFQ for the Bridge, other auction systems that produce signed orders recognized by the SpokePool are also supported.

Relayers, who are external to Across, compete to fill intent orders. Risk Labs runs an open-source relayer implementation to support the Bridge and expand the network. Across Settlement enables the processing of any cross-chain intent orders, providing escrow, verification, and repayment. It offers two key advantages: aggregated and optimistic verification and relayer cross-chain management.

Valid fills are aggregated off-chain and verified by UMA’s Optimistic Oracle. This optimizes gas costs, providing significant savings and better execution for users and relayers. Repayment is made on the relayer’s chosen chain, simplifying cross-chain management and reducing costs for relayers, which translates to better pricing for users. This is facilitated by Across' Hub and Spoke model, where LPs provide loans to relayers for managing time-value risk.

Over the past month of November, Across facilitated approximately $2+ billion in bridge asset transfers.

In Q2 2024, Across and Uniswap Labs proposed a new ERC-7683 standard that creates a unified framework for defining cross-chain actions in intent-based systems. If widely adopted, it could transform DEX dynamics, with Uniswap at the forefront of this shift. You can also check our ERC-7683 Uniswap Article.

Main Risks

While intents offer an exciting new approach to transactions, their widespread adoption could accelerate the shift of user activity to alternative mempools, risking centralization and the rise of rent-seeking intermediaries if not carefully managed.

If intent execution is permissioned and the permissioned set is poorly chosen, it could lead to centralization in Ethereum's block production. Since the Merge, most block production—roughly 90% of blocks, on Ethereum has happened through mev-boost, an out-of-protocol implementation of proposer-builder separation (PBS).

It relies on competition among block builders to direct MEV to validators. A major concern is that block builders may gain exclusive access to order flow, which could undermine the competitive structure of PBS. A block builder controlling a large share of Ethereum’s order flow could dominate block production and introduce censorship. This would shift value from Ethereum to the builder, posing significant risks of rent-seeking and censorship. Since the Merge, three entities—beaverbuild.org, Titan Builder, and Vanilla Builders—have been responsible for building most of the blocks, with 44.9%, 39.9%, and 10.5% of the total, respectively. Together, they account for 95.3% of all blocks.

Trust in intermediaries creates high barriers to entry for intent-based solutions. In the worst case, a monopolistic block builder could control intent execution, extracting rents and suppressing new proposals that don’t align with their interests. This issue extends beyond block building to other sectors, like the order flow auction (OFA) market, where entities like Flashbots and CoWswap dominate due to established trust. New entrants would face significant challenges in gaining user confidence, further entrenching middlemen, and limiting competition.

The risk of centralization is evident in the EIP-4337 intent format as well. If trusted intermediaries dominate its architecture, they may block adoption of new formats that compete with their business models, reinforcing trust-based barriers and slowing innovation.

Intent architectures often require users to surrender control over their on-chain assets, leading to opacity in how their expectations are met and leaving potential threats undetected. This issue is particularly relevant in intent-based applications, where users may outsource decisions like order routing. The risk of MEV harming user execution increases when transactions give up more control, such as through slippage limits. In the worst case, users may sign an intent that disappears into an unclear process and later materializes as a transaction with no transparency on its creation. This lack of clarity poses challenges for monitoring threats and maintaining the health of the ecosystem.

Addressing Risks

The Ethereum mempool has limitations, including privacy concerns (sandwiching) and its inability to support broader message formats, making it difficult for wallets and developers to connect users to the blockchain securely.

An ideal system should be permissionless, general, and transparent, allowing anyone to execute intents, supporting new applications without creating new mempools, and ensuring execution processes are publicly auditable when privacy allows.

While solutions like Flashbots and Anoma aim to address these needs, the ideal system may not be ready soon. In the meantime, different solutions with trade-offs may work better for specific applications. Tools like fallback transactions and cautious selection of middlemen for intent pools can help improve worst-case scenarios.

Innovations in AMM Space

Besides the AMM models that we have covered in that article and the previous one, some models are in the early stage of development. All of them popped up in 2024 and they offer different approaches to AMM design. In this section, we will explore am-AMM, pm-AMM, and sr-AMM.

am-AMM

Traditional AMMs can be risky for LPs due to factors like impermanent loss and arbitrage. Auction-managed AMMs (am-AMMs) offer a new approach to reduce these risks. In am-AMM, the pool manager takes on the risk of price volatility and volume fluctuations. LPs, in turn, earn a steady income based on expected fees and arbitrage profits that the pool manager will collect. This shift in risk can lead to increased profitability for LPs.

am-AMMs work by auctioning off the right to manage a liquidity pool to the highest bidder. This pool manager can then adjust fees to attract traders and maximize profits. Unlike traditional AMMs, am-AMMs allow the pool manager to directly profit from arbitrage opportunities. In return, the pool manager pays a fee to the liquidity providers. This system aims to make liquidity pools more profitable for both managers and providers.

Projects like BidDog and Bunni v2 are already implementing am-AMM mechanisms. These platforms aim to provide LPs with higher returns and better control over liquidity risks.

am-AMMs represent a promising development in DeFi, as more platforms adopt this model, we can expect a significant shift in the DeFi landscape. Source. Arxiv.

pm-AMM

pm-AMM is a new AMM model customized for prediction markets firstly introduced by Paradigm. AMMs currently dominate crypto DEX volume, however, crypto prediction markets mostly use CLOBs, not AMMs. As a result, existing AMMs are ill-suited for outcome tokens due to their volatile liquidity and guaranteed LP losses.

Paradigm introduced a new AMM model optimized for outcome tokens, addressing the question of AMM optimization for specific asset types. This model uses "Gaussian score dynamics" to predict price movement and creates a new AMM invariant (pm-AMM) to address these issues.

Loss-vs-rebalancing (LVR) is a metric that measures the expected losses for liquidity providers in AMMs due to stale prices and adverse selection. Uniform AMMs aim to distribute these losses evenly across different price levels, making them more predictable for liquidity providers. Constant-geometric-mean AMMs (like Balancer and Uniswap v2) are not suitable for assets with Gaussian score dynamics, such as prediction market tokens. Paradigm proposed two new AMM designs that address this limitation and offer a more uniform LVR for prediction markets.

  • Static pm-AMM: offers constant risk of loss (LVR) but LVR increases near expiry (volatile).
  • Dynamic pm-AMM: adjusts liquidity over time to keep LVR constant, offering less liquidity near expiry (may not be ideal for real pools).

However, the static pm-AMM loses value over time due to arbitrage. To mitigate this, a dynamic pm-AMM is proposed, where liquidity is withdrawn gradually. The dynamic pm-AMM's expected pool value decreases linearly, and the expected rate of loss is constant over time. This results in a 50% loss of initial wealth by maturity.

These AMMs might be useful for prediction markets and the concept can be applied to other asset types. Source: Paradigm.

sr-AMM

Sandwich-resistant AMM (sr-AMM) was firstly introduced by Umbra Research with a goal of creating a novel design that mitigates profitable sandwich attacks.

Sandwich attacks exploit high-slippage orders on AMMs. A victim, often a memecoin trader, places a large market order with a high slippage tolerance to ensure quick execution. A malicious actor can then

  • Frontrun the victim's order, buying the asset at a lower price
  • Let the victim's order execute at the worst possible price, further increasing the asset's price
  • Backrun the victim's order, selling the asset at a higher price.

These strategies, especially popular on Solana and Ethereum, allow attackers to profit significantly from unsuspecting traders. The sr-AMM extends traditional constant-product AMMs by enforcing a time-based invariant: swap prices are locked within a specific time window, preventing arbitrage opportunities that underpin sandwich attacks. Moreover, it inherently increases the net spread or fee paid by swappers, offering a trade-off between LP and swapper welfare, adjustable via minimum pool spread.

The first implementation of sr-AMM in production was made by Ellipsis Labs with a product called Plasma.

While preserving key AMM features like permissionless operations, it remains vulnerable to sandwiching at slot window boundaries and potential JIT (just-in-time) liquidity attacks. Mitigations include preventing consecutive leader control and implementing liquidity activation periods to deter bundled swap-and-liquidity strategies.

Summary of the innovations in the AMM Space

Conclusion

AMMs have revolutionized decentralized trading, but they come with their own set of challenges.

For LPs, the main problems include impermanent loss, low capital efficiency, and LVR. Impermanent loss occurs when the value of assets fluctuates after the deposit, resulting in a lower dollar value upon withdrawal compared to simply holding. Low capital efficiency refers to the fact that not all liquidity in a pool is actively used in trades, especially in older AMMs like Uniswap v2 where liquidity is spread across all price ranges regardless of trading activity. LVR highlights the potential losses LPs face due to stale prices and arbitrageurs exploiting price differences between AMMs and other platforms.

For users, AMMs can present issues like front-running and sandwich attacks, where malicious actors exploit the transparency of blockchain transactions to profit at the expense of regular traders. Poor UX and UI can also be a problem, with complex interfaces and jargon discouraging newcomers.

Several solutions are being developed to address these AMM problems. Vertex Protocol, for instance, offers a hybrid CLOB-AMM design that combines the benefits of both systems. This approach ensures baseline liquidity, supports both passive LP liquidity and active limit orders, and facilitates the trading of long-tail assets. CoW Swap utilizes an intent-based system where users specify desired trade outcomes, and solvers compete to find the best execution routes, minimizing gas costs and mitigating MEV issues. Aperture Finance takes this further by allowing users to express their goals in natural language through a GPT-like chatbox, which is then translated into actionable blockchain logic.

Other innovations in the AMM space include am-AMM, pm-AMM, and sr-AMM. Auction-managed AMMs (am-AMMs) shift the risk of price volatility from LPs to a pool manager, who actively manages the pool to maximize profits. Prediction Markets AMMs (pm-AMMs) are customized for prediction markets, addressing the limitations of traditional AMMs for outcome tokens. Sandwich-resistant AMMs (sr-AMMs) aim to mitigate sandwich attacks by locking swap prices within a specific time window.

These solutions represent the ongoing evolution of AMMs, tackling issues like MEV, slippage, and user experience. As the DeFi landscape continues to mature, we can expect further innovation and refinement of these solutions to create a more efficient and user-friendly trading environment.

We are excited about new AMM implementations, as discussed in previous sections. We believe these innovations will drive more efficient technology and enhance user experiences, all while minimizing added complexity for developers, users, and liquidity providers alike.

FAQ

What main issues do current AMMs create for liquidity providers and traders?

AMMs create several challenges for both LPs and traders.

LPs are exposed to impermanent loss, which occurs when the value of their assets fluctuates after they have been deposited in a liquidity pool, resulting in a lower withdrawal amount than simply holding the assets.

AMMs also suffer from low capital efficiency, as liquidity is often spread across an unutilized range, particularly for stable assets like USDC and USDT.

Additionally, LPs can face losses due to stale prices in AMMs, which differ from the more dynamic prices seen in centralized exchanges, resulting in arbitrage losses. Another form of MEV to which LPs are exposed is just-in-time liquidity.

For traders, the primary issues include slippage, front-running, and sandwich attacks, where malicious actors exploit AMM mechanics to profit at the expense of unsuspecting traders.

How do order books differ from AMMs?

Order books differ from AMMs in their approach to matching buy and sell orders. In an order book, buy and sell orders are listed at specific price points, and trades are executed when a matching order is found, often through limit orders.

This contrasts with AMMs, where liquidity is provided in pools, and prices are determined by the algorithm and are based on the ratio of assets in the pool, rather than individual orders.

Order books provide more control over trade execution and generally reduce slippage, especially in high liquidity environments. They also allow users to set specific price points for their trades, while AMMs use a continuous pricing model based on asset ratios.

The main tradeoff with order books is that they require liquidity to function effectively. In the absence of enough buy or sell orders at the very specific price points, trades will not be executed. This can lead to wider spreads in low liquidity markets, increasing slippage.

The hybridization of both models (think of Vertex AMM+CLOB), attempts to combine the benefits of AMMs' flexibility with the precision of order book systems.

How do intents improve the user experience while reducing MEV risks?

Intents improve the user experience by simplifying the transaction process. Instead of manually crafting transactions, users specify the desired outcomes, and the system executes the transactions on their behalf.

This flexibility not only reduces complexity but also allows for more efficient transaction execution by grouping and batching multiple intents to lower gas costs.

By removing the need for users to detail every action, intents mitigate the risks associated with MEV, such as front-running and sandwich attacks, because solvers are economically motivated to provide the most optimal route, and if possible, profit from the users’s outcome. This reduces the opportunities for malicious actors.

How do hybrid models combining AMMs and order books help with impermanent loss and slippage?

Hybrid models that combine AMMs and order books aim to address the issues of impermanent loss and slippage by leveraging the strengths of both systems.

The order book component helps to narrow spreads and reduce slippage, particularly for more liquid and frequently traded assets, by providing a more predictable price mechanism.

On the other hand, the AMM component ensures that liquidity is always available, even for long-tail assets that may not have active order book participants.

References