Kyber swap

Kyber swap Moves from Quote Preparation to On-Chain Result Verification

Kyber swap reaches a verifiable result only when the wallet uses the intended network, the quote remains acceptable at signing and the submitted transaction settles with the expected output-token transfer. Until the wallet submits the signed swap transaction, route choice and quote review remain reversible. After submission, the transaction status, transfer record and recipient balance show whether the exchange completed.

Submitting the signed swap transaction forms the exchange commitment boundary. Before submission, the quoted exchange remains a proposal, although a separate approval transaction may already have changed the token allowance. After submission, the swap transaction records an attempted state change. Keeping those phases separate prevents an approval, displayed quote or transaction hash from being mistaken for settlement.

Route composition before wallet approval

The proposed path matters because KyberSwap Aggregator may split a same-chain order among integrated liquidity sources. It computes that path from the input token, output token, amount and available liquidity. The route is not reserved merely because the interface displays it, so the quote and path need to be reviewed together before commitment.

A larger estimated output does not settle the decision by itself. The associated minimum, fee estimate and route conditions must also fit the intended exchange. Close the confirmation or wait if the network, token identity or amount has changed. The exchange does not occur until the signed swap transaction executes successfully.

Wallet readiness at the commitment boundary

A wallet is ready only when it holds the input token on the selected network and enough native currency for the transaction fee. A token on another network cannot satisfy the quote, even if the wallet shows the same ticker. The connected address should also match the intended recipient for the same-chain output.

Wallet readiness at the commitment boundary: Connecting a wallet reveals available addresses but does not authorize token spending. When the wallet presents a permission request, compare its network, token and spender with the reviewed action.; An unexplained chain change or contract address is a reason to reject the request before any state changes.

Open full-size image

Connecting a wallet reveals available addresses but does not authorize token spending. When the wallet presents a permission request, compare its network, token and spender with the reviewed action. An unexplained chain change or contract address is a reason to reject the request before any state changes.

Quote controls that define acceptable execution

The quote sets the conditions under which the proposed exchange may proceed. Its fields describe different risks and should not be treated as interchangeable estimates.

Estimated output and minimum received

Estimated output reflects the route under current conditions. Minimum received is the binding floor derived from the selected maximum slippage. If execution cannot meet that floor, the transaction should revert instead of completing below it. The exchange remains undone after a revert, although the network may still charge for the attempted transaction.

Price impact and slippage

Price impact estimates how the order itself affects its average execution price. Slippage measures the difference between the expected and executed price as conditions change. A large order relative to available liquidity can raise price impact before submission, while intervening market activity can produce slippage after the quote appears.

Transaction time limit

The transaction time limit defines how long the submitted swap remains valid. It prevents execution under an expired proposal, but it does not guarantee network inclusion within that period. The limit also does not replace the minimum-output condition or the wallet fee review.

Allowance choice remains separate from exchange

An approval grants a specified spender permission to use the input token. It neither performs the exchange nor proves that a route remains available. An amount-limited allowance narrows the authorization, while a broader allowance can remain available for later transactions. The wallet request should expose the amount and spender before confirmation.

For an ERC-2612 token that KyberSwap marks as eligible, the interface can offer a signed permit instead of a separate approval transaction. The permit carries its own nonce and deadline conditions. The token exchange still requires an on-chain transaction and network gas, and the permit signature does not establish that the swap settled.

Quote refresh at the moment of signing

Rates and paths can change during review because available liquidity and pending market activity continue to move. The interface may refresh the estimate or calculate a different final route before opening the confirmation view. That latest view is the relevant proposal, so compare it with the intended input, minimum output and fee rather than relying on an earlier screen.

A route change before signing remains reversible. Continue only if the revised terms still meet the intended conditions. Once the wallet broadcasts the signed transaction, quote comparison gives way to transaction-state verification.

A reversible choice before the signature

All figures and outcomes in this worked example are hypothetical. A reader plans to exchange 72.2 input-token units and holds 0.025 native units for network fees. The first quote estimates 51.67 output-token units, sets 51.12 as the minimum and estimates a 0.018 native-unit fee.

Two options remain before signing: continue with that quote or wait for a refreshed route. Both use the same criterion. The minimum must reach the reader's hypothetical acceptance floor of 51.20 output units, and the fee must fit the available native balance. Because 51.12 falls short, the reader waits. A refreshed quote estimates 51.73, raises the minimum to 51.26 and lowers the fee estimate to 0.017, so the reader accepts the second proposal.

After confirmation, the explorer hypothetically reports success and records 51.44 output-token units transferred to the connected address. The corresponding wallet balance rises by 51.44 units. Those observations establish a completed output above the signed minimum. A pending or reverted record would leave that conclusion unproven, regardless of the earlier quote.

How can I confirm that the output actually arrived?

