Skip to main content
Logo
DocsCookbooksToolsTestnet

AMM Cookbook

The AMM Cookbook is a developer resource for designing programmable liquidity, trading logic, and market access using the Limit Break AMM (LBAMM).

Built from the ground up for customization, Limit Break AMM supports hooks at the token, pool, and position level, giving developers full control over how assets are traded, how fees are collected, and who can access liquidity.

Apptokens are at the heart of this system. By enforcing transfer rules and permitting token movement through approved operators, Apptokens ensure tokens can only be traded through authorized protocols like LBAMM. This gives developers confidence that their fee, access, and reward logic can’t be bypassed by routing trades through other AMMs or OTC.

This document outlines a wide range of programmable AMM patterns, from dynamic fees and swap gating to custom market-making strategies. Each entry introduces a novel design, the use case it serves, and how it can be implemented using Limit Break’s programmable infrastructure.

This list is non-exhaustive. As developers continue to build new primitives on top of the protocol, the design space will expand and unlock entirely new categories of trading and liquidity behavior.

Categories​

  1. Fee Design Patterns
  2. Swap Access & Reward Mechanics
  3. Liquidity Access & Incentives
  4. Market Making & Price Control

Fee Design Patterns​

Fee Design Patterns describe how fees can be customized, routed, and segmented across tokens, pools, and users. These patterns enable developers to design tokenomics that reward long-term users, penalize bots, generate protocol revenue, or fund ecosystems in novel ways.

Fee Design Patterns

What new opportunities do fee design patterns unlock?​

Ensure fee integrity through approved execution paths​

How can tokens ensure fees are consistently applied across venues?​

Apptokens can authorize specific operator contracts, such as LBAMM, so trades are executed through paths where hooks apply fee, reward, and policy logic. This guarantees consistent, predictable economics while preserving composability.

For example:

  • A token $ROYALTY routes 1% of swap value to the protocol treasury.
  • As an Apptoken, it authorizes transfers through LBAMM pools (and other approved operators) where fee logic is applied automatically.
  • All valid transfers execute via these sanctioned paths, ensuring the treasury receives its share and token rules are honored.

Reduce trading fees the longer a token is held​

How can tokens reduce trading fees over time?​

Tokens can be implemented with dynamic fee logic that rewards long-term holders by decreasing trading fees based on how long the token has been held.

This unlocks a powerful alignment between holders and the long-term goals of a protocol or product, as users are financially incentivized to delay selling. Developers can configure fee decay curves to match product retention goals or market stabilization needs.

For example:

  • A protocol launches a token, $HOLD, that accrues utility value in the ecosystem over time.
  • The token is implemented with time-sensitive fee logic - 5% fee if held < 24 hours, 2% fee if held < 7 days, 0.5% if held longer.
  • Speculators who immediately trade the token incur a high fee, while loyal users enjoy near-free trades.
  • Trading volume stabilizes over time and aligns with long-term user growth.

Take fees in the paired token​

How can token trading fees be collected in the paired token?​

Instead of taking trading fees in the native token being transferred, tokens can be configured to collect fees in the paired token used for the trade. This is especially useful when the developer prefers to accumulate ETH, USDC, or another stable asset.

For example:

  • A game developer launches a token, $XP, that’s earned through gameplay and spent on upgrades.
  • When players buy $XP in a LBAMM pool paired with ETH, the developer takes a 2% fee in ETH.
  • Players receive the full amount of $XP they paid for, and the game treasury accumulates ETH for development and prize pools.

Take fees in the native token​

How can tokens charge fees in their own supply?​

Tokens can be configured to always take fees in their own native supply, even when being paired against other tokens. This design is useful when token deflation, burn mechanics, or internal redistribution are key to the tokenomics of the system.

This creates tight feedback loops where usage drives scarcity or redistribution without relying on paired token behavior.

