Trading

A trade on Ekubo goes through three stages: finding a route, quoting it, and executing it. Each stage is available as public infrastructure you can use directly.

Routing and quoting

Ekubo’s liquidity is spread across pool types and extensions — concentrated, stableswap, full-range, TWAMM, MEV capture, Ve33 — all inside the same Core contract. A good route often splits a trade across several of them.

The Quoter API does this for you. Given a chain, an amount, and a token pair, it returns block-pinned split routes for exact-input or exact-output swaps:

GET https://prod-api-quoter.ekubo.org/{chainId}/{amount}/{specifiedToken}/{otherToken}

A negative amount requests an exact-output quote. Token addresses and decimals resolve through the Ekubo API token list.

Because quotes are pinned to a block, they reflect exact pool state at that block — including extension behavior, which is the part hand-rolled integrations most often get wrong.

Simulation

If you need to compute quotes yourself — running your own solver, backtesting, or simulating without a network round-trip — the SDKs implement the same math the contracts do.

The Rust SDK (ekubo_sdk) is the most complete: its quoting module implements every pool type and extension, so simulated quotes match on-chain execution rather than approximating it. It is no_std-compatible, so it runs in constrained environments as well as on a server.

For pool math in TypeScript — tick and price conversions, liquidity sizing, swap steps — use @ekubo/sdk.

Execution

On EVM chains, swaps execute through the Yul Router, deployed at the same address on every supported chain. Routes are encoded with @ekubo/yul-router-sdk and sent as raw calldata — there is no swap selector, because the calldata is the route. The same route can be priced without executing it through the router’s quote(bytes) entrypoint.

The router executes every split of a trade under a single Core lock, aggregates the amounts, applies one slippage check against the total, and settles token transfers once. This is what makes multi-pool routing on Ekubo cheap: flash accounting means intermediate hops never touch the token contracts.

Trading from your own contract on either chain follows the same lock-and-callback flow — see Swapping.

Trade types beyond spot

• DCA orders — sell a token gradually over a period, netted against opposing orders, using the TWAMM extension
• Limit orders (Starknet) — narrow positions one tick spacing wide (128 ticks) that execute at a chosen price and are pulled automatically once filled
• Signed exclusive swaps — RFQ-style pools where a market maker signs each quote off-chain with its own fee and bounds

MEV capture

The MEV capture extension charges an additional fee on swaps that move a pool’s price significantly, and directs that value back to the pool’s liquidity providers rather than to searchers. Pools using it are routed and quoted like any other pool.

How MEV capture fees are credited

MEV capture holds its additional fee in the pool and credits it to liquidity providers at the first interaction with the pool in a later block timestamp. On chains with sub-second blocks, several blocks can share one timestamp. The credit goes to the liquidity that is active at the pool price at that moment, not to the liquidity the surcharged swap traded through. Positions added in the same block timestamp after a surcharged swap share in that swap’s additional fee, and positions removed in that timestamp do not. If the price was left in a range with no liquidity, that amount is not credited to anyone. A position near the edge of the active range can therefore receive more or less than its share of a given swap’s additional fee, in some cases all of it or none of it. Ekubo estimates that from June 2025 to October 2026 this affected about 0.15% of the additional fees paid out, with no sign of deliberate exploitation. That is a historical estimate, not a limit. Deployed MEV capture extensions cannot be changed, so this applies to every existing MEV capture pool.