Why We Built the Limit Break AMM

Public Audit Starts Soon

The Limit Break AMM (LBAMM) public audit competition will begin on February 23rd with $150,000 in rewards available to security researchers.

The public audit period will provide builders their first look into the protocol’s capabilities, including the full codebase and preliminary technical documentation to help researchers and developers follow along. Additional technical writeups and integration examples will be shared throughout the audit period.

LBAMM has already undergone three independent audits during development, including one by Omniscia and two by Guardian Audits. The Guardian engagement also included the development of a comprehensive fuzz testing suite to stress critical execution paths and invariant assumptions. The public competition represents the next stage of review, expanding scrutiny beyond private engagements and inviting open evaluation from the broader security community.

This marks an important milestone, not just for LBAMM, but for a broader shift in how tokens behave in decentralized systems.

Tokens Changed. Markets Didn’t.

Uniswap and other early AMMs established a framework where tokens were reduced to interchangeable balances inside liquidity pools, and price was determined purely by deterministic liquidity formulas. That model worked because early tokens behaved like commodities. They moved freely and carried no expectations beyond ownership. For nearly a decade, Uniswap and the AMMs that followed defined how onchain markets operate.

However, modern tokens express intent, react to context, and increasingly participate directly in application logic. They influence access, incentives, ownership, and how value is allowed to move. Yet most liquidity infrastructure still treats tokens as passive assets.

Modern tokens demand capabilities that existing AMM architectures fundamentally cannot provide.

Limit Break encountered this directly while developing Apptokens. Apptokens embed capabilities that govern how they transfer, trade, and participate in liquidity. Identity, permissions, fees, timing, and external signals can all influence execution. Instead of acting as inert balances, tokens become active participants in the applications they power.

This introduces a simple but uncompromising requirement:

Token behavior must hold everywhere the token is used.

Once accepted, several system requirements follow naturally:

• token behavior must apply to every interaction, not just selected paths
• tokens must receive sufficient execution context to make decisions
• liquidity cannot become a mechanism for bypassing token logic
• guarantees cannot rely on opt-in integrations and must hold across chains
• capabilities must evolve without breaking standard tooling

What made traditional AMMs successful also defines their boundary: they assume tokens adapt to markets. Apptokens reverse that assumption.

LBAMM was built to resolve this mismatch.

What Is LBAMM?

LBAMM is programmable liquidity infrastructure built for tokens with logic.

If you’ve followed Limit Break’s AMM work before, this will be a refresher. If you’re new, this is a concise overview of what LBAMM is and why it exists.

It provides a consistent execution model that spans swaps, liquidity provisioning, and routing, preserving token behavior across the full lifecycle of a transaction. In LBAMM, markets are treated as programmable systems rather than passive reserves.

Hooks exist at the token level, the liquidity position level, and the pool level, with rich execution context passed through every operation. This allows tokens and pools to influence execution directly, while liquidity positions participate through enforceable conditions governing how liquidity is added, constrained, and removed, all guaranteed by the protocol.

LBAMM supports multiple execution patterns under this model, including:

• Swaps executed against liquidity pools.
• Swaps that combine liquidity pools with offchain signed orders or onchain orderbook-style markets.
• Direct peer-to-peer swaps using offchain signed orders or onchain orderbook-style markets.

Crucially, LBAMM is not locked into a single liquidity design. It supports multiple pool types, including concentrated price liquidity, asymmetric fixed-price liquidity, and fully custom, hook-controlled markets. New liquidity designs can be introduced over time without changing how enforcement works or how execution is reasoned about.

Fees are first-class and enforceable at execution time, spanning liquidity provider fees, token-imposed fees, exchange fees embedded in orders, and executor fees for routed fills. This gives token issuers and builders precise control over economic flows.

All of this works without custom routers, privileged deployers, or breaking standard tooling. LBAMM is self-service and deployable anywhere, with consistent execution semantics across environments.

For a deeper dive into LBAMM’s execution model, liquidity designs, and market structures, see the original announcement post here.

The Architectural Mismatch

AMMs were designed to optimize for price discovery, capital efficiency, and composability. They were never designed to participate in token enforcement.

At a structural level, they accept tokens and emit tokens. There is no native concept of global token policy, no guaranteed execution context, and no protection against enforcement being bypassed through liquidity mechanics.

That model works when tokens are inert and interchangeable. It breaks down when tokens carry intent.