For example:

  • A DeFi protocol launches $BURN, a governance token with a deflationary design.
  • When users sell $BURN for USDC, a 1% fee is taken in $BURN, not in USDC.
  • The fee is burned permanently, reducing supply with each swap.
  • As activity increases, the supply of $BURN decreases, creating long-term demand pressure.

Token-based fee segmentation by user attributes​

How can a token apply different fees based on who is trading it?​

Tokens can implement their own fee logic via hooks that assess attributes of the trader’s wallet. These attributes might include governance participation, reputation scores, or social graph data. The fee is enforced by the token itself, regardless of which pool it's being traded in.

This gives token creators a protocol-level tool to reward long-term holders, penalize bots, or create community-based fee tiers across all liquidity venues.

For example:

  • A token $ENGAGE is launched for a decentralized social app.
  • The token defines a fee hook that charges different fees based on wallet behavior:
    • Contributors with over 50 DAO votes: 0.1% fee
    • New wallets: 0.4% fee
    • Known bot wallets (Sybil-flagged): 1.0% fee
  • These fees apply no matter what pool the token is traded in.
  • The result: power users pay less, low-quality traffic pays more, all enforced at the token layer.

Pool-based fee segmentation by user traits​

How can individual pools charge different fees to different users?​

Pools can define custom fee logic that charges different swap fees depending on who the trader is, even if the token itself has no built-in fee logic. These hooks are set at the pool level, giving LPs or protocols granular control over how their specific liquidity is priced.

This enables powerful use cases like staking discounts, affiliate pricing, or loyalty-based pool access.

For example:

  • A LBAMM pool is created for $TOKEN / ETH.
  • The pool implements a fee hook that checks if the trader is staking $TOKEN in a rewards contract.
    • Active stakers: 0.2% fee
    • Non-stakers: 0.6% fee
  • Another pool might offer discounts to wallets holding a specific NFT.
  • Each pool sets its own logic, giving LPs control over pricing and user targeting.

Scale pool fees based on transaction size​

How can pools apply different fees to large and small trades?​

Fees can be scaled based on the size of the transaction, using predefined brackets or continuous curves. This discourages toxic flow or MEV while making small trades more affordable.

Developers can also implement premium pricing for high-volume access or subsidized micro-transactions to promote inclusivity.

For example:

  • A game studio launches $GEM with a pool designed for in-game swaps.
  • Fees scale as follows:
    • Trades under $10: 0.1%
    • Trades between $10 and $1,000: 0.4%
    • Trades over $1,000: 1%
  • This encourages lightweight usage inside the game while preventing large value extraction from external players or bots.

Adjust fees based on historical trading volume​

How can pools personalize fees based on past trading behavior?​

Pools and tokens can adjust fee rates based on a user’s historical trading volume. This allows for loyalty programs, whale-tier pricing, or anti-sandwich protections based on a wallet’s long-term usage profile.

Hooks can read trade histories, on-chain volumes, or protocol-specific metrics to apply contextual fees dynamically.

For example:

  • A DEX rewards long-term traders by lowering fees for wallets with high historical usage.
  • Wallets with over $1M in past volume pay just 0.2% per trade.
  • New wallets pay 0.6% until they’ve traded enough to qualify for volume tiers.
  • Fee logic is implemented in a pool-level hook that reads a usage-tracking contract and applies tiered pricing.

Adjust fees based on profit and loss​

How can fees reward users in a loss and tax those in profit?​

Swap fees can be dynamically adjusted based on a trader’s net profit or loss in a given token or ecosystem. This allows developers to subsidize users who are trading at a loss, offering them cheaper exit liquidity, while extracting more value from users who are actively profiting.

It’s a powerful tool for smoothing volatility, reducing sell pressure from distressed holders, and capturing upside from high-frequency or MEV-driven traders.

For example:

  • A game token, $GRIT, tracks each wallet’s average entry price.
  • When a player swaps $GRIT, the pool hook checks if they’re currently above or below breakeven.
  • If they’re trading below their average entry price (a net loss), they pay only 0.2% in fees.
  • If they’re exiting at a profit, they pay a higher 1.0% fee that funds rewards or treasury growth.
  • This cushions losses for loyal players and charges more from opportunistic sellers.

