Kyberswap
Kyberswap token swap checklist with pass/fail evidence
Last updated -
A Kyberswap token swap checklist starts by matching the wallet’s active network to the intended input asset. Treat the first quote as provisional until the confirmation screen shows the route and minimum received. A pass requires the correct input asset, enough spendable input balance and enough native network currency for any approval and swap transaction. Before signing, compare the output estimate, minimum received, gas estimate, price impact and allowance request with the intended trade. After submission, use the matching on-chain receipt and received output as settlement evidence. A failed or reverted record is a stop signal: diagnose the cause, obtain a fresh quote and sign only the next valid request.
Bottom line: A swap passes only when the selected network and input asset, any required spending authority, the confirmed minimum and on-chain settlement all match the intended trade.
Network and asset identity set the first pass
A swap path is eligible only when the wallet’s active network and the input asset matches the intended trade. The wallet address should hold the spendable input balance on that network as well as enough native currency for any on-chain approval and execution. A balance on another network cannot fund the selected route.
Token symbols alone do not establish identity. On networks that identify tokens through contract addresses, compare the address and network before accepting a custom asset. Pass this stage when the wallet account, active network, input asset identity and intended output all agree. Stop if the interface shows a different network, an unfamiliar contract or a balance that belongs elsewhere.
Which quote belongs in the final decision?
The confirmation quote is the one to judge because Kyberswap may refresh the route and price after the initial entry screen. If the output changes before confirmation, the revised figures replace the earlier estimate. Decline the request if the new terms no longer fit the intended exchange.
Expected output and minimum received answer different questions. Expected output estimates the result at the quoted route, while minimum received sets the lowest output that execution may accept under the selected slippage tolerance. Neither number includes a promise that market conditions will remain unchanged before inclusion.
Price impact describes how the trade size affects the execution price through available liquidity. Slippage covers movement between the quoted state and execution. Review both because a permissive slippage setting cannot repair an unattractive price impact already visible in the quote.
The remaining cost is network gas, shown as an estimate and paid in the network’s native asset. Mark the quote as a pass only when its input amount, estimated output, minimum received, price impact and estimated gas are all acceptable together. A stale or materially changed quote needs a new decision rather than automatic confirmation.
Five records that define the swap state
The strongest evidence comes from the record closest to the state being tested. An approval proves authority, for example, while a receipt proves what happened after broadcast.
| Evidence record | Pass condition |
|---|---|
| Active wallet context | The intended account and network appear before quoting. |
| Input asset record | The input asset and spendable balance match the selected network. |
| Spending authority | No approval is required, or the allowance or permit matches the token, spender and required amount. |
| Final confirmation | The input, expected output, minimum received, price impact and gas estimate remain acceptable. |
| Settlement record | A successful receipt and received output correspond to the submitted swap. |
Do not substitute one row for another. A connected wallet does not prove an allowance, an allowance does not prove submission and a transaction hash does not prove success. A pass requires the prerequisite records and final receipt to agree without an unexplained mismatch.
Does approval mean the swap has started?
No. Approval establishes spending authority for a token, while the swap requires a separate confirmation and on-chain execution. Read the wallet request before signing because an approval and a swap can appear close together but produce different records.
ERC-20 allowance
An ERC-20 approval records token spending authority for a named spender and amount. It does not submit the exchange or establish the eventual output. Compare the token, network, spender and allowance scope with the pending trade. A custom allowance may need renewal when the remaining amount cannot cover a later swap.
ERC-2612 permit
A supported token may offer an ERC-2612 permit, which authorizes spending through a signed message instead of a separate approval transaction. The permit itself can avoid approval gas, but the swap still requires an on-chain transaction and network gas. Pass the permit only when its token, authorized amount, spender and validity belong to the intended swap.
The wallet signature marks the commitment boundary
The confirmation screen prepares a transaction, but the wallet controls whether it leaves the account. This is the last point to reject an unexpected network, account or contract interaction without broadcasting the swap.
Compare the wallet request with the confirmed trade. The active network and sending account should match, while the transaction target and requested value should make sense for the action. A sudden account switch or network change invalidates the earlier checks.
Identify which request the wallet presents. An approval changes token authority, a permit signs an authorization message and a swap transaction attempts execution. Completing one request does not silently complete the others, so each record needs its own purpose.
After broadcast, preserve the transaction hash that belongs to the swap rather than relying on a button state or temporary notification. The hash identifies the submitted transaction. Its receipt status and received output decide whether that commitment produced a completed exchange.
What proves that the quoted protection held?
A successful receipt plus an output at or above the confirmed minimum proves that the swap satisfied its quoted protection. Kyberswap completes the swap only if execution can meet the displayed minimum received; otherwise, the transaction reverts.
Successful receipt
Match the receipt to the submitting account and transaction hash, then verify that the intended recipient received the output asset. The actual output may differ from the estimate while remaining above the minimum. Record the received amount rather than treating the estimate as the settled result. A successful status without the expected output asset at the intended recipient still needs reconciliation.
Reverted receipt
A reverted EVM transaction rolls back the token-transfer state, although the network does not return gas already used for execution. The failed receipt is useful evidence: it separates an executed failure from a request that never reached the network. Do not mark the swap complete merely because the wallet displayed a submission message.
A bounded retry after a reverted swap
Normal path. The reader selects the intended network and input token, accepts a current quote and confirms spending authority that covers the trade. The swap reaches a successful receipt, and the received output meets or exceeds the saved minimum received. That matching record ends the task.
Edge case. Market conditions change before execution, so the route can no longer deliver the confirmed minimum. The transaction reverts and the receipt shows failure. The attempted asset transfer rolls back, although execution gas may still reduce the native balance.
The recovery boundary begins with a fresh quote, not a repeat of the stale transaction data. Compare the updated route, minimum received, price impact and gas estimate. Check whether the existing allowance still names the required spender and covers the new input amount. Retry only after those records agree; otherwise, stop without another signature.
Diagnose the fault before signing again
Retry only when the failure identifies a condition that the next request can change.
Network funding and transaction state
An inadequate native-asset balance may prevent the wallet from broadcasting or leave no room for the estimated gas. A pending transaction is neither a pass nor a confirmed failure, while a dropped, replaced or reverted transaction has a different recovery path. Identify that state first so a second submission does not create an unintended duplicate.
Quote, allowance and asset mismatches
A transaction time limit, route refresh or market movement can make old swap data unusable. Insufficient allowance can also block the contract from spending the requested amount. If the input asset or network is wrong, abandon the quote rather than adjusting slippage. If the asset is correct, obtain current terms and authorize only the amount and spender that the new request needs.
Stop with a confirmed result or a named fault
A pass has the intended network and input asset, acceptable confirmation terms, any required spending authority, a successful receipt and the corresponding received output. A stop has a specific unresolved fault such as an identity mismatch, insufficient gas, stale quote, pending transaction or failed receipt. Preserve the relevant hash and confirmed minimum, then decide whether new terms justify another attempt or whether the trade should remain closed.
Details worth knowing about Kyberswap
-
Can I reuse an existing token allowance for a later Kyberswap swap?
- Yes, an existing allowance may cover a later swap when the network, input token and authorized spender remain the same and the unused allowance is sufficient. A different spender or a larger required amount can trigger another approval. Read the new wallet request rather than assuming that a previous approval applies to every route.
-
Why does an EVM native asset not need an ERC-20 approval?
- An EVM network’s native asset moves through the transaction value mechanism rather than an ERC-20 token contract, so it does not use an ERC-20 allowance. The wallet still needs enough of that asset for the swap amount and network gas. A wrapped version is a token contract and may require approval.
-
Why was network gas charged when the swap reverted?
- On an EVM network, validators still process the transaction instructions that lead to a revert, so the sender pays for the gas consumed. The revert rolls back the attempted token-state changes, but it does not refund execution gas. Check the failed receipt before deciding whether a fresh quote warrants another transaction.
-
Is a token symbol enough to identify a custom swap token?
- No, a symbol can be duplicated and does not uniquely identify a token. Match the contract address on the selected network, then confirm that the wallet balance belongs to that same contract. Stop if the symbol looks familiar but the address or network differs from the asset intended for the swap.
-
Can the final output exceed the displayed minimum received?
- Yes, minimum received is a protective floor rather than the predicted settlement amount. Execution can produce a higher output when the route fills on better terms, while any acceptable result may still differ from the original estimate. Compare the actual received amount with the confirmed minimum to classify the completed swap.