1. Introduction: The Evolution of Cross-Chain Swap Architectures and the Core Problem
Public blockchain ecosystems are being reshaped into a multi-chain environment where L1s, L2s, rollups, and appchains coexist. Users increasingly hold and exchange assets assuming cross-chain movement, and service providers have also normalized operating chain-specific infrastructure. As a result, liquidity and user experience become fragmented by chain, and as execution steps increase, cost, latency, and failure points expand in tandem.
Cross-chain swaps emerged to mitigate these issues. However, as adoption expands from trading into payments, commerce, and institutional use cases, the structural limits of the widely adopted AMM (liquidity pool)-based model are becoming increasingly clear.
1.1 Structural Limitations Facing AMM-Based Cross-Chain Swaps
AMM-based cross-chain swaps operate on the assumption that liquidity is pre-positioned on the destination chain. To deliver the same swap experience across multiple chains, liquidity pools must be maintained per chain, and that liquidity continuously shifts based on incentive design and market volatility. AMMs do not resolve liquidity fragmentation; instead, they increase the operational burden of managing chain-by-chain liquidity.
This burden translates into slippage—the gap between the expected price and the executed price. In AMMs, prices are not fixed quotes; they are determined by the pool’s reserve state, and the trade itself changes the pool balance and moves the price. As trade size increases, price impact compounds, and the average execution price drifts further away from the user’s expected exchange rate.
In cross-chain settings, execution delays are introduced between chains. The larger the gap between the quote time and the execution time, the more slippage can increase or become difficult to predict. If slippage exceeds the user’s tolerance, the transaction fails (reverts), which becomes a direct user-experience risk.
In short, AMM-based cross-chain swaps have the following structural limitations:
Dependence on destination-chain liquidity
Slippage transmission driven by liquidity volatility
Increased price impact and execution-failure risk for large trades
These limitations make it structurally difficult to meet the execution requirements demanded in payments, institutional, and commercial use cases.
1.2 Differences in Requirements: Trading Swaps vs. Payment/Commercial Swaps
The limitations of AMM-based structures stem from the fact that execution requirements differ by transaction intent. In trading-centric swaps, price volatility and execution risk are assumed; users manage these risks by setting slippage tolerance, splitting execution, and so on.
In contrast, payment and commercial swaps prioritize predictability of outcomes. The essence of a payment is “how much arrives if I pay X,” which directly ties into invoicing, settlement, accounting, and customer support. In this environment, slippage is not merely a cost fluctuation—it functions as an operational risk.
Therefore, in payments and commerce, price finality tends to matter more than best execution price; eliminating slippage (or making it highly predictable), and ensuring fee stability and controllability become primary conditions. In particular, fees are close to “market costs” in trading, but in commerce they must be designed as policy variables.
However, in AMM-based cross-chain swaps, exogenous factors—chain gas, liquidity conditions, routing paths, network congestion—combine and cause total costs to fluctuate continuously. Even if a service provider designs a policy-based fee model, it is structurally difficult to control realized execution costs.
As a result, AMM-based cross-chain swaps may be effective for trading, but structural mismatches grow as they expand into payments, institutional, and commercial use cases.
2. Structural Limitations of AMM-Based Cross-Chain Swaps
2.1 Characteristics of the Permissionless Liquidity Model
An AMM is a mechanism that forms prices via liquidity pools without an order book. Anyone can provide liquidity, and traders swap directly against the pool. In this structure, execution quality is strongly dependent on pool depth and asset distribution.
In order-book markets, external quotes exist. In AMMs, the pool state itself is the price. At the moment a trade occurs, the price is simultaneously re-formed; execution and price formation are coupled within the same mechanism. This property is advantageous for automated trading, but becomes a structural constraint in payment and commercial environments that require control over final received amounts.
2.2 Structural Causes of Liquidity Volatility and Slippage
AMM prices are determined by the ratio of two assets deposited in the pool. A representative AMM is designed to preserve x × y = k, so when a trade happens, reserve ratios shift immediately and the price moves. Slippage is therefore not an exception—it is a structural outcome.
Slippage is influenced by pool liquidity size and trade volume. As trade size grows, the magnitude of price movement increases, and because of the curved pricing function, the average execution price becomes progressively worse relative to the user’s expected price as the trade proceeds. As market volatility increases, the gap between external market prices and the price formed in the pool widens further.
2.3 Lack of Price Finality and Limits for Large Trades
In AMMs, the impact of the price curve grows quickly as trade size increases. Small trades see limited price movement, but as volume grows, the same incremental trade causes a much larger price change than before. As a result, the average execution price deviates significantly from the user’s expected price.
While splitting execution or setting slippage limits can mitigate this, in cross-chain environments, additional delays and route complexity increase failure risk. Ultimately, for large trades, it becomes difficult to predict both price conditions and execution success at the same time.
2.4 Constraints on Fee and Business-Policy Design
In commercial environments, fees should function as policy variables. However, in AMM-based swaps, total cost is dependent on pool structure and market conditions. When cross-chain execution is combined, gas and execution costs accumulate and the cost structure becomes more complex.
Even for the same swap request, costs vary by timing and network state, making fixed fees or policy-based fees difficult to design and maintain. In payment and commercial settings, this volatility directly increases settlement complexity and customer-support burden.
2.5 Structural Mismatch for Payment, Institutional, and Commercial Use Cases
In payment, institutional, and commercial swaps, finality conditions matter more than best price. Variability in received amount, price impact during large executions, and cost fluctuations driven by exogenous variables make invoicing, settlement, and accounting unstable.
From this perspective, AMM-based cross-chain swaps structurally embed slippage and price impact, and cross-chain settings add execution delays and multi-step cost structures. Accordingly, payment and institutional use cases derive the following requirements:
Firm quote (price finality)
Slippage elimination or predictability
Fee stability and controllability
Trust in the execution structure
These requirements explain why RFQ and intent-based execution models—covered in the next section—are gaining traction.
3. Cross-Chain Execution Requirements from the Payment and Institutional Perspective
In payment, institutional, and commercial use cases, cross-chain swaps must operate not merely as an asset exchange function, but as execution infrastructure where price, conditions, and outcomes are defined in advance and executed reliably. The core requirements are predictability of results and trustworthiness of execution. From this perspective, AMM-based models face constraints in meeting these requirements.
The requirements can be summarized into four key conditions.
3.1 The Need for Firm Quotes (Pre-Execution Finality)
In payment and institutional environments, the result must be finalized before execution. The essence of payment is “how much arrives if I pay X,” which directly connects to invoicing, settlement, and accounting. Therefore, payment and commercial swaps require a firm quote structure where received amount and conditions are clearly agreed upon at the quoting stage.
In AMM-based swaps, quotes are derived from pool state and assume that execution outcomes may change during execution. This creates a potential gap between quote and fill, leading to settlement mismatches and operational risk in payment and institutional environments. As a result, in these use cases, pre-agreed final conditions take priority over real-time market price.
3.2 Slippage Elimination or Predictability (Execution Stability)
Even if a price is finalized in advance, risk remains if execution outcomes fluctuate during execution. Slippage refers to the divergence between expected and actual outcomes due to changes in external liquidity conditions or market volatility, which can trigger downstream costs such as payment mismatches, refunds, and additional reconciliation.
Therefore, from a payment and institutional standpoint, slippage must be structurally eliminated, or at minimum bounded within a precisely predictable range prior to execution. Any structure where outcomes vary depending on network state or liquidity changes is unsuitable for commercial operations. Simply widening slippage tolerance may reduce failures, but it weakens finality and consistency of outcomes, making it an insufficient solution.
3.3 Fee Policy Stability and Controllability (Policy Control)
In payment and commerce, fees are not merely execution costs; they are components of service policy. Fees are intentionally adjusted based on promotions, customer tiers, channel strategy, and settlement structure, and must remain predictable at the time of transaction. Fee consistency directly impacts user trust and also ties into reconciliation, accounting, and operational efficiency.
However, in AMM-based cross-chain swaps, total cost is determined by multiple exogenous variables such as chain gas, liquidity conditions, execution routes, and network congestion. Thus, even if a provider sets a policy-based fee, realized execution cost inevitably changes by transaction timing. In payment and institutional settings, this volatility increases reconciliation complexity and operational burden, constraining the ability to use fees as policy variables.
3.4 Trust Requirements for the Execution Structure (Clear Accountability and Attribution)
In payment and institutional use cases, it is not only the outcome that matters but also how the transaction is executed—under what conditions and rules. The mechanism for validating execution conditions, criteria for success and failure, and the attribution and handling of funds in failure scenarios must be defined in advance. This is a trust requirement for operational and risk-management purposes, beyond technical stability alone.
In cross-chain environments, as execution steps increase, failure points multiply. If a transaction halts mid-process or becomes ambiguous, payment and institutional environments cannot accept it. Therefore, the structure must clearly define pre-execution condition verification, fund movements based on execution outcome, refund behavior on failure, and accountable parties.
4. Squid CORAL Overview: An Intent-Based RFQ Execution Layer
Squid CORAL is a protocol that frames cross-chain swaps not as a simple exchange function, but as an execution layer that executes trades based on pre-defined conditions. Instead of AMM-based price discovery, CORAL adopts a structure that first finalizes price and conditions based on user intent, then executes accordingly.
To achieve this, CORAL uses an RFQ (Request-for-Quote) execution model. Users specify the asset to exchange, source and destination chains, and trade conditions, while market participants provide quotes that satisfy those conditions. Conditions are finalized before execution, and execution follows the pre-agreed terms.
This design is intended to satisfy the requirements of payment and institutional environments: price finality, execution stability, fee-policy controllability, and trust in execution.
4.1 RFQ-Based Price Finalization
In CORAL, prices are not calculated from liquidity pool states. Multiple market participants submit quotes for a user’s trade intent, and the price is determined via an RFQ process where a qualifying quote is selected. The price is finalized before execution and does not change during execution.
In this structure, price volatility risk is not passed to the user. The quoting participant assumes price risk, and the user receives outcomes according to pre-agreed terms. This differs from AMM-based models where quote/execution divergence, slippage tolerance settings, and execution failure risk are inherent.
Through RFQ-based execution, Squid CORAL presents a cross-chain swap model that satisfies the payment and institutional requirement of finalized execution outcomes.
4.2 Pre-Agreement on Trade Size and Conditions
In CORAL, execution conditions—trade amount, output asset, destination chain, recipient address—are defined and agreed upon in advance. Unlike AMMs, where large trades are affected by price curves, CORAL incorporates trade size directly into the RFQ process and treats it as part of execution conditions.
As a result, large trades do not require compensating mechanisms such as split execution or slippage limits. Conditions are finalized prior to execution, and execution applies those conditions as-is. This makes CORAL suitable for use cases requiring consistent outcomes: large payments, institutional transfers, and commercial settlement.
In effect, CORAL enables predictable and controllable cross-chain execution by allowing trade size and conditions to be agreed upon before execution.
4.3 Slippage Elimination and Fee-Policy Design
CORAL is designed to keep outcomes predictable without slippage. Because price and conditions are finalized before execution, external liquidity changes or market volatility do not affect outcomes during execution. Slippage is therefore not a separate parameter to manage—it is eliminated at the level of execution design.
Fees are also not determined indirectly by liquidity conditions or congestion. Transaction costs are either included in the quoted price or explicitly specified during the RFQ stage, enabling service providers to design policy-based fees. Fee adjustments for promotions, customer tiers, and channel strategies are not undermined by execution-cost volatility.
Squid CORAL presents a cross-chain swap model that satisfies the requirement of finalized execution outcomes in payment and institutional environments through RFQ-based execution.
5. Conclusion: Payment and Institutional Demand Is Redefining the Standard for Cross-Chain Swaps
5.1 Summary of the Applicability Limits of AMM-Centric Cross-Chain Swaps
As discussed, AMM-based cross-chain swaps have served as an efficient baseline solution in trading-centric environments. However, as multi-chain ecosystems expand and cross-chain swaps extend into payment, institutional, and commercial use cases, their limitations become clearer.
AMMs depend on destination-chain liquidity, and that volatility transmits into slippage and price impact. As trade size grows, dispersion of outcomes increases, and cross-chain delays and complex cost structures further weaken predictability. In addition, because total cost is driven by exogenous variables—gas, liquidity state, network congestion—structural constraints emerge in designing and maintaining fees as policy variables.
These limitations are not simply about whether AMMs are “better” or “worse,” but are best interpreted as a fit problem between AMM execution properties and the requirements of payment and institutional environments. In these environments, outcome finality, execution stability, and cost controllability take priority—areas that AMM-based cross-chain swaps are structurally unable to satisfy.
5.2 The Execution-Model Shift Proposed by CORAL
Squid CORAL defines cross-chain swaps as an execution model that enforces pre-defined trade conditions. Through an RFQ and intent-based model, each trade becomes an execution unit that must satisfy user intent and conditions.
In CORAL, price, trade size, output asset, and execution conditions are agreed upon before execution, and execution applies those conditions as-is. Slippage and outcome variability are designed not to occur structurally. In addition, costs are explicitly presented during quoting, minimizing divergence between policy-based fees and realized execution costs.
As a result, CORAL satisfies the four key requirements of payment and institutional environments—firm quotes, execution stability, fee controllability, and a clear execution structure with explicit accountability—within a single coherent model.
5.3 Squid CORAL Positioning and Strategic Implications
Squid CORAL implements a cross-chain execution layer that meets the execution requirements of payment and institutional environments. CORAL’s core value is not merely providing an exchange function, but serving as execution infrastructure that consistently links trade conditions to execution outcomes.
By designing user experience such that execution volatility does not directly surface to end users, CORAL provides a foundation for service providers to design transaction conditions and fees as policy variables. Cross-chain swaps are treated as settlement-ready transaction units, and the execution process consistently reflects the agreed conditions.
In summary, the standard for cross-chain swaps is shifting toward execution structures that can reliably execute condition-finalized trades. Squid CORAL represents an implementation of this shift—providing a reference point for extending cross-chain swaps into execution infrastructure that can operate in payment, institutional, and commercial environments.
Key References
Squid Docs - Coral: Intent Swaps
Squid's Cross-Chain Order Routing and Auction Layer: CORAL
Other References
What is an Automated Market Maker? | Uniswap Labs
Understanding Automated Market-Makers, Part 1: Price Impact - Paradigm
Disclaimer
The contents of this report are for informational purposes only and do not constitute a recommendation or basis for legal, business, investment, or tax advice under any circumstances. References to specific assets or securities are for informational purposes only and do not represent an offer, solicitation, or recommendation to invest. The final responsibility for any investment decisions lies solely with the investor, and this report should not be used as a guideline for accounting or legal judgment.
As a matter of principle, the author does not trade related assets using material non-public information obtained during the research or drafting process. The author and Catalyze may have financial interests in the assets or tokens discussed herein and may serve as a strategic partner to certain networks.
The opinions and analyses expressed in this report reflect the author's personal views and do not necessarily represent the official position of Catalyze or its affiliates. All information is current as of the date of publication and is subject to change without prior notice.