Kyber swap
Kyber swap links route choice and trade controls to the records and balance changes that verify settlement
Kyber swap offers an immediate same-chain exchange, a limit order at a chosen rate or a cross-chain exchange between networks. The right path follows from the intended destination and timing. Before submission, the wallet must use the correct network, hold the input token and enough native currency for required on-chain fees and grant any necessary token allowance. A live quote then shows the estimated output, minimum received, price impact, route and applicable fees. A quote or approval does not prove completion. The relevant transaction record and the resulting output-token balance provide that evidence.
Bottom line: Choose the exchange path by destination and timing, then confirm settlement through the transaction record and the wallet's output-token balance.
Route fit and settlement evidence
Each exchange path produces a different commitment and final state. An immediate swap fits when the input and output assets are on the same supported network and the trader accepts the confirmed market quote. A limit order records a chosen rate and waits for a taker to fill it. A cross-chain swap covers an exchange whose output must arrive on another network, adding transfer and destination-settlement stages.
The aggregator can split a same-chain trade and route portions through multiple liquidity sources on the connected network. That routing may improve the quoted output, but the confirmation view remains the decision point because market conditions can change. The selected path should therefore match both the desired destination and acceptable completion evidence. An immediate swap ends with an on-chain receipt, a filled limit order has a settlement transaction and a cross-chain exchange also needs destination-chain delivery.
Wallet, network and allowance prerequisites
A same-chain exchange starts with compatible wallet state. The connected network must match the selected route, the wallet must hold the intended input token and its native balance must cover network fees. Token identity matters because symbols can be duplicated across unrelated contracts. The contract address and network together identify the asset more reliably than its ticker alone. A newly encountered token may also require an ERC-20 spending allowance before the swap contract can transfer it.
An approval changes permission; it does not exchange the token.
The allowance transaction may consume a network fee and must confirm before a dependent swap can proceed. Some tokens support an ERC-2612 permit, which replaces an on-chain approval with a signed authorization. The exchange itself still requires execution. Before signing, the wallet should display the expected network, token and spender. A request for another network or an unexpected spender is a reason to stop because it does not match the quoted action.
Quote controls before commitment
A swap quote describes a proposed exchange rather than a reserved outcome. Its most useful fields connect the intended input to the conditions under which execution may continue:
- estimated output for the proposed route
- minimum received after the selected slippage tolerance
- price impact associated with the trade and available liquidity
- estimated network fee for the on-chain transaction
- liquidity path used to form the quote
An instant swap completes only when execution meets the minimum-received threshold; otherwise, the transaction reverts. A narrow slippage tolerance sets a tighter minimum output but can produce more failed attempts during volatility. A wider setting raises execution tolerance and permits a worse final rate within that boundary. Price impact is separate: it estimates how the trade itself changes the average execution price relative to available liquidity. The confirmation view may present a refreshed route or output, so its figures should be compared with the earlier quote before signing.
What proves that a swap completed?
A successful transaction receipt and the corresponding output-token balance change prove a same-chain swap completed. The transaction hash identifies the submitted action, while its receipt records whether execution succeeded or reverted. A pending status does not establish the final result. An approval receipt proves permission was granted, not that an exchange followed it.
A reverted swap does not deliver the quoted output, although the network may still charge gas for the attempted execution. Limit orders require a fill or settlement record rather than an active-order entry. Cross-chain swaps add source-chain, transfer and destination-chain states, so a successful source transaction alone does not prove that the destination address received the output. The destination balance and final route status close that gap.
A hypothetical minimum-output check
This worked case uses hypothetical values throughout: network N, input token A, output token B, route R and every amount are invented. The wallet proposes 275.5 A for an estimated 741.75 B and selects a hypothetical maximum slippage of 1%. The resulting minimum is 741.75 multiplied by 0.99, or 734.3325 B. The displayed network fee is also hypothetical, and the wallet holds enough native currency to submit the transaction.
Assume hypothetical input token A needs a new allowance before this swap. The smallest initial action is to authorize only the required input amount, followed by a check that the confirmed quote still meets the 734.3325 B boundary. The wallet then submits the swap; its receipt shows success and its output-token balance rises by 738.10 B. That executed output exceeds the minimum.
The acceptance test uses two observations: the receipt succeeded and the output-token balance increased by 738.10 B. If the route could not deliver at least 734.3325 B, the minimum-output condition would have caused a revert instead. The calculation does not predict a live rate; it shows how a chosen boundary separates an acceptable execution from a rejected one.
Limit orders and cross-chain alternatives
A limit order suits a rate condition that may be met later. Its maker signs an order that is relayed off-chain, while a taker settles a matching fill on-chain. The offered tokens remain in the maker's wallet until settlement. Spending those tokens elsewhere, reducing the allowance or reaching the expiry can leave the order unable to fill.
Order creation itself can use an off-chain signature, but a token approval may still require gas. Filling also depends on available takers and the economics of settlement. Reaching the chosen market rate therefore does not promise execution at a particular moment.
A cross-chain exchange serves a different destination. Its confirmation details should identify the source and destination networks, receiving address, estimated output, minimum received, route fees and expected processing time. The route may involve a source exchange, a transfer provider and destination settlement. Each stage has its own status, so recovery information must be read from the selected route rather than inferred from same-chain revert behavior.
Immediate aggregation favors execution against a confirmed same-chain quote, a limit order waits for a specified rate and a cross-chain route targets delivery on another network. Matching that job before signing makes the resulting record easier to interpret than treating every exchange as an ordinary instant swap.
Frequently asked questions about Kyber swap
Does KyberSwap add a protocol fee to an instant swap?
KyberSwap does not add its own protocol fee to the standard instant-swap product. The route can still include liquidity-pool trading fees, and the blockchain charges a network fee for execution. Those costs differ from a KyberSwap fee and affect the economic result. Limit orders, cross-chain routes and integrated services can use separate fee schedules, so their confirmation details need an independent review.
Why can the final quote differ from the first estimate?
The final quote can change because liquidity, market prices and network conditions continue moving while a route is calculated. KyberSwap may refresh or replace the proposed path before confirmation. The confirmation screen is therefore the relevant version to assess. Compare its output, minimum received, price impact and fee with the earlier estimate, then reject the transaction if the new terms no longer suit the intended exchange.
When does an ERC-2612 permit replace an approval transaction?
An ERC-2612 permit can replace a separate on-chain approval when the input token implements that standard and the interface supports the permit flow. The wallet signs structured authorization data instead of broadcasting an approval transaction. This permission does not execute the swap, and the swap still incurs its own network fee. Tokens without permit support generally require the conventional ERC-20 allowance transaction before the contract can transfer them.
What happens if execution would fall below minimum received?
The instant swap reverts when execution cannot satisfy the minimum-received amount encoded for the transaction. The wallet keeps the unexchanged input, but the network may still consume gas for the failed attempt. Raising slippage tolerance can make execution more likely, yet it also accepts a worse output within the wider boundary. A fresh quote may offer different liquidity without changing that basic rule.
Are funds locked while a limit order waits for a match?
The offered tokens remain in the maker's wallet while a KyberSwap limit order waits for settlement. They are transferred only when a taker fills the signed order on-chain. This means the same balance can be spent elsewhere, but doing so may leave too little balance or allowance for the order to execute. An active order should not be treated as a reserved wallet balance.
Is a successful source-chain transaction enough for a cross-chain swap?
A successful source-chain transaction is only one part of cross-chain completion. The route may still need a transfer provider to process the message or funds and settle the output on the destination network. Final proof combines the route's completed status with the destination transaction and receiving balance. Processing status means those later stages have not yet supplied complete delivery evidence.
Where can a completed same-chain exchange be verified?
Use the transaction hash to locate a successful on-chain receipt, then confirm the corresponding output-token balance change. The interface history is useful for locating the record, while the blockchain record confirms execution independently of the wallet's display. If the token is missing from the visible asset list, compare its contract-specific balance before and after the transaction to distinguish a display issue from a failed exchange.
Why might a limit order remain unfilled after the target rate appears?
A target rate does not by itself guarantee that a KyberSwap limit order will fill. Settlement also requires a taker, valid order timing, sufficient maker balance and enough allowance for the offered token. Network fees and available volume can make a small fill unattractive to takers. A momentary market price does not prove execution when the order is expired, cancelled or underfunded.
ยท last updated