Mdex first swap: checks before signing and completion evidence

Which choices change the transaction you sign?

The network, token contracts, amount, path, recipient, deadline, and output constraint determine the swap call. Changing any of them changes the requested transaction, its execution constraints, or the account that receives the output.

Network and contract identity

A token symbol is not a unique identifier. The same visible symbol can belong to different contracts, and a contract address has meaning only on its own network. The wallet network, input contract, and output contract must therefore agree with the quote before the request reaches the signing screen.

Path and trade direction

The asset path starts with the input contract and ends with the output contract. A selected path may pass through intermediate pools. Reversing the direction changes which token and reserve are treated as the input, so it produces a different quote. An earlier route can also become stale as pool state changes.

Output and time boundaries

Mdex router calls encode an asset path, a deadline, and either a minimum output or maximum input, depending on the swap method. For an exact-input swap, lowering the minimum output permits execution at a worse result. For an exact-output swap, raising the maximum input permits more of the input token to be spent. An expired deadline causes the call to fail rather than execute later under an old time limit.

Readiness before the commitment point

Readiness requires more than a connected wallet. The account must hold the selected input, maintain enough native network balance for execution, and provide any allowance that the router needs to transfer the input token. A connection exposes an address to the interface, but it does not establish token identity, sufficient balances, or an available route.

Current configuration determines whether a particular action is available. A historical market name or an old interface image does not prove that a route still works. A live quote reflects a proposed output for a selected path and the current pool state, but inclusion can occur later, after reserves or other relevant on-chain state have changed. Do not sign when the interface cannot produce a coherent quote.

What proves that the bounded swap finished?

Completion requires a successful on-chain transaction for the intended network and contract call, followed by balance changes that agree with its transfer records. A quote, wallet confirmation screen, or transaction hash alone does not establish that result.

Receipt status

A transaction hash identifies a submitted candidate. While the transaction remains pending, the requested state change has not reached a final recorded outcome. A successful receipt establishes that the included call did not revert, but the contract address and call data still need to match the intended swap. A failed receipt records an attempt, not an exchange.

Pool events

Mdex pair contracts emit a Swap event when a pool executes an exchange. A route through more than one pool can produce multiple exchange events within the same transaction. Those records connect the call to particular token flows and pool contracts, which is more precise than a wallet label that merely says a contract interaction succeeded.

Balance reconciliation

Compare the account's resulting token balances with the receipt's transfer records. The network fee affects the native balance separately from the exchanged assets, and token-specific transfer behavior can affect the recorded movement. A stale wallet display may need a refresh, but it should not trigger another swap while any discrepancy between the successful receipt and displayed balance remains unresolved.

Approval and swap records preserve different evidence

A token approval sets an allowance for a spender and does not, by itself, exchange the approved token. Its successful receipt shows that the approval call did not revert; read the resulting allowance before treating the permission as changed. The allowance may remain if the later swap fails, is rejected, or is never submitted, and any unused portion depends on the approved amount and subsequent transfers. Reducing or revoking that permission is another on-chain action, with its own signature, status, and network fee.

View full-size image

A mismatch calls for the smallest safe retreat

Before signing, reject the request and correct only the disputed input. A wrong network calls for network alignment; a wrong token calls for contract re-selection; an outdated quote calls for a refresh. Loosening the output constraint or enlarging an allowance does not repair an identity mismatch. Those changes widen the commitment instead.

After broadcast, use the transaction state rather than the interface animation. A pending call may still succeed or fail, so an immediate duplicate can create a second trade. A confirmed failure leaves the requested swap state reverted, although an execution fee may have been consumed. Refresh the quote only after identifying whether the failure came from an expired deadline, an unmet output boundary, insufficient allowance, insufficient balance, or another recorded cause.

The next action begins from a reconciled state

After a successful swap, the new balances, remaining allowance, and transaction receipt form the starting state for any later action. Obtain a new quote because pool reserves, balances, and time limits may have changed. If the receipt and balances conflict, stop until the discrepancy is resolved. For example, a confirmed approval without a successful swap receipt is permission evidence, not completion evidence.