Completion requires a successful transaction record and the expected output-token transfer to the intended address on the selected network. A transaction hash alone does not prove that the network included or successfully executed the swap. The block explorer should show the swap transaction as successful, and its transfer data should identify the output asset and recipient.

A same-chain aggregator transaction executes atomically, so a split route should not leave only one leg settled. The wallet balance provides a second check, although a wallet may need to refresh or display the token manually. Verification should use the token identity from the transfer record rather than its ticker alone.

Reading pending, reverted and successful states

Each transaction state supports a different conclusion. Treat the explorer's record as the primary execution evidence and the wallet display as a useful confirmation.

Pending before inclusion

Pending means the network has not finalized the transaction. The quoted output has not become a settled balance. Wait for a final state or use the wallet's supported replacement controls where available. Submitting an unrelated second swap can create another commitment without resolving the first.

Reverted after an execution attempt

Reverted means the smart contract rolled back the proposed exchange. The wallet should retain the unexchanged input, but the network can still charge gas for processing the failed attempt. Any later attempt needs a fresh quote because the old route described earlier market and network conditions.

Successful and settled

Successful status establishes that the called transaction executed. Inspect its token transfers to confirm that the relevant hash belongs to the swap rather than an approval. The output identifier, recipient and transferred amount should agree with the signed conditions and resulting balance.

If a hash is dropped or marked as replaced, check for a replacement transaction. Follow any replacement to its final state before deciding whether the exchange executed. The absence of a wallet notification does not override a finalized on-chain record.

Cost lines in the review

KyberSwap's fee schedule lists no KyberSwap trading fee for the standard Swap product, while liquidity-pool fees and blockchain network fees can still affect the exchange. An embedded partner integration may configure a separate commission. The quote and wallet preview should expose the applicable costs before signature, and the network fee normally uses the chain's native currency.

Reconciling the record with the wallet display

A missing wallet row does not by itself prove that the swap failed. The network, recipient and exact output-token identity must agree before the display can be interpreted.

Selected network and recipient

The output from a same-chain swap belongs on the network used for execution. Confirm that the wallet is viewing that network and that the transfer record names the connected recipient. Switching the wallet view does not move a token between networks.

Token identity rather than ticker

A wallet may omit an unfamiliar token from its visible asset list. Compare the asset identifier or contract address in the successful transfer with the intended output before adding it manually. A matching ticker alone is insufficient because different tokens can share the same symbol.

Balance change and transfer amount

The output balance should reflect the confirmed transfer amount in addition to any prior holdings. Network gas can reduce the native-currency balance independently of the output. If the explorer shows no matching output transfer, a success label may belong to another transaction and should not close the verification.

A new attempt starts a new commitment

A second signature is a new exchange once the first swap has succeeded. While the first remains pending, another submission may duplicate the intended trade or wait behind it. After a confirmed revert, request a fresh route and review every condition again. Do not submit another swap until the earlier transaction succeeds, reverts or is confirmed dropped. If it was replaced, follow the replacement to its final state first.

Key questions about Kyber swap

Does canceling a pending transaction revoke the token allowance?

No. Canceling or replacing a pending swap changes that transaction, not a previously confirmed token allowance. An on-chain approval can remain until its amount is used, changed or revoked. An unused signed permit follows its own nonce and deadline. Check the allowance for the exact owner, token and spender before assuming that canceling the swap removed authorization.

Why does raising maximum slippage not guarantee faster confirmation?

Raising maximum slippage does not change transaction ordering or guarantee earlier inclusion. It widens the price interval in which the contract may execute, which can reduce reverts caused by market movement. Block inclusion still depends on network conditions and transaction fee settings. A wider tolerance also accepts a worse output, so it does not resolve a transaction that is already pending.

When should an unused allowance be reduced or revoked?

Reduce or revoke an allowance when the approved spender no longer needs it, when its amount is broader than intended or when the spender does not match the reviewed swap. Revocation is a separate on-chain action and requires network gas. Confirm that transaction independently because a completed exchange does not automatically prove that every remaining allowance reached zero.

Do token approvals carry over when I switch blockchain networks?

No. On EVM networks, an approval belongs to one chain and binds an owner, token contract and spender. Changing the wallet to another network does not copy that record, even when a token uses the same symbol. The new network may require a separate approval, and its wallet request should clearly identify the network and contract before signature.

Is the network fee deducted from the output token?

For a same-chain EVM swap, the network fee is normally paid with the network's native gas asset, while the exchange consumes the selected input token. Liquidity-pool fees can affect route economics, and an integration may add a disclosed commission. Read the wallet fee preview and quote details together because the output estimate and gas charge follow different accounting paths.

What makes a second transaction wait behind the first one?

On an EVM network, a later transaction can wait because the network processes a wallet's transactions in nonce order. A lower-nonce transaction that remains pending can hold back later submissions. The wallet's speed-up or cancel function usually replaces that nonce and may require another network fee. Verify the first hash before sending a fresh swap with a new nonce.

· last updated