Mdex swap inputs, pool roles, and the commit point

Swaps, liquidity, rewards, and governance change different states

Each function changes a different kind of on-chain state. A swap changes token balances, liquidity provision changes a pool position, incentive staking moves that position into another contract, and governance records a separate choice. Access to one function does not establish that another is available.

Token swaps

A pool-based swap exchanges an input token for an output token through reserves held by a smart contract. The route may use one pool or several connected pools. Its feasibility depends on deployed contracts, sufficient liquidity, and a valid path on the selected network.

Liquidity and incentives

Providing liquidity deposits the pool's paired assets and normally returns a token representing the provider's share. Staking that position for incentives is another transaction with different withdrawal rules and contract exposure. An advertised reward does not change how the underlying pool reprices the deposited assets, and it does not prove that a historical incentive program remains open.

MDX and governance

MDX is the protocol token and has been used in rewards, staking, and governance arrangements. The applicable rights depend on the particular contract and program. Holding MDX alone does not establish that a pool earns rewards, that a vote is active, or that an older lockup arrangement still accepts deposits. The swap quote covers only the chosen trade.

What determines a swap quote?

The network, token contracts, input amount, route, pool reserves, fee parameters, and slippage setting determine a swap quote. Reserve balances establish the exchange relationship at the moment of calculation. A trade that is large relative to the pool's reserves tends to move the quoted rate further than a smaller trade through the same pool.

The displayed output remains an estimate until the transaction executes. Other transactions can alter reserves while a wallet prompt is open, and a route can become less favorable or unavailable. Refreshing the quote updates those inputs. It does not guarantee execution at the displayed number, which is why the transaction also carries a minimum acceptable output.

The network and token contract define the market

A route exists on one network between specific contracts. Matching symbols, familiar names, or similar icons do not make tokens interchangeable across networks.

Network selection

Mdex announced deployments on BNB Chain and Ethereum, while HECO formed part of its earlier multi-chain setup. HECO was scheduled to go offline on January 15, 2025. Treat a HECO route as historical unless live network evidence establishes otherwise. A cached interface label cannot prove that the network, pool, or withdrawal path still operates.

Contract identity

A token contract address identifies the asset that the router will spend or deliver. Two contracts may display the same symbol while representing unrelated assets, wrapped forms, or fraudulent copies. Compare the selected contract with the intended asset before approving it. The receiving balance should later reference that same contract on the same network.

The wallet prompt marks the commitment boundary

Before signing, the proposed action remains reversible: the prompt can be rejected without changing on-chain balances. The decoded call should identify whether the wallet is approving a spender, submitting a swap, or invoking another function. Contract address, spending amount, recipient, and network fee deserve separate attention because they describe different parts of the authorization.

Once the wallet broadcasts a signed transaction, the call cannot be edited. It may remain pending, confirm successfully, or revert. A wallet that shows opaque call data provides less evidence than a fully decoded prompt. In that case, returning to the quote and contract details is safer than inferring the action from an icon or button label.

How do approval and swap transactions differ?

An approval gives a specified contract permission to spend an allowance; a swap uses that permission to exchange tokens. An ERC-20-compatible token needs sufficient allowance before the router can transfer it, although an existing allowance can satisfy that requirement. The approval does not execute a trade, set its eventual output, or prove that a later swap succeeded.

The allowance may equal the intended amount or permit a larger limit, depending on the request. A broader allowance leaves more spending authority with that contract until the holder changes or revokes it. A failed swap normally does not remove an existing allowance because the approval is a separate state change. Revocation also requires its own network transaction.

Quoted output, price impact, and slippage

These figures describe different parts of the trade. Reading them together shows when shallow liquidity makes the effective rate more sensitive to trade size or reserve changes.

Quoted output

Quoted output is the amount that current pool reserves and route calculations predict before execution. Pool trading fees affect that calculation. The number can change after any reserve update, including another swap. A refreshed quote therefore replaces the earlier estimate rather than validating it.

Price impact

Price impact estimates how much the proposed trade itself shifts the pool's rate. It usually grows when the input is large relative to available liquidity. Splitting a trade does not automatically remove that cost because each part can move the same reserves, while separate transactions add network fees and timing risk.

Minimum received

For an exact-input swap, slippage tolerance converts the quote into a minimum acceptable output. Price impact is already reflected in the quoted output; slippage tolerance covers adverse movement between quotation and execution. Raising the tolerance does not improve the pool price. It only permits the transaction to complete across a wider range of outputs.

If execution would return less than the minimum, the swap should revert instead of completing at that output. The network can still charge gas for the reverted computation. A very tight limit may cause repeated reverts in a moving pool, while a loose limit accepts a worse result. The appropriate boundary changes with liquidity and current transaction conditions.

Fees come from separate layers

The pool's trading fee affects the assets exchanged and is reflected in the route calculation. Its live value can depend on the pool or current configuration, so an old promotional rate should not be treated as a permanent protocol constant. Historical rebates or mining rewards require current eligibility before they can be included in a net-cost estimate.

The network fee pays for computation and comes from the selected network's native asset. The network fee is separate from the input amount and from MDX. If the trade spends the network's native asset, both charges come from the same asset balance. Wallet estimates may change as network demand and the transaction's gas limit change.

Some tokens deduct a transfer fee or restrict transfers in their own contracts. That behavior can reduce the amount reaching a pool or cause an incompatible route to revert. A symbol does not reveal these rules. The relevant evidence is the exact token contract, the router's supported behavior, and the final on-chain transfers.

Liquidity positions change with the pool

Providing liquidity is not the same commitment as making a swap. The position represents a share of changing reserves, so withdrawal can return a different mix of assets from the original deposit. Trading fees may add value to the pool, while relative price movement can create impermanent loss. Any separate MDX incentive changes the reward side, not the reserve mechanics or withdrawal composition.

When does the evidence show a completed swap?

A successful receipt on the intended network, accompanied by the expected token transfers and balance change, shows that a swap completed. A pending hash is not completion, and a confirmed receipt with a failed status records a revert. An approval receipt proves only that spending permission changed.

Wallet displays can update later than the chain record or hide an unfamiliar token until its contract is added to the asset view. Reconcile the transaction status, receiving address, token contract, and transfer amount before acting again. The observed output may legitimately exceed the minimum received, but it should correspond to the same route and recipient that the wallet authorized.

The smallest reversible recovery step

Resolve a mismatch at the earliest state that still allows correction. Reject an unsigned prompt and refresh a stale quote. For a pending transaction, inspect its nonce and status before attempting replacement. After a revert, correct the specific network, allowance, balance, or output-limit problem instead of repeating every step. If the chain record shows success, investigate display or reconciliation issues and do not submit a duplicate swap.

View full-size image