This describes a pre-release version of LBAMM. Interfaces and behavior may change.
Verify the exact repository commit before building production integrations.
Security Model
This page documents the security model, trust boundaries, and delegated risk surfaces of LBAMM.
It is intended for:
- Smart contract auditors
- Teams building custom pool types
- Teams deploying hooks
- Integrators implementing transfer handlers or signed-order flows
- Security researchers
LBAMM is intentionally extensible.
Security posture depends not only on core correctness, but on how extension surfaces are implemented and configured.
This page focuses on:
- What the core guarantees
- What extension modules are responsible for
- What must always remain true
- Where risk is intentionally delegated
It does not restate pool math or hook APIs.
Architecture & Security Model
LBAMM core is:
- Invariant-agnostic
- Module-driven (pool types define swap and liquidity math)
- Hook-extensible (token, position, pool)
- Transfer-handler extensible (custom settlement flows)
- Fee-surface configurable
Core enforces structural and accounting constraints.
Execution logic is delegated to extension modules.
Security review must account for:
- Core contract logic
- All enabled pool type modules
- All enabled hook contracts
- All enabled transfer handlers
- Permit infrastructure (if used)
→ See: Protocol Fundamentals
→ See: Hooks
→ See: Fees & Economics
Trust Boundaries
Core Contract
The core contract:
- Enforces poolId structure and fee caps
- Enforces reserve and fee balance accounting
- Enforces swap and liquidity limit constraints
- Holds all pool token balances
- Executes hooks in defined order
- Delegates invariant logic to pool types
Core does not:
- Implement pricing logic
- Validate offchain orderbooks
- Sandbox extension modules
Pool Type Modules
Pool types:
- Define invariant math and price movement
- Define liquidity accounting semantics
- Must preserve reserve and fee balance correctness
Incorrect pool logic can break economic assumptions while remaining structurally valid at the core level.
Hooks
Hooks:
- May validate, revert, or impose additional constraints
- May accrue hook fees
- Execute inside the core call graph
Token hooks apply globally to a token across pools.
Hooks cannot bypass core accounting constraints, but can influence execution flow and fee behavior.
Transfer Handlers
Transfer handlers:
- Implement settlement mechanics
- May validate signatures and bind swap intent
- Must correctly report and transfer token amounts
- Must not violate fee or limit constraints
Mis-implementation can result in incorrect settlement or signature misuse.
Critical Invariants
The following properties must hold across all pool types and extensions:
- Withdrawals and swaps cannot exceed pool reserve balances
- Fee collection cannot exceed fee balances
- Swap limit constraints must be enforced
- Liquidity limit constraints must be enforced
- Execution-level fee caps must be respected
Invariant enforcement is distributed between:
- Core (structural + accounting guarantees)
- Pool types (invariant correctness)
Fee Surfaces & Configuration Risk
LBAMM exposes multiple fee surfaces:
- LP fees (pool-defined)
- Exchange fees
- Fee-on-top
- Protocol fee overrides
- Hook-managed fees
- Flashloan fees
Security review must consider:
- Mode-dependent fee caps
- Recipient binding correctness
- Interaction between hook fees and maxHookFee bounds
- Multi-hop aggregation behavior
Misconfiguration risks include:
- Excessive hook fees
- Incorrect recipient configuration
- Governance-level fee overrides
Extension Risk Model
LBAMM intentionally exposes programmable extension points:
- Custom pool types
- Custom hooks
- Custom transfer handlers
These modules:
- Execute within the core call graph
- May revert execution
- May influence settlement flow
- May influence fee attribution
LBAMM does not sandbox extensions.
Extension contracts must be reviewed with the same rigor as core.
Security posture depends on:
- Correct configuration
- Restrictive governance
- Careful review of all enabled modules
Audit Scope Guidance
Third-party audits should include:
- Core contract
- All enabled pool types
- All enabled hooks
- All enabled transfer handlers
- Fee configuration paths
- Token settings and role management
Audits should also consider:
- Signature binding in transfer handlers
- Governance permissions and upgrade surfaces
- Fee override configuration paths
Out-of-scope risks may include:
- Offchain orderbook matching logic
- Frontend enforcement assumptions
- Non-canonical PermitC deployments
Audit Reports
The following independent security audits have been performed:
-
[Auditor Name] – Audit Title – Date
- Scope: Core / Pool Types / Hooks / etc.
- Report:
-
[Auditor Name] – Audit Title – Date
- Scope: …
- Report:
Where applicable:
- Findings were addressed prior to mainnet deployment.
- Remaining issues (if any) are documented in the linked reports.
If you are conducting an independent review and require clarification, please contact: contact.