For programmable tokens, this is not a missing feature or an integration gap to be filled. It is a fundamental architectural mismatch between how tokens are expected to behave and how AMMs are built to operate.

Why Uniswap V4 Can’t Be the Foundation

Uniswap V4 is the closest existing AMM design to what programmable tokens require, which makes its limitations especially instructive. Its hook system is powerful and well designed, and we evaluated it in practice as a potential foundation for Apptokens.

However, its extension model is scoped to individual pool behavior, while Apptokens require token-level guarantees that hold across all venues by default. That difference in scope is decisive.

The sections that follow outline where this mismatch becomes concrete and why it cannot be resolved through hooks, routers, or surrounding infrastructure.

Pools Aren’t a Control Boundary

Uniswap V4 hooks are scoped to individual pools, while tokens exist and interact across many pools.

There is no canonical way for a token to assert which hook represents its intent, nor any guarantee that a pool interacting with the token will have a hook at all. As a result, tokens cannot ensure their policies are applied consistently across execution paths.

This limitation becomes more severe when two programmable tokens are paired together. In traditional AMMs, there is no reliable way to reconcile multiple token intents, so one or both are implicitly overridden or bypassed during execution.

For programmable tokens, conditional enforcement is indistinguishable from no enforcement.

LBAMM resolves this by establishing a clear control boundary: each token’s invariant behavior is preserved, and shared market logic is defined explicitly rather than emerging implicitly from pool configuration.

No Reliable Execution Context

Swaps in Uniswap V4 do not carry sufficient context for token-level decision making without introducing custom routers.

Critical information about intent, origin, downstream settlement, and aggregation is not available by default at the hook layer.

Recovering that context requires rebuilding routing infrastructure outside the core protocol.

Once that happens, compatibility with standard tooling degrades. Execution paths fragment, and the assumption that wallets, aggregators, and analytics work uniformly no longer holds.

Without context-aware execution, token logic cannot be treated as a property of the system.

LBAMM addresses this by making execution begin inside the AMM itself. Origin, executor, and routing context are preserved by default, allowing hooks to make decisions based on actual execution truth rather than inferred behavior.

Liquidity Bypasses Intentions

In traditional AMMs such as Uniswap V4, liquidity positions are freely transferable abstractions representing underlying tokens. There is no mechanism for tokens to defend their intended behavior on liquidity transfers, nor a clear answer for which token’s policies should apply.

More critically, tokens do not need to leave the AMM after a swap. They can settle directly into a new pool, including one with no hooks at all, either as part of another swap or as newly minted liquidity.

From the token’s perspective, enforcement fails at the exact moment value is being recomposed.

LBAMM changes this by treating liquidity positions as first-class, policy-aware state rather than transferable claims. Liquidity is added, consumed, and removed through explicit execution paths where token, pool, and position conditions are applied, rather than being abstracted into freely movable representations.

This makes liquidity a programmable surface rather than a bypass vector, enabling designs like locked positions, vesting liquidity, and application-scoped markets without relying on external wrappers or custom routers.

Liquidity Design Becomes Lock-in

Uniswap V4 is architecturally coupled to its concentrated liquidity model. While hooks allow additional behavior to be layered on top, the underlying assumptions about how liquidity is added, consumed, and accounted for remain fixed.

If a token issuer wants to trade using a different liquidity design, such as fixed-price bands, oracle-informed pricing, application-specific curves, or future models that do not yet exist, the enforcement stack must be rebuilt alongside that liquidity model.

For programmable tokens, where market structure is part of the token’s behavior, this coupling is not merely limiting. It is incompatible.

LBAMM avoids this by separating execution and enforcement from liquidity design, allowing new pool types to be introduced without changing token behavior or how execution is understood.

Where Token Capabilities Cannot Reach

Uniswap deployments are limited to the blockchains the protocol chooses to support, tying market access to governance decisions and curated chain lists.

Apptokens are chain agnostic by design. When liquidity infrastructure is selectively deployed, token issuers are forced to trade global reach against the preservation of their token’s capabilities, or fragment their markets across environments with different behavioral assumptions.

This reintroduces a dependency programmable tokens are meant to remove: reliance on external governance to preserve how a token behaves.

LBAMM is deployable anywhere without permission, ensuring that token capabilities travel with the token and are not constrained by curated deployments or protocol governance.

The Cost of Making It Work