Enforce marketplace fees on offchain orders​

How can marketplaces ensure signed orders include non-removable fees?​

When using signed offchain orders, protocols can enforce marketplace fees at the time of swap execution by validating the fee terms included in the signed payload. This ensures the fee set by the order maker cannot be bypassed by takers or routing agents.

This pattern allows marketplaces and RFQ systems to reliably monetize order flow while still offering decentralized execution.

For example:

  • A signed order to sell 1,000 $TOKEN for ETH includes a 0.25% marketplace fee.
  • The order maker signs this fee into the offchain order structure.
  • When the order is filled through a LBAMM pool, a hook verifies that the expected fee was included and properly routed.
  • Takers cannot modify or remove the fee, and the marketplace hosting the orderbook earns revenue for providing liquidity access.

Monetize routing of offchain orders through liquidity pools​

How can searchers earn from routing signed orders into pools?​

When signed orders are filled using public liquidity pools, searchers (a.k.a. solvers or routers) can attach an execution fee that captures a portion of the swap. This “fee on top” can be dynamically calculated and routed to the entity that fulfilled the order.

This model rewards routing and execution infrastructure while preserving the user’s intent and slippage bounds.

For example:

  • A user signs a permit to sell 1,000 $TOKEN for at least 0.5 ETH.
  • A searcher finds a LBAMM route that can fulfill the order for 0.55 ETH.
  • The searcher adds a 0.05 ETH fee-on-top and executes the swap on-chain.
  • The user receives 0.50 ETH, and the searcher earns 0.05 ETH for execution.

Charge fees in native token when used in a flash loan​

How can tokens apply fees only during flash loan usage?​

Tokens can be configured to remain fee-free during normal transfers or trades, but apply a fee when used in a flash loan. This behavior allows developers to extract value specifically from MEV searchers or arbitrage bots that borrow and repay tokens in a single transaction.

The logic detects flash usage through execution context or balance deltas, and applies a token-level fee conditionally.

For example:

  • A stablecoin project launches $USDX with no standard trading fee.
  • When $USDX is borrowed and returned within the same transaction (flash loan behavior), a 0.3% fee in $USDX is enforced.
  • This fee is routed to a protocol treasury.
  • Honest users can transfer or trade normally, while advanced use cases like arbitrage contribute to the ecosystem.

Charge fees in alternate token when used in a flash loan​

How can tokens collect flash loan fees in a different token?​

Instead of charging flash loan fees in the borrowed token itself, developers can implement logic to charge fees in an alternate asset such as ETH or a governance token. This gives more flexibility in treasury strategy and decouples the utility of the token from its fee accrual.

Hook logic can read execution context and enforce multi-token fee transfers atomically.

For example:

  • A yield protocol allows $YIELD to be flash borrowed for composability.
  • When borrowed in a flash loan, the protocol charges a 0.5% fee but in $GOV, its governance token.
  • LBAMM verifies both the return of the original amount and the presence of the fee in $GOV during the same transaction.
  • This model boosts demand for $GOV while allowing flexible use of $YIELD in complex strategies.

Swap Access & Reward Mechanics​

Swap Access & Reward Mechanics let developers define who can trade, under what conditions, and with what incentives. These patterns empower games, compliance-focused apps, and programmable markets to tailor participation while embedding custom rewards into every trade.

Swap Access And Reward Mechanics

What new opportunities do swap access & reward mechanics unlock?​

Allow swap access based on NFT ownership​

Hooks can be used to allow swap access based on whether the wallet holds a specific NFT or belongs to an NFT collection. This is ideal for games, clubs, gated airdrops, or communities where only members should be able to access liquidity.

NFT gating can be applied at the token level, pool level, or even per liquidity position.

