Skip to main content
Pre-Release Documentation

This describes a pre-release version of LBAMM. Interfaces and behavior may change.

Verify the exact repository commit before building production integrations.

Orders

In LBAMM, every execution is an order match.

A swap submitted to the protocol is a taker order.
Liquidity available to satisfy that swap represents maker orders.

LBAMM exists to deterministically match the two.


Taker Orders

A taker order expresses intent:

  • “I am willing to provide this token”
  • “I want to receive that token”
  • “Here are my exact constraints”

The taker defines whether the swap is:

  • Input-based (swap by input amount)
  • Output-based (swap by output amount)

Nothing in the system executes passively. All state transitions begin with a taker order.


Maker Orders

Maker orders represent liquidity made available to satisfy taker intent.

Maker liquidity in LBAMM can take multiple forms:

  • Continuous liquidity exposed through pools
  • Discrete limit-style commitments
  • Signed offchain authorizations

The protocol does not assume a single liquidity model.

Instead, it treats all liquidity expressions as maker orders that can be matched against a taker’s constraints.


Matching Model

Matching in LBAMM is:

  • Deterministic
  • Single-path
  • Explicitly routed

There is no internal auction and no hidden competition inside execution.

A taker order specifies how it should be matched.
The protocol executes that path exactly.


A Shared Settlement Layer

LBAMM separates:

  • Intent (taker order)
  • Liquidity expression (maker order)
  • Settlement guarantees (core AMM)

Liquidity modules, transfer handlers, and hooks may exist as independent contracts.

What unifies them is not implementation — it is settlement.

All maker expressions, regardless of how they are implemented, ultimately resolve through the same deterministic matching and accounting guarantees provided by the AMM core.


In the following pages, we’ll explore:

  • How swaps are structured
  • How single-hop and multi-hop execution differs
  • How partial fills are defined
  • How executors and solvers interact with the protocol

Limit Break

TwitterLimitBreak.comMedium

© 2026 Limit Break International, Inc. All rights reserved.

Privacy PolicyTerms of ServiceCookie PolicyDo Not Sell My Info