Addressing these limitations inside an architecture not designed for enforcement requires rebuilding large portions of the surrounding stack:

• Custom routers to recover missing execution context.
• Custom position managers to impose policy on liquidity.
• Custom enforcement layers to approximate token-level guarantees.

Even with that effort, enforcement remains partial, brittle, and difficult to reason about.

At that point, you are no longer building on Uniswap V4. You are building around it. Core assumptions remain unchanged, while complexity accumulates at the edges. The audit surface expands, enforcement guarantees weaken, and compatibility with standard wallets, routers, and aggregators erodes.

The result is a fragmented execution model that is harder to reason about, harder to audit, and increasingly disconnected from the composable paths that make DeFi usable.

LBAMM was built to show that this tradeoff is unnecessary. Programmable markets can be enforced directly at the protocol level, without sacrificing composability or standard tooling.

Case Studies: When Markets Undermine Strategy Tokens

The enforcement gap described above is not theoretical. It has already cost projects material strategic value.

Two recent examples illustrate the pattern.

PunkStrategy (PNKSTR)

PNKSTR launched as a strategy token with a 10 percent trading fee. That fee was used to buy and relist CryptoPunks, compounding value back into the ecosystem.

The model only works if the fee is applied everywhere the token trades.

It wasn’t.

Alternative pools emerged with lower fees, paid solely to liquidity providers and not the PNKSTR protocol. Those pools processed over $50 million in volume. If even half of that activity was organic, the protocol treasury could have acquired roughly 60 percent more CryptoPunks.

Instead, volume was siphoned into parallel markets that ignored the strategy.

No exploit was required. No vulnerability was triggered. The architecture allowed the bypass.

The team later launched TokenStrategy to generalize the model across NFT collections and introduced transfer restrictions to defend fee logic. But those protections rely on routing assumptions, specifically that trades through the strategy pool will settle as transfers out of the AMM. Instead, trades can settle directly into alternative pools that wrap the strategy token and divert volume away from the intended venue, paying fees only on initial entry and on periodic arbitrage back to the primary pool, rather than on the full volume the strategy was designed to capture.

DEATHSTR

DEATHSTR followed a similar model and encountered a more severe outcome.

Alternative pools diverted enough trading volume that the team ultimately relaunched the token with additional transfer restrictions.

The token and hook contracts are not verified but decompiled logic suggests the enforcement mechanism itself is bypassable by routing a minimal dust transfer through the original pool before settling in a lower fee venue using a custom hook configuration.

Whether that specific bypass is practical is almost secondary.

The real issue is structural.

When enforcement depends on predicting every possible liquidity configuration, the attack surface becomes economic rather than technical. If a cheaper path exists, capital will find it.

The Pattern

In both cases:

• The token’s economic model depended on a global trading fee.
• Liquidity was permissionless and unconstrained.
• Alternative pools emerged that weakened or bypassed enforcement.

These were not hacks. They were responses to incentives in a system that does not treat token behavior as a first-class invariant.

The markets optimized for lower fees. The strategy optimized for treasury growth. The markets won.

PNKSTR and DEATHSTR are not anomalies. Every trading tax token has failed for these same reasons and these are two of the latest.

What LBAMM Changes

Under LBAMM, strategy tokens define their trading invariants at the execution layer:

• What assets they can be paired with
• What the fee rate is
• Which side pays it
• Where that fee is routed
• Who may provide liquidity and under what conditions

Those rules apply globally across swaps, routing, and liquidity actions. Alternate pools cannot silently dilute the strategy.

Enforcement is not delegated to social coordination or router discipline. It is part of execution itself.

For tax-based or strategy tokens, this reduces the economic bypass surface to the protocol’s execution model. There are no parallel venues that can erode the intended mechanics.

Markets remain permissionless. Strategy remains enforceable.

That is the difference.

Looking Ahead

LBAMM was designed to make programmable markets possible in practice.

Its architecture is intentional, its invariants are explicit, and its execution semantics are consistent across swaps, liquidity actions, and routing. Market behavior is defined within execution itself, not inferred from emergent pool mechanics or external assumptions.

The upcoming public audit is an invitation to examine that claim in the open, not as an extension of legacy AMMs, but as a purpose-built execution layer where programmability is enforced by the execution model itself.

If programmable tokens are to exist everywhere they are used, the markets they trade in must be programmable as well.

LBAMM is that layer.