Kyber swap
Kyber swap controls link route choices to verifiable token output
Kyber swap controls let a trader compare a live route, estimated output, minimum received, price impact, network fee and permitted liquidity sources before signing. After submission, the transaction status, transfer record and recipient balance show whether the proposed exchange produced the accepted output.
Immediate execution and neighboring order modes
The interface separates an immediate same-chain swap from limit-order and cross-chain modes because each mode commits to a different outcome.
An immediate swap uses a live quote for assets on one network. Its controls describe a proposed route and the conditions under which that route may execute. A limit order expresses a chosen rate and waits for an eligible fill. A cross-chain exchange also has destination-network delivery to track, so its route and records cover more than one settlement stage.
This page concentrates on the immediate swap controls. A route preview is relevant only while its quote remains available, and changing an input amount can produce a different path. The displayed estimate is therefore part of the pending proposal. It is not evidence that the exchange has occurred or that the quoted output has been reserved.
A same-chain swap should be judged through its current quote, signed transaction and resulting token transfer, without importing order-fill or destination-chain assumptions from the neighboring modes.
Route details before commitment
The proposed route shows how the aggregator intends to source the output, including any split among available liquidity sources.
Route composition affects more than the names displayed in the path. Different pools or venues can produce different output estimates, price impact and execution costs for the same requested amount. A split route may reduce the burden placed on one source, while a shorter route may require less on-chain work. The quote brings those effects together for comparison before the wallet receives a transaction request.
A route should be read with its input token, output token, amount and selected network. After submission, verify the recipient against the output transfer rather than treating it as a quote field. If the input amount changes, the previous route no longer describes the same request. If the selected network changes, token balances and allowances on the earlier network do not carry into the new proposal.
Quote fields with separate jobs
Each quote field answers a different question about the proposed exchange, so one favorable number cannot substitute for the others.
Estimated output describes what the route expects to return under the quoted conditions. Minimum received is the lower execution boundary associated with the slippage setting. If execution cannot satisfy that boundary, the swap should revert rather than settle below it. An output token's fee-on-transfer mechanism can separately reduce the amount delivered to the recipient. The estimate can still change before signing because liquidity and market conditions continue to move.
Price impact estimates how the requested trade size affects the available market price. Maximum slippage addresses adverse movement between quotation and execution. These measures can rise for different reasons and should not be merged into one percentage. A large request can have material price impact even when execution remains within the chosen slippage boundary.
The network fee estimate covers the blockchain resources expected for the transaction. It can vary with the route and network conditions. A transaction time limit controls how long the submitted swap remains valid for execution. None of these fields, taken alone, confirms that the recipient obtained the output token.
What does maximum slippage actually control?
Maximum slippage sets the largest adverse movement that the submitted swap may accept relative to its quoted output.
The interface translates that tolerance into a minimum-received value. A wider tolerance lowers the boundary and allows execution across a broader range of changing conditions. It does not improve liquidity, reduce price impact or guarantee quicker inclusion. It changes only the execution boundary below which the transaction should fail.
A narrow tolerance protects a higher floor but may cause more reverts when the market moves before execution. A wide tolerance increases the gap between the estimate and the permitted floor. The useful comparison is therefore the actual minimum-received amount, not the percentage in isolation.
Liquidity-source filters and route changes
The liquidity-source selector changes which integrated sources the routing calculation may consider for the current same-chain request.
Leaving the available sources enabled gives the routing engine a broader search space. Excluding one narrows that search and can alter the route, output estimate, price impact or expected network fee. The filter does not establish that a remaining source is safer or more favorable. It records a routing preference, and the refreshed quote shows the consequence of that preference.
KyberSwap Aggregator can split a same-chain trade across integrated liquidity sources when the computed route favors that structure. The route view can then identify the included sources and their allocation. A later quote may use a different composition because the underlying request or available liquidity changed. The wallet should be asked to sign only after the refreshed route remains acceptable.
A hypothetical quote acceptance test
This hypothetical example uses invented token quantities and an invented 0.7% maximum-slippage setting to show how an acceptance boundary works.
A request starts with 247 input-token units and an estimated return of 913 output-token units. Before execution, the wallet must hold the input on the selected network, have enough native currency for the network fee and provide any required allowance. A simplified 0.7% calculation gives a minimum received of 906.609 output units.
The route refreshes before signing, and the submitted transaction later records a transfer of 908.2 output units to the intended recipient. That amount exceeds 906.609. A successful transaction status, the matching token-transfer record and a corresponding 908.2-unit balance increase together confirm the accepted result.
If executable output had fallen to 905.9 units, the minimum check would not have been met. The bounded outcome would be a reverted swap with no accepted output transfer, rather than settlement below the stated floor.
Approval evidence and swap evidence
An approval record proves that a contract received permission to spend a token amount; it does not prove that an exchange followed.
A conventional token approval is an on-chain transaction with its own hash, status and network fee. Its record concerns allowance. The swap requires another wallet confirmation and produces a separate execution record. A completed approval can therefore exist without any output-token transfer, particularly when the user stops before submitting the exchange.
Eligible ERC-2612 tokens can use a signed permit for allowance instead of a separate on-chain approval transaction. Whether permission comes from approval or permit, the later swap record remains the evidence for execution. The relevant output transfer and recipient balance must belong to that swap, not merely to the permission step.
How can the execution record explain an unexpected output?
The execution record can identify the transaction status, recipient, token contracts and transfer amounts that produced the observed balance change.
Start with the transaction hash generated by the submitted swap. Its network must match the selected network, and its status must show successful execution rather than a pending or reverted attempt. The transfer entries then identify which token contract sent output, how much moved and which address received it. Route-internal transfers should not be mistaken for the recipient's final amount.
The final amount may be below the earlier estimate while remaining at or above minimum received. That difference can reflect permitted slippage at execution. If the transaction succeeded but the visible wallet amount seems wrong, compare the recipient and token contract first. A ticker alone is insufficient because unrelated tokens can share a symbol.
A missing or mismatched transfer changes the diagnosis. The record may show the wrong recipient, another token contract or no successful swap transaction at all. Interface history can help locate the hash, but the on-chain receipt and token transfers explain what execution actually produced.
Balance reconciliation by network and token identity
Balance reconciliation matches the recorded output transfer to the same recipient, network and token contract shown by the wallet.
The pre-swap and post-swap balances should refer to one address and one token identity. Switching networks can make the wallet display another balance under the same ticker. A wallet may also omit an unfamiliar token from its default list even though the transfer exists. Adding the verified token identity to the wallet view can resolve that display issue without changing the on-chain balance.
Pending data can create another temporary mismatch. The interface, wallet and explorer may query different nodes or refresh at different times. A pending transaction has no settled output to reconcile. If the transaction succeeds, its transfer record provides the amount and recipient that the wallet display should reflect.
Other wallet activity can also change a balance near the same time. The most reliable comparison isolates the transfer associated with the swap hash rather than attributing the entire before-and-after difference to one exchange.
Limits of interface history and settlement records
Interface history is a convenient index of past activity, but it depends on the connected address and the data available to the application.
A transaction record can show whether a submitted transaction is pending, successful or reverted. After successful execution, its transfer entries can establish the delivered token and recipient. Those records do not prove that an earlier quote was the best possible market option, and they cannot recover a route that was viewed but never signed. Settlement evidence proves execution within the encoded conditions, not economic optimality.
What readers ask about Kyber swap
Why can two quoted routes show similar output but different network fees?
Different routes can call different contracts, use different liquidity sources or split the request across several paths. Those choices change the amount of on-chain computation that the network must perform. The fee shown before signing is still an estimate because network pricing and actual gas use can change. Similar token output therefore does not imply equal transaction cost.
Does excluding a liquidity source guarantee a better route?
No. Excluding a source only removes it from the routing search for that request. The refreshed route may have a lower estimate, higher price impact or different network-fee estimate because fewer paths remain available. The useful evidence is the complete refreshed quote after the filter is applied, including output, minimum received and route composition.
When can price impact and slippage point in different directions?
Price impact and slippage describe different effects. Price impact relates the requested trade size to available liquidity, while slippage compares the expected execution with the outcome available when the transaction runs. A request may show noticeable price impact yet execute close to its estimate, or it may have modest price impact and encounter adverse movement before inclusion.
Is minimum received the exact amount that will reach the wallet?
No. Minimum received is the lowest output that the submitted swap may accept under its slippage condition, not a prediction of the exact final transfer. A successful execution can deliver more than that floor. The transaction receipt, output-token transfer and recipient balance establish the amount that actually arrived.
What does a wallet simulation add to the confirmation review?
A wallet simulation may preview expected asset changes or flag a transaction that is likely to revert, depending on the wallet and network support. It remains a forecast based on the state available to the simulation provider. The simulation does not replace the signed transaction's final status, transfer logs or resulting token balance.
Why might interface history and a block explorer use different status labels?
The interface can group application-specific phases into reader-friendly labels, while a block explorer reports the state of an individual blockchain transaction. Compare the transaction hash before comparing labels. A submitted swap may be shown as processing in the interface while its on-chain transaction is pending, and the final transfer remains unconfirmed until settlement.
Do failed swaps still incur a network fee?
A swap that reaches a gas-charging network and reverts can still consume execution resources, so its sender may pay a network fee despite receiving no output token. A request rejected in the wallet or never broadcast does not create that on-chain execution cost. The transaction hash and receipt distinguish a mined revert from an unsigned or unsubmitted request.
ยท last updated