Merlin swap fees are comparable when controlled exchange inputs stay consistent
Merlin swap fees are only one part of what a token exchange costs. To compare two quotes fairly, keep the input asset, output asset, input amount, network and receiving account unchanged, then capture the quotes as close together as possible. Read the liquidity-provider fee beside the quoted output, minimum received, price impact and wallet gas estimate. A lower displayed fee can still leave less output when liquidity or routing changes the exchange rate. After execution, reconcile the confirmed gas charge and received token amount with the quote. This final comparison measures the completed exchange instead of relying on a percentage shown before signing.
Updated:
The short version: Compare identical exchange inputs, then reconcile the quoted output with confirmed gas charges and the tokens received.
Where each cost enters the exchange
Different parts of the total cost appear in the quote, wallet request and on-chain execution. Separating those stages prevents one visible percentage from standing in for the entire exchange.
Costs shown with the quote
The swap detail view separates the liquidity-provider fee, price impact, average price and minimum received into distinct fields. The pool fee is a charge associated with the selected liquidity path. Price impact describes how the proposed exchange interacts with available liquidity, while minimum received defines the lowest acceptable output under the chosen tolerance.
Costs presented by the wallet
The wallet estimates the network gas needed for the requested transaction. An input token may require a separate approval before the swap, so the wallet can present two requests with two gas charges. Approval authorizes a specified spender and does not exchange the assets by itself.
Costs established by execution
The final gas charge comes from the executed transaction rather than the earlier estimate. The received amount also reflects the exchange state when the transaction ran. A quote can therefore be useful without being a reserved rate, and a failed on-chain attempt can leave a gas cost without producing output tokens.
Build comparison evidence before signing
Record each quote while it is actionable. Keep the token contract identities, exchange direction, input amount, receiving account, slippage setting and network unchanged. Save the quoted output, minimum received, liquidity-provider fee, price impact and gas estimate together. A figure copied without its asset denomination or transaction stage cannot support a reliable comparison.
Which fields must stay fixed for a fair comparison?
A fair comparison keeps the assets, input amount, receiving account, network and slippage setting constant, and changes only the path or fee choice being evaluated. Both quotes should describe the same economic action.
The selected input amount matters twice. It fixes how much the account spends and affects how deeply the request reaches into available liquidity. Changing that amount can alter both price impact and quoted output, even if the displayed fee tier remains unchanged.
Timing also matters because pool state and gas conditions can move between requests. Quotes captured close together are more comparable, although simultaneous conditions cannot be guaranteed. If the market moves materially, request both quotes again rather than pairing a fresh result with an older one.
Use the same slippage setting as well. Different settings create different execution boundaries and failure risks. They do not make the underlying pool fee higher or lower, but they change which outcomes the transaction is permitted to accept.
Trace one input change through three stages
Start with a recorded quote for the selected input amount. Set it aside without submitting it, change only that amount and request another quote. The comparison shows whether the pool charge, price impact and estimated output move together or at different rates.
| Stage | Evidence and operative boundary |
|---|---|
| Quote | Record the selected assets, input amount, expected output and displayed cost fields. Minimum received is the execution boundary for that quote. |
| Wallet request | Match the token, amount, spender and receiving account. The gas limit caps the gas units available to the request. An approval authorizes the spender but does not execute the swap. |
| Confirmation | Use successful transaction status, actual gas charged and the output balance change. A pending or failed record does not prove completion. |
If the larger input produces proportionally less output, the changed amount has affected more than the headline fee. Restore the original amount and obtain a fresh quote before choosing between the paths. This reversible check tests whether the quote follows the input change, but liquidity and gas conditions can still affect the result.
After submission, the confirmed transaction and received balance become the completion evidence. If either does not match the expected state, preserve the record and investigate the difference before starting another exchange.
Liquidity fees and price impact describe different costs
A liquidity-provider fee is charged under the selected pool or route terms. Price impact is not a separate transfer to the liquidity provider. It describes the difference between the pre-exchange reference and the rate produced when the requested amount interacts with available liquidity.
Read these fields together. A path with a higher stated pool fee can still quote more output when its liquidity supports the requested amount more efficiently. Conversely, a low fee does not compensate for an exchange rate that deteriorates sharply as the amount increases. Minimum received belongs beside both figures because it determines the lowest output that successful execution may accept.
Gas and approvals belong in separate columns
Network gas pays for the on-chain computation needed to process a request. It is separate from the liquidity-provider fee and may be denominated in a different asset from both the input and output tokens.
Merlin Chain uses native BTC for gas, while its account-abstraction wallet can offer MERL as the gas asset. The wallet configuration therefore affects how the network charge appears, but it does not change the pool fee or price impact embedded in the exchange quote.
A token approval can add another transaction charge when the existing allowance is absent or insufficient. Include that gas cost when comparing the full cost of starting from the same unapproved state. Exclude it only when both alternatives begin with the same usable allowance and the comparison clearly covers the swap transaction alone.
Gas estimates can change before execution. Compare estimates at the quote stage, then replace them with actual charges when reconciling completed transactions. Mixing one route's estimate with another route's confirmed charge produces an uneven result.
Why can the cheaper fee produce less output?
The path with the lower displayed fee can produce less output when its exchange rate or available liquidity is less favorable for the selected amount. Fee percentage alone does not measure this difference. Compare expected output, minimum received and gas under the same inputs. If one path uses additional liquidity steps, rely on the complete route quote rather than adding an assumed charge for each step.
Convert unlike units without hiding assumptions
Raw fee numbers cannot be added when they use different assets. A gas charge in BTC or MERL and a liquidity fee reflected in another token need a common reference unit, or they should remain as separate line items. Label every amount with its asset before calculating a total.
For a normalized comparison, use one conversion snapshot for both alternatives and record its time. Subtract the converted gas estimate and any in-scope approval cost from each route's quoted output value. After confirmation, repeat the calculation with actual gas and received output. The normalized total is specific to that conversion snapshot, not a permanent cost for the route.
How should two route choices be compared?
Compare two supported paths by placing their complete quotes side by side under the same exchange conditions. The better result is the path that preserves more net output within an acceptable execution boundary, not automatically the path with the smallest fee label.
The route name alone proves little. Record the liquidity-provider fee, price impact, quoted output and minimum received for each choice.
Then account for the wallet's estimated swap gas and any approval required for each path from the same starting state. If one path needs a separate approval while the other can use an existing allowance, show that difference openly rather than folding it into an unexplained total.
Refresh both quotes when one becomes stale or the selected amount changes. Route comparisons expire as liquidity and network conditions move. They support a decision at the recorded time and inputs, not a claim that one path is always cheaper.
Reconcile quote evidence with the completed exchange
The final comparison uses confirmed execution evidence. Replace provisional quote values only where the transaction record supplies an actual result.
When the swap succeeds
Check the successful transaction status, actual network charge and output-token balance change for the receiving account. Keep unrelated transfers out of the measured interval because they can distort the balance difference. Compare the received amount with the quote and minimum received, then calculate net cost using the same reference unit applied to the alternative.
When execution fails
A reverted on-chain transaction can still consume gas even though the swap does not complete. Record that charge separately from the unspent input tokens. A preceding approval may also remain effective because it was a different transaction. Pending records should remain unresolved until their status becomes final enough to establish success or failure.
The boundary of a like-for-like result
A like-for-like result answers a bounded question: which available quote produced the stronger cost outcome for the same assets, amount, settings and comparison window. It does not prove that the chosen path will remain cheaper after the amount, pool state, gas conditions or route changes. Preserve the inputs and confirmed evidence with the result, or the comparison loses its practical limit.
Practical questions about Merlin swap fees
-
Are bridge charges part of a Merlin swap fee comparison?
- Bridge charges belong outside the swap comparison when the assets are already on Merlin Chain. If reaching the network is necessary for the intended exchange, record bridging as a separate acquisition or funding cost. Do not merge it with the liquidity-provider fee because bridging and swapping are different actions with different execution records. Include it only when both alternatives are being compared from the same pre-bridge starting state.
-
Can an existing approval reduce the cost of a later comparison?
- An existing allowance can remove the need for another approval transaction when it covers the same input token, spender and required amount. That can reduce the immediate gas needed for a later swap. The earlier approval still had its own historical gas cost, however. Decide whether the comparison covers only the next exchange or the complete cost from an initially unapproved account, then apply that scope to both alternatives.
-
Why can an affordable quote still fail during execution?
- A displayed cost does not establish that every execution condition will remain satisfied. The account may lack enough of the selected gas asset, the allowance may be insufficient or the exchange state may move beyond the minimum received boundary before processing. A wallet or contract can also reject a request that fails its checks. Preserve the failed transaction status and gas charge instead of treating the quote as a completed exchange.
-
Is the minimum received amount a guaranteed payout?
- No. Minimum received is the lower output boundary that the submitted swap may accept under its configured tolerance. It applies only if the transaction executes successfully. The transaction can fail instead of delivering that amount when the exchange cannot satisfy the boundary or another execution condition fails. Compare it with the expected output to understand the permitted range, but use the confirmed balance change for the final result.
-
Which fee record applies when an account-abstraction wallet pays gas in MERL?
- Use the transaction record for the gas asset and amount actually charged by the wallet. Paying gas in MERL changes the denomination of the network cost, not the liquidity-provider fee or the quoted token output. For a common-unit comparison, convert that confirmed MERL charge with the same time-specific reference method used for the competing route. Keep the original asset amount beside the converted value so the assumption remains visible.
-
Does viewing or rejecting a quote create a network fee?
- Viewing a quote or rejecting an unsigned wallet request does not submit an on-chain transaction, so that action alone does not consume network gas. A fee can already exist if a separate approval was submitted and confirmed before the swap request was rejected. Check the transaction history rather than the interface state to distinguish an unsubmitted quote from an approval or swap that reached the network.