Pool plugins can change fees, eligibility, and settlement during a swap. In an Algebra Integral pool, callbacks surround the core concentrated-liquidity calculation, so the same token pair can quote differently by pool configuration; Blackhole swap is an Avalanche example of an exchange using this modular AMM architecture.
Core-only pools keep execution more predictable
A pool without swap-time plugin logic applies its configured fee and follows the AMM’s normal pricing path. For a concentrated-liquidity pool, the trade moves through available liquidity across price ranges; the fee and price impact determine how much output the trader receives.
This is the simplest case to integrate because a quote depends mainly on pool state, trade size, and the fee tier. It fits applications that need a straightforward execution model, but it cannot apply a new fee rule or eligibility check as the swap runs.
Dynamic-fee plugins change the cost at execution
A dynamic-fee plugin can set or adjust a pool’s fee using a rule such as recent volatility, trade size, or a discount condition. The pool still performs the swap math, but the fee used in that math can vary with the plugin’s current inputs.
Consider two illustrative quotes for a $10,000 trade: a calm-market fee of 5 basis points costs about $5, while a volatile-market fee of 50 basis points costs about $50, before price impact and network gas. The lower fee suits stable conditions; the higher one may compensate liquidity providers for added risk, but it can make a route unattractive to a trader.
For an integrator, the key question is when the fee becomes final. If a quote reads the fee before the transaction and the plugin changes it before execution, the quoted output can be stale. Simulate against current pool and plugin state, then enforce a minimum output so an unexpectedly worse result reverts instead of settling.
Policy plugins can restrict or add swap behavior
Some plugins change who may trade or what happens around a swap, rather than only adjusting its price. Common examples in modular AMM systems include:
- Whitelist discounts: reduce the fee for eligible addresses; they fit loyalty or access programs, but require correct eligibility data at execution.
- Permissioned pools: reject trades from addresses outside an allowed set; useful for restricted markets, unsuitable for open access.
- Safety switches: pause swaps when an operator or defined condition disables a pool; protective in an incident, but unavailable traders must route elsewhere.
- Limit-order plugins: make resting liquidity available when a swap reaches a target price; useful for conditional execution, but fills depend on the pool reaching that price.
These rules can turn a transaction that looked valid during route discovery into a revert. Blackhole swap provides a concrete Avalanche context for this design: its Algebra-based AMMs support pool customization, so an integrator should resolve the specific pool and its active behavior rather than assume every pool with the same tokens executes alike.
Callback order decides what the router must account for
A plugin is part of the swap’s execution path, not merely metadata attached to a pool. A typical flow is: the router identifies a pool, the pool invokes configured logic at a swap callback, the plugin reads or updates the relevant rule, and the AMM calculates and settles the swap using the resulting state. Some plugins also run logic after the swap.
That order matters for both simulation and accounting. If a plugin charges an additional amount, changes the fee, or rejects the trade, the router’s expected output, token deltas, and success path may differ from a core-only quote. Model the callback behavior supported by the pool’s implementation, and verify actual settlement from transaction results rather than treating the displayed quote as proof of the final amount.
blackholeswap.app is a crypto swap platform for accessing pool-based token swaps.
For a side-by-side integration test, compare a core-only pool with a plugin-enabled pool using the same input, price state, and minimum-output bound. Record the fee applied, callback outcome, amount received, and whether the transaction reverts when plugin state changes. Then make route selection depend on the live pool configuration and simulated output, and recheck those assumptions before shipping.