Skip to main content

​
Introduction

Swaps are the most common way of interacting with Ramses. For end-users, swapping is straightforward: a user selects an ERC-20 token that they own and a token they would like to trade it for. Executing a swap sells the currently owned tokens for the proportional1 amount of the tokens desired, minus the swap fee. That fee is routed according to the pool’s configuration.2 Swapping with Ramses is a permissionless process.
note: Using web interfaces (websites) to swap via Ramses can introduce additional permission structures, and may result in different execution behavior compared to using Ramses directly. To learn more about the differences between the protocol and a web interface, see “What is Ramses?”
Swaps using Ramses are different from traditional order book trades in that they are not executed against discrete orders on a first-in-first-out basis — rather, swaps execute against a passive pool of liquidity. LP fee eligibility depends on the pool model, the liquidity active at the executed prices, and the pool’s configured fee routing.

​
Pool Models

Ramses supports more than one execution model:
  • Concentrated-liquidity swaps move through active tick intervals
  • DLMM swaps execute at one fixed-price bin at a time and cross to the next non-empty bin when needed
A direct DLMM pool quote can be partial when the selected pool runs out of traversable liquidity. Reject getSwapOut() when amountInLeft != 0, and reject getSwapIn() when amountOutLeft != 0. The DLMM router handles DLMM-only paths. A mixed route that combines DLMM with concentrated-liquidity or Legacy pools requires a higher-level router or separate transactions; do not encode mixed pool types into DLMMRouter.Path.

​
Price Impact

In a traditional order-book market, a sizeable market-buy order may deplete the available liquidity of a prior limit-sell and continue to execute against a subsequent limit-sell order at a higher price. The result is the final execution price of the order is somewhere in between the two limit-sell prices against which the order was filled. Price impact affects the execution price of an AMM swap through model-specific mechanics. In a curve-based pool, the marginal price shifts continuously as the trade consumes liquidity. In a DLMM pool, execution stays at one fixed price inside a bin and changes discretely when the trade crosses bin IDs. Either path can produce an average execution price different from the starting price. As the amount of liquidity available at different price points can vary, the price impact for a given swap size will change relative to the amount of liquidity available at any given point in price space. The greater the liquidity available at a given price, the lower the price impact for a given swap size. The lesser the liquidity available, the higher the price impact. Approximate3 price impact is anticipated in real-time via the Ramses interface, and warnings appear if unusually high price impact will occur during a swap. Anyone executing a swap will have the ability to assess the circumstances of price impact when needed.

​
Slippage

The other relevant detail to consider when approaching swaps with Ramses is slippage. Slippage is the term we use to describe alterations to a given price that could occur while a submitted transaction is pending. When transactions are submitted to an EVM network, inclusion and ordering depend on that network’s sequencer or validator rules. While a transaction is pending, other swaps can change pool reserves, the active tick or bin, and the applicable fee. Slippage tolerances establish a margin of change acceptable to the user beyond price impact. As long as the execution price is within the slippage range, for example 1%, the transaction will execute. If the execution price ends up outside the accepted range, the transaction will fail and the swap will not occur. A comparable situation in a traditional market would be a market-buy order executed after a delay. One can know the expected price of a market-buy order when submitted, but much can change in the time between submission and execution.

​
Safety Checks

Price impact and slippage can both change while a transaction is pending, which is why we have built numerous safety checks into Ramses to protect end-users from drastic changes in the execution environment of their swap. Some of the most commonly encountered safety checks:
  • Deadline exceeded: The transaction reverts after its deadline. CL and Legacy integrations may surface Expired; the DLMM router uses LBRouter__DeadlineExceeded.
  • Minimum output not met: The transaction reverts when execution would return less than the configured minimum. Legacy integrations may surface INSUFFICIENT_OUTPUT_AMOUNT; the DLMM router uses LBRouter__InsufficientAmountOut.

​
Additional resources

Footnotes

  1. Proportional in this instance takes into account the relative price, fee, slippage, price impact, and other factors in an open and adversarial EVM environment. ↩
  2. Fee-only and gauged pools use different fee routing. See Fees. ↩
  3. The Ramses interface informs the user about the circumstances of their swap, but it is not guaranteed. ↩