Minswap
Minswap fees combine pool charges with applicable order execution costs
Minswap fees include pool trading charges and any applicable batcher costs for executing Cardano orders. V2 constant-product pools deduct their trading charge from swap input. Network fees and ADA required in token outputs also affect wallet funding, so the swap percentage alone does not describe the total balance change.
The trading charge equals the input amount times its fee rate
For a V2 constant-product swap, the trading charge is
f * Δx
in the input asset. Here,
Δx
means the amount entering the swap, and
f
means the applicable trading rate expressed as a fraction. The pricing calculation uses
(1 - f) * Δx
after that deduction. A fee expressed in the traded token therefore differs from an ADA charge for processing the order.
Before rounding down to the output asset's smallest unit, the corresponding output relationship is
Δy = ((1 - f) * Δx * y₀) / (x₀ + (1 - f) * Δx)
. The symbols
x₀
and
y₀
represent the input and output reserves before the swap. This relationship includes the trading charge and the pool's changing exchange rate. The relationship applies to V2 constant-product pools; stable pools have their own pricing curve.
ADA costs and token charges need different units
A fee total is meaningful only when its amounts share a stated asset and unit. The V2 constant-product calculation measures its trading charge in the input asset. Batcher charges use ADA, while a quoted token amount follows that token's decimal precision. Adding those raw quantities together would mix different assets and scales.
One ADA equals 1,000,000 lovelace, so an integer lovelace amount needs conversion before comparison with an ADA balance.
The Minswap Aggregator API supports decimal amounts and amounts in the smallest unit. Its decimal-mode setting changes how quantities should be read. Token decimal information matters separately from ADA's precision. A token's displayed quantity and its raw integer balance can describe the same holding without representing an additional cost.
Batcher fees pay for applying orders within an authorized limit
A V2 batcher collects order UTxOs and applies them to the relevant liquidity pool UTxO. UTxOs are unspent transaction outputs, the objects that Cardano transactions consume and create. The batcher handles this execution work under the protocol's authorization rules. Its charge compensates order processing, while the pool's trading fee enters the swap calculation.
V2 limits the batcher charge to the maximum batcher fee specified in the order.
The maximum and the amount actually charged need not be equal. The order authorizes a ceiling, and the processing transaction supplies the used fee within that ceiling. This per-order amount differs from the pool percentage. Changes to an execution charge do not, by themselves, change the trading rate stored in the pool.
Output ADA and network fees affect different balances
ADA required in a token output remains value in that output, while a network fee pays for the Cardano transaction. A wallet can need enough ADA for both purposes, alongside any ADA reserved for batching. Native-token outputs must satisfy Cardano's minimum-ADA requirements. That requirement concerns the output that holds the tokens, rather than payment to a liquidity provider. The transaction's byte size contributes to its network fee; the token amount does not describe that size. These components explain why the ADA needed to fund an order can exceed the amount consumed as fees.
The parameters behind a V2 cost calculation
Increasing the swap input raises its trading charge proportionally when the applicable rate stays unchanged. The same increase also changes the exchange rate along the constant-product curve. These calculations use different parameters from the ceiling on a batcher's charge.
| Parameter | Value used | Unit or basis | Applicable constraint |
|---|---|---|---|
| Swap input |
Δx
, the selected swap amount
|
Input asset units | Separate from ADA reserved for execution and outputs |
| Input reserve |
x₀
, the pool's input reserve
|
Same scale as the swap input | Must describe the pool state used in the calculation |
| Output reserve |
y₀
, the pool's output reserve
|
Output asset units | Constrains the output available through the pricing curve |
| Trading rate |
f = f_n / f_d
|
Fraction of swap input | Use the rate applicable to the direction and pool settings |
| Maximum batcher fee |
max_batcher_fee
in the order
|
Lovelace | The used batcher fee cannot exceed this ceiling |
| Minimum swap output |
minimum_receive
in an exact-input order
|
Output asset's smallest units | Successful execution must meet or exceed this amount |
| Fee-sharing setting |
fee_sharing_numerator_opt
, absent or configured
|
Fraction of the trading fee, calculated as the configured numerator divided by 10,000 | Sharing applies only when the setting enables it |
| Pool parameters calculate token output; order limits constrain batching charges and acceptable execution. | |||
Compare smaller and larger inputs against the same reserve state and trading rate. Before integer rounding, the larger input produces more output tokens, but fewer output tokens per unit supplied. Its absolute trading charge also rises. These are separate effects: the fee follows the input proportionally, while reserve changes alter the exchange rate. A smaller fee percentage alone therefore cannot explain every difference between quoted output amounts.
This comparison holds only while the reserves, swap direction, and applicable rate remain fixed. It does not predict a later quote after another trade changes the pool state, and it does not set an ADA execution charge.
How do multi-pool routes change Minswap fees?
A route through several pools incurs each pool's applicable trading fee. An intermediate output becomes the input to a later swap, so its asset and fee basis can differ from the original input. Additional pool charges can accompany access to better liquidity. A route's final output therefore reflects both its pricing and its costs. The Minswap Aggregator distinguishes LP, DEX, and aggregator fee components in its estimates. Compare routes using the same starting amount and desired output asset, including any separately funded ADA costs; counting pools alone does not establish which route delivers more value.
Liquidity deposits and Zap Out can include a swap
V2 deposits that differ from a pool's reserve ratio can include an internal swap to balance the contribution. The deposit calculation exchanges part of the excess asset, then calculates the liquidity provider tokens, or LP tokens, that the contribution earns. That exchanged portion carries trading costs through the swap formula. A contribution already matching the reserve ratio follows the proportional deposit calculation without this balancing exchange.
A proportional withdrawal returns the paired assets represented by the withdrawn LP tokens. Zap Out adds a conversion into one selected asset from the pool after that withdrawal calculation. The converted portion therefore encounters the pool's trading fee and pricing curve. V2 also documents withdrawals with a chosen asset ratio, whose adjustment can involve a swap. These alternatives have different cost bases even when they begin with the same liquidity holding.
Those combined operations do not, by themselves, imply separate user transactions for every internal calculation.
Fee sharing divides the pool's trading revenue
V2 fee sharing allocates a configured fraction of the pool's trading fee. Its basis is the collected fee, rather than an additional percentage of the full swap input. The sharing setting therefore changes the allocation between liquidity-provider revenue and protocol revenue. LP tokens represent a proportional interest in the pool, including its fee earnings. Yield farming uses a separate reward arrangement, so a farming reward should not enter a calculation of the fee charged on a trade. The applicable pool settings determine the allocation; a generic split should not replace those settings.
Pool configuration can change the rate that a quote uses
V2 stores separate base fees for the two swap directions in the data attached to the pool UTxO. Authorized updates must keep each rate between 0.05% and 20%. Its dynamic-fee setting also matters: when enabled, a supplied volatility component can add up to 2 percentage points to the base rate, provided the total rate does not exceed 20%. When disabled, that component does not affect the trading rate. These are protocol capabilities with pool-specific settings, rather than proof that every pool currently charges a dynamic fee.
LP fee governance can delegate management of a pool's fees through a proposal and vote. A delegated manager's authority concerns the relevant pool. Neither that arrangement nor V2's parameter model creates one permanent percentage for the entire exchange. Stable pools use a different pricing curve, so the constant-product explanation should not replace their own configuration and quote.
Price impact and slippage change output for different reasons
Price impact comes from the trade's effect on pool reserves; slippage describes the difference between expected and executed pricing. A V2 constant-product output estimate already includes its modeled trading charge and reserve movement. Subtracting those effects again from that output would count the same adjustment twice. Slippage can arise when the state used for execution differs from the state behind the estimate. Treating either effect as another named service fee obscures what changed.
Slippage tolerance sets an execution boundary; it does not add its full percentage to the pool's trading charge.
An exact-input V2 order expresses that boundary through its minimum received amount. A higher tolerance permits a wider difference from the estimate. It does not instruct the batcher to charge that percentage, and it does not make an unfavorable exchange rate cheaper.
Terminating an order after a failed output check can still incur a batcher fee
A V2 exact-input order that permits termination after a failed output check can return funds minus its used batcher fee. The processing path leaves the pool state unchanged in that case, so the refund is different from a completed swap. This cost belongs to handling the rejected order, rather than a trading charge on an exchange that succeeded.
The order's termination setting controls whether that refund path is available. An order that disallows termination cannot use the same failed-check refund path. Return of the input tokens therefore does not establish that execution was free. The relevant amounts are the returned tokens, the ADA deducted for processing, and the network fees associated with the transactions involved.
Minswap fees: what people ask
Does holding MIN reduce every cost on a Minswap trade?
Holding MIN does not establish a discount across every cost component. The 2024 V2 launch fee arrangement applied its MIN-based discount to batcher fees during the three-month launch experiment. That scope did not make pool charges, network fees, and output ADA subject to the same reduction. A batcher discount concerns the execution charge; the trading rate belongs to the selected pool.
Can cancelling an unexecuted V2 order incur an additional cost?
Cancelling an order can require a Cardano transaction fee even though the swap did not execute. V2 also supports optional expiry settings with a maximum ADA tip for someone cancelling an expired order. That tip belongs to expiry cancellation and can reduce the returned ADA. It differs from the batcher charge for processing an order or the trading fee on a completed exchange.
Are trading fees calculated differently for an exact-output swap?
An exact-output V2 swap calculates the input needed to obtain a specified output, including the applicable trading fee. The order also sets a maximum input, which constrains execution. The calculation works backward from the requested output, making the required input the unknown quantity. Unused input can return as change; that amount is distinct from a refund of consumed fees.
When can a partial V2 swap incur another batcher charge?
A partial V2 swap can incur another batcher charge when it executes another permitted portion of the order. Its terms include a maximum number of executions and a maximum batcher fee for each execution. The contract also tracks the remaining overall batcher-fee allowance. The word partial therefore does not establish a single execution charge for the entire order.
Is a farming APR the percentage deducted from a swap?
A farming APR expresses annualized rewards for a liquidity position, while a trading-fee rate applies to the amount entering a swap. Those percentages have different calculation bases and time periods. Farming participation and reward conditions concern the LP position; they do not identify the pool fee deducted from a particular trade.