This describes a pre-release version of LBAMM. Interfaces and behavior may change.
Verify the exact repository commit before building production integrations.
Design Goals & Guarantees
This page states the protocol-level contract LBAMM is designed to uphold: what it makes possible, what integrators can depend on, and what is explicitly not guaranteed.
It is not a security analysis (see Security Model), and it is not a replacement for detailed behavioral specifications in later sections. It defines the boundary of what you can safely build on.
Design goals
One execution model across all actions
Swaps (single-hop, multi-hop, and direct), liquidity actions, pool creation, and flash loans share the same execution framing and context semantics. This makes policy reusable and predictable across “how value moves,” not just “which pool you touched.”
Non-spoofable, minimal execution identities
LBAMM keeps execution identities minimal and explicit:
- Executor is the LBAMM caller (
msg.sender). - Recipient is surfaced where relevant (e.g. swaps).
Policy is explicit, composable, and scoped
Policy attaches at the correct layer:
- Token hooks for token-global guarantees
- Pool hooks for venue/pool-wide constraints
- Position hooks for position-scoped constraints (lockups, vesting, operator flows, tranche rules)
LBAMM enforces the execution framework; hooks define the policy. This is “policy as first-class,” but still opt-in via configuration choices.
Liquidity mechanics are modular without breaking enforcement
Pool types define liquidity/pricing mechanics, but the enforcement model and execution semantics remain stable across pool types. New market designs should not require reinventing how context and policy are enforced.
Fee surfaces are explicit and bounded
LBAMM is designed so integrators can reason about “what you pay”:
- Execution-level fees apply once per execution (even in multi-hop).
- Hop-level fees apply per hop.
- Hook fees are bounded in liquidity flows and are settled in a controlled way.
Protocol-level guarantees
From the design goals above, the following properties hold:
Single execution context per top-level call
Every top-level call into LBAMM core constructs exactly one execution context that is shared across all pools, hooks, and internal logic for the duration of the call.
Atomicity
If any required validation, hook invocation, or invariant check reverts, the entire execution reverts. No partial state transitions persist.
Deterministic hook invocation surface
Hooks are invoked at defined execution points with a consistent context model. Core does not conditionally skip hook surfaces based on routing path.
Core-enforced settlement authority
LBAMM core owns reserves and performs settlement. Pool types and hooks do not custody reserves independently.
Policy attachment at defined scopes
Policy attaches only at defined surfaces:
- Token scope
- Pool scope
- Position scope
Core enforces the execution framework; hooks define policy within that framework.
Explicit non-goals and non-guarantees
LBAMM intentionally does not guarantee:
Economic outcomes
LBAMM does not guarantee profitability, fair pricing, liquidity depth, or protection against adverse market conditions.
Hook safety
Hooks are external contracts. LBAMM guarantees invocation surfaces, not the correctness, gas efficiency, or safety of hook implementations.
Cross-protocol enforcement
LBAMM enforces policy within its own execution model. It does not enforce behavior in external AMMs, bridges, or off-protocol transfers.
Absence of revert
Hooks may revert based on custom policy. Integrators must assume that any operation may revert if policy conditions are not satisfied.
Backward compatibility of custom pool types
While core execution semantics are stable, custom pool types must conform to interface expectations. Incorrect implementations can violate expected economic behavior.
Trust boundaries (who you are trusting)
LBAMM’s modularity is a power tool. It also means risk is delegated.
- Core AMM: trusted for custody, accounting, context construction, and enforcement of bounds/invariants.
- Token hooks: trusted by anyone interacting with that token (token-global policy surface).
- Pool hooks: trusted by pool creators and pool participants (venue-wide policy surface).
- Position hooks: trusted by position providers (position-scoped policy surface).
- Pool types: trusted by pool creators/LPs for liquidity math and position semantics; core remains the balance authority.
(See Security Model for the full risk surface taxonomy.)
Practical guidance for integrators
If you are building a router / aggregator
- Assume you are the executor (hooks will see you as
msg.sender). - Prefer designs that keep LBAMM as the top-level call when possible to avoid executor-policy conflicts.
- Treat hook reverts as expected behavior; build fallbacks and quote-time simulation accordingly.
If you are integrating non-trivial tokens
- Read token hook configuration first; it defines what must be enforced.
- Assume token behavior can affect swaps, liquidity actions, and order settlement.
If you are authoring hooks
- Treat your hook as part of the protocol’s trust surface: document revert conditions, fee behavior, and any external dependencies.
- Keep work bounded and deterministic; design for multi-hop composability.