For example:

  • A music artist launches a fan token, $VIBES, tradable only by holders of a concert ticket NFT.
  • When a user attempts a swap, the token-level hook checks for NFT ownership.
  • If the user holds the required NFT, the trade is allowed.
  • NFT holders can swap freely, creating exclusive access to rewards or merch tokens.

Allow trading for KYC-verified users​

Hooks can be used to allow trading only for wallets that have passed KYC verification. This is ideal for regulated markets, institutional token offerings, or any environment where compliance is required.

KYC checks can be applied at the token level, pool level, or per liquidity position.

For example:

  • A security token, $RWA, is tradable only by investors who have completed identity verification.
  • When a user attempts a swap, the token-level hook verifies KYC status.
  • If the user is KYC-verified, the trade is allowed.
  • Verified users can trade freely within the pool, ensuring compliance without hindering legitimate access.

Enable swaps through game level progression​

How can in-game achievements unlock token access?​

Game developers can allow swaps for wallets that have achieved specific progress in a game such as reaching a level, owning a character, or completing a quest. This turns token access into an earned privilege and unlocks novel progression-based economies.

The hook logic reads game state contracts to validate eligibility during the swap.

For example:

  • A game launches $LOOT, a reward token usable for high-tier upgrades.
  • Players who have reached level 50 can swap into $LOOT.
  • The pool hook checks the caller’s level via the game’s on-chain player stats contract.
  • Progression is recognized at the liquidity layer, turning gameplay into token access.

Enable swaps based on net worth​

How can swap access be tailored to a trader's portfolio value?​

Protocols can design pools that cater to traders within specific net worth ranges. This creates differentiated market access, offering dedicated liquidity for institutional traders, or reserving early distribution for everyday users.

Net worth can be estimated using token balances, staked positions, NFTs, or external oracles.

For example:

  • A compliance-focused $RWA pool enables swaps for wallets with over $250,000 in on-chain assets, verified using a net worth oracle. Ensuring access for institutional-grade traders in regulated markets.
  • A fair launch $COMMUNITY pool enables swaps for wallets with under $5,000 in assets, ensuring broader distribution among everyday participants while preventing early whale dominance.

Allow swaps within specific price ranges​

How can tokens or pools enforce pricing constraints?​

Using Limit Break AMM’s hook system, swaps can be enabled only when the current price is within a defined range. This supports use cases like launch mechanics, price bands, or range-bound stability tokens.

Developers can define static price ceilings/floors or dynamic ranges based on oracles or market state.

For example:

  • A project launches $SALE, a fixed-price token distribution.
  • The token is configured to allow swaps only while the price is between 1.00 and 1.50 USDC.
  • If the price moves outside the band, swaps pause until the price re-enters the range.
  • This ensures the token trades within the intended price window during initial distribution.

Meter order flow through exchange integrations​

How can exchanges be charged for routing trades through your pools?​

Protocols can meter swap volume based on the source of order flow, such as a specific DEX frontend, aggregator, or backend service, and enforce limits, apply fees, or route incentives accordingly. This gives pool developers the ability to monetize high-volume integrations and ensure that exchanges pay their fair share.

Hooks can inspect transaction metadata or enforce access tokens to apply usage-based rules.

For example:

  • A DEX aggregator integrates LBAMM and routes thousands of swaps per hour through a high-liquidity pool.
  • The pool developer configures their hook to meters trades by origin and enforces a usage cap of 50,000 swaps per day from that aggregator.
  • Once the cap is hit, the aggregator must pay an additional routing fee or request expanded access.
  • Smaller exchanges are allowed higher burst limits or subsidized fees to encourage growth.

Reward exchanges for routing order flow​

How can liquidity pools incentivize integrations and routing?​

Protocols can offer dynamic rebates to exchanges or dApps that route users to their liquidity pools. These rebates can be paid in the swapped token, the paired token, or a third-party incentive token.

Routing metadata is passed through calldata and validated via hooks, enabling affiliate-style reward structures.

For example:

  • A LBAMM pool offers a 0.05% rebate to any exchange that routes volume through it.
  • When a user swaps via PartnerDEX, the frontend sets the PartnerDEX address as the exchange fee recipient.
  • The pool-level hook verifies the recipient and sends the rebate to PartnerDEX’s wallet.
  • Exchanges are now incentivized to direct users to deeper or more strategic liquidity.

Reward buyers with spend-only tokens​

How can swaps grant tokens that can’t be resold?​

Tokens can reward buyers with non-transferable, spend-only tokens when they trade through a specific pool. These tokens can be used for in-game items, upgrades, or other utilities but can’t be resold or dumped.

This mechanic aligns rewards with usage and unlocks more sustainable incentive structures.

For example:

  • A game studio launches $BATTLE for in-game PVP and pairs it against ETH.
  • When players buy $BATTLE, they also receive a matching amount of $MEDAL, a spend-only token.
  • $MEDAL can be redeemed for skins or cosmetics but cannot be transferred or sold.
  • Loyalty rewards are earned through actual purchases, not airdrop farming.

Liquidity Access & Incentives​

Liquidity Access & Incentive Design lets developers shape who can provide liquidity, what pairings are supported, and how LP rewards are distributed. These patterns enable intentional market design, maximize capital efficiency, and create targeted participation incentives.

Liquidity Access And Incentives

What new opportunities do liquidity access & incentives unlock?​

Allow specific token pairings​

How can developers control what tokens can be paired?​

Token hooks can implement rules that approve only designated token pairings. This ensures liquidity is concentrated in trusted markets, prevents fragmentation, and maintains security against malicious pairings.

Pair allowances can be enforced at pool creation time using token-level hooks.

For example:

  • A stablecoin project launches $USDX and limits it to approved pairs.
  • Only pools pairing $USDX with ETH, USDC, or $YIELD are allowed.
  • The token hook enforces this rule, ensuring all pairs meet the approved list.
  • Liquidity stays focused in high-quality, vetted markets.

Allow approved creators for liquidity pools​

How can pool creation be limited to approved users?​

Developers can enable pool creation only for specific roles, contracts, or KYC/AML-verified addresses. This helps maintain curated, high-quality liquidity environments, support launch phases, or safeguard protocol integrity.

Token-level hooks can check wallet attributes before allowing a pool to be initialized.

For example:

  • A lending protocol launches a permissioned pool system for interest-bearing tokens.
  • Verified partners and DAO-curated addresses can deploy new pools.
  • When a wallet calls the pool creation function, the hook checks an allowlist.
  • Authorized creators ensure every pool meets quality and compliance standards.

Enable LP fee sharing with builders​

How can hook developers or protocols earn from LP activity?​

LBAMM allows liquidity pool hooks to direct a portion of swap fees to third parties including protocol treasuries, staking systems, or independent hook developers. This creates sustainable incentives for building valuable liquidity logic.

Instead of charging users more, the fee share comes from the LP's portion rewarding infrastructure without increasing execution prices.

For example:

  • A developer publishes a public hook that implements advanced anti-bot logic and dynamic fee scaling.
  • LPs opt to use the hook to improve pool performance and attract better order flow.
  • The hook takes a 0.5% swap fee, split as:
    • 0.4% to LPs
    • 0.1% to the hook developer’s wallet
  • The developer earns passive revenue as more pools adopt the hook, creating an open-source-aligned incentive loop.

Enable liquidity provision for verified users​

How can liquidity provisioning be opened to compliant participants?​

Just like swaps, liquidity provision can be enabled for KYC/AML-verified users. This ensures that approved participants can act as liquidity providers, ideal for institutional markets, real-world assets, or regulated jurisdictions.

Hooks validate the LP’s address against a registry or attestation contract before accepting deposits.

For example:

  • A compliant stablecoin protocol allows verified users to provide liquidity in its $RWA/USDC pool.
  • When a user attempts to add liquidity, the hook checks an OFAC/KYC registry contract.
  • If the wallet is approved, liquidity is accepted.
  • The protocol maintains regulatory compliance while still using public blockchain infrastructure.

Enable liquidity provision for specific character classes or levels​

How can games unlock liquidity access and tie rewards to in-game progression?​

Games can open liquidity provision to players with specific in-game attributes, like class, level, or faction, turning LP access into a gameplay achievement. Once unlocked, players who contribute liquidity can be rewarded with yield, in-game assets, XP, or other progression-linked benefits.

This model keeps economic rewards thematic and gameplay-aligned, enhancing the sense of accomplishment while incentivizing meaningful contributions.

For example:

  • A blockchain RPG issues $MANA, the token used to craft and cast spells.
  • Wizard-class players at level 30+ can LP into the $MANA/ETH pool.
  • A LBAMM hook checks the character’s level before allowing liquidity to be added.
  • Whenever a swap uses that liquidity, the Wizard who provided it earns:
    • Spellcasting XP
    • Rare crafting materials
    • A leaderboard boost
  • Providing liquidity becomes a new endgame activity, tightly woven into the core of progression.

Market Making & Price Control​

Market Making & Price Control patterns enable dynamic or oracle-based pricing, permissioned liquidity access, and programmable rules for price behavior. These mechanics give builders precision over how prices are discovered, maintained, and adapted for institutional DeFi, stable pricing, or regulated asset flows.

Market Making And Price Control

What new opportunities do market making & price control unlock?​

Create liquidity pools with oracle-based pricing​

How can pools use external pricing rather than reserves?​

Instead of using automated pricing based on reserves, Limit Break AMM allows liquidity pools to delegate pricing logic to external oracles. This enables pools to mirror off-chain or centralized market prices while still executing trust-minimized swaps.

This is especially useful for RWA tokens, stablecoins, or synthetic assets.

For example:

  • A protocol tokenizes a barrel of oil as $OIL.
  • The $OIL/USDC pool doesn’t use a standard AMM curve instead it reads an oracle for real-world oil prices.
  • Swaps are executed at the current oracle price ± a configurable spread.
  • Users get real-world price execution with full on-chain auditability.

Enable liquidity access for verified traders​

How can market makers connect directly with approved counterparties?​

Limit Break allows LPs to make their liquidity available only to verified traders. This is ideal for institutions, RFQ-style execution, or high-value trading strategies where counterparties are pre-approved.

Hooks validate the swapper’s wallet or metadata before the LP’s liquidity is used.

For example:

  • An OTC desk provides $10M of ETH liquidity into a LBAMM pool.
  • Their liquidity position is protected by a hook that allows KYC’d counterparties to execute trades against it.
  • Approved traders benefit from direct access to deep liquidity.
  • Institutional LPs gain fine-grained control without needing custom infrastructure.

Enable pool creation for accredited providers​

How can protocols empower accredited LPs to launch pools?​

For regulatory or compliance-sensitive environments, pool creation can be enabled exclusively for accredited providers. This ensures that entities meeting certain legal or financial standards can deploy new liquidity with confidence.

Hooks can validate accreditation status via allowlists, attestation systems, or KYC/AML integrations before allowing new pools to be initialized.

For example:

  • A tokenized security protocol launches $FUND, representing shares in a regulated investment vehicle.
  • Accredited LPs can create new $FUND/USDC pools.
  • The token-level hook checks the caller’s address against an accreditation registry.
  • Approved providers can deploy liquidity while preserving regulatory compliance and onchain composability.

Limit Break

TwitterLimitBreak.comMedium

DigiDaigaku

DiscordTwitterDigiDaigaku.com

FreeNFT

DiscordTwitterFreeNFT.com

GitHub

Creator Token StandardsPayment ProcessorTokenMasterLBAMMAI Tools

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

Privacy PolicyTerms of ServiceCookie PolicyDo Not Sell My Info