Kyberswap
Kyberswap: actions from route selection to verified exit
Last updated -
Kyberswap combines route comparison, token swaps, limit orders, cross-chain transfers and liquidity tools in a wallet-directed workflow. A reader starts with a supported network, token or existing position, reviews the proposed action and its costs, then decides whether to sign or broadcast it. Completion comes from the matching on-chain record, destination balance, filled-order state or updated liquidity position rather than the button press itself. This article follows that handoff from quoted intent to observable settlement. It also separates an approval from a swap, a signed order from its fill and a source-chain transaction from completed cross-chain delivery.
The seven-stage path from intent to exit
Every supported action moves through a similar sequence, although swaps, orders and liquidity positions produce different records. The table maps each stage to the evidence that can confirm progress or support recovery.
| Stage | State change | Evidence or recovery boundary |
|---|---|---|
| 1. Starting state | The wallet, source network, balance or existing position is identified. | Record the wallet address, network and relevant token or position identifier. Stop if any item is wrong. |
| 2. Requested action | The input, intended output, destination or order terms are entered. | Compare the entered values with the intended change. Correct a mismatch before requesting a route. |
| 3. Quoted terms | A route, estimated output, minimum received, expiry or provider option appears. | Read the live costs and conditions. Refresh terms that have expired or changed materially. |
| 4. Authority | The wallet grants an allowance, signs a permit or signs an order when required. | The wallet prompt identifies the network and requested authority. Reject an unexpected contract or amount. |
| 5. Commitment | A transaction is broadcast or a signed limit order is submitted for matching. | Keep the transaction hash or order identifier. If the wallet request is rejected, no order is signed and no transaction is broadcast. |
| 6. Settlement | The network executes the swap, a taker fills an order or a cross-chain route advances. | Use the receipt, fill record and available source and destination transaction records to distinguish pending, failed and completed states. |
| 7. Reconciliation and exit | The resulting balance, order state or liquidity position is compared with the intended outcome. | Investigate unresolved states before resubmitting. Cancel an open order, remove supported liquidity or revoke unused authority when appropriate. |
This sequence prevents two common mix-ups. An approval authorizes a later action but does not prove execution, while a source-chain confirmation does not by itself prove delivery on another network.
Where does wallet authority begin?
Wallet approvals and signatures set the authority boundary. Connecting a wallet identifies an address and network, but it does not execute a trade. Authority changes only when the user grants a token allowance, signs a permit or order or broadcasts an on-chain transaction.
Before approving, signing or broadcasting, check these fields:
- The selected network must match the location of the input asset.
- The token and spending amount must match the intended action.
- The wallet prompt must match the expected approval, permit, order or transaction.
- When the wallet must broadcast an on-chain transaction, it needs enough of the network’s native asset to pay the network fee.
An allowance and a swap are separate states. A failed approval leaves the swap unsubmitted, while a successful approval may remain available for later transactions until it is spent, changed or revoked. Supported permit flows replace an approval transaction with a signed message for a defined amount and validity period, but the swap still needs network execution.
Limit orders use signed maker orders stored off-chain, while takers settle matched orders on-chain. The input tokens remain in the maker’s wallet before settlement, so the balance and allowance must still be sufficient when a taker tries to fill the order. Once a signed order has been distributed, guaranteed cancellation may require an on-chain cancellation transaction.
How can a Kyberswap result be verified?
A verified result matches the intended state change to both the interface record and the relevant blockchain record. For an immediate swap, a successful receipt should correspond to the expected output token appearing at the receiving address. A reverted transaction does not produce that intended output, although the network may still charge gas for processing it.
Limit orders have more than one valid end state. An order may remain open, become partially filled, fill completely, expire or be cancelled. The active-order view and order history distinguish those states, while each on-chain fill provides settlement evidence. A signature alone proves that an order was authorized, not that a trade occurred.
Cross-chain history records the route, status and on-chain transactions associated with the transfer. A confirmed source-chain transaction proves that the first step reached its network, while final delivery requires a successful destination status and the expected receiving balance. Keeping both records matters when the route remains in processing or a provider reports a failure.
Liquidity actions produce another kind of evidence. The resulting position identifier, deposited amounts and wallet balance should reflect the completed entry, migration or withdrawal. A dashboard estimate can help with monitoring, but the position and transaction records establish what was actually executed.
Swaps, limit orders and cross-chain transfers
Each action crosses the commitment boundary differently, so an identical-looking wallet confirmation can lead to a different waiting period and completion record.
Immediate swaps
Before wallet confirmation
The aggregator can split a requested trade across several liquidity sources when constructing its route. The confirmation details may show the estimated output, minimum received, price impact, network fee and slippage setting. Market movement can change those terms between the first quote and the final confirmation, making the latest displayed route the relevant proposal.
After network submission
Once broadcast, the transaction waits for its network receipt. The minimum-received condition protects the quoted boundary by reverting execution when the output would fall below that amount. A transaction hash allows the submitted call and final status to be checked without relying only on a wallet notification.
Limit orders
A limit order records a maker’s chosen rate and expiry for later matching. Creation uses a signed order that can be relayed without moving the offered tokens at that moment. Settlement occurs only when a taker fills the order on-chain. Partial fills are possible, and moving the offered tokens elsewhere can leave too little balance for the remaining order.
Cross-chain transfers
A cross-chain quote combines a source asset, destination asset, receiving address and provider route. Available options can differ in estimated output, fees and processing time. After confirmation, the route may include a source-chain swap, bridging and destination settlement. The output balance at the stated receiving address is the decisive end state, not the first transaction alone.
Liquidity entry, management and exit
Kyberswap also supports a longer cycle for liquidity positions. KyberEarn can surface supported pools and positions, while KyberZap can construct entry, migration and withdrawal transactions for supported liquidity protocols. Compatibility varies by network, pool type and integration, so the live position view determines which actions are available.
A Zap may prepare the required pool assets and add liquidity within one transaction. The route still has transaction-specific inputs such as token amounts, position range, slippage and network cost. Some concentrated-liquidity positions are represented by position identifiers, which become part of the record needed for later management or withdrawal.
Monitoring continues after entry because accrued fees, token balances and a concentrated position’s in-range status can change. Smart Exit Orders add an order state for supported positions, with the displayed condition and status showing whether an exit instruction remains active or has executed. A normal withdrawal or Zap out instead requires a new on-chain transaction and confirmation of the assets returned to the selected wallet.
Liquidity carries pool-contract risk, price exposure and possible impermanent loss. Concentrated positions can also move out of range and stop earning trading fees until price returns or the position changes. Those outcomes belong to the position itself; a successful deposit transaction does not establish future earnings.
Costs, failures and the deliberate exit
No single fixed cost describes every Kyberswap action. Network fees vary with the selected network, current network conditions and transaction complexity. For a swap, route liquidity and price impact affect the amount received, while the slippage setting defines the minimum acceptable output. Any platform, pool or provider fee shown for the route adds to the cost. A fee-on-transfer token can also reduce the amount that reaches the next step.
Failure states differ. An expired quote needs fresh terms, a reverted swap leaves no intended output and an underfunded limit order may remain unfilled. A cross-chain transfer can stay in processing after its source transaction confirms because destination settlement has not finished.
Submitting a duplicate while the first action remains unresolved can create a second valid transaction. Retaining the hash, order identifier, route status and receiving address makes reconciliation possible before another commitment is made.
Exit means something different for each path. An immediate swap ends with the new balance, an open limit order needs a fill, expiry or cancellation and a liquidity position remains active until it is withdrawn or otherwise closed. The appropriate next step changes when current route terms, supported integrations or wallet permissions differ from the state reviewed before signing.
Kyberswap: what people ask
Do I need a native asset to pay network gas?
A native network asset is generally required when the wallet broadcasts an on-chain approval, swap, cancellation or liquidity transaction. The required asset and estimated amount depend on the selected network and transaction. A gasless signature may avoid a maker-side transaction at that stage, but any later on-chain action still needs someone to pay the network fee.
Can a token approval outlive the swap?
A token approval can remain active after a swap finishes or fails because the approval and trade are separate transactions. Its duration and amount depend on the permission that was granted. The wallet or a compatible allowance manager can show the remaining authority, which may be reduced or revoked when the user no longer wants the contract to spend that token.
Why can the received amount differ from the first quote?
The received amount can change because liquidity, market prices and route conditions may move before execution. The final confirmation presents the current estimate and minimum-received boundary for an immediate swap. Transfer-fee tokens can introduce another deduction defined by the token contract, so their balances may not follow the standard token flow.
Does a Kyberswap limit order lock the maker’s tokens?
A Kyberswap limit order does not move the maker’s offered tokens merely because the order was signed and submitted. The tokens remain in the wallet until a taker settles a matching fill on-chain. Using or transferring those tokens beforehand can prevent settlement if the remaining balance or allowance no longer covers the order.
What happens if a limit order no longer has enough balance?
A limit order cannot settle the requested amount when the maker’s wallet lacks sufficient offered tokens at fill time. The attempted fill may fail even though the signed order still appears valid. The order state, wallet balance and remaining allowance should be reconciled before relying on that order or creating a replacement.
Which address receives a cross-chain output?
The receiving address shown in the cross-chain confirmation receives the destination output. The interface may use a connected destination wallet by default or accept a separately entered compatible address, depending on the route and networks. Checking the full destination address before signing matters because a successful source transaction does not correct an address entered for the wrong recipient.
Is a source-chain confirmation enough for a cross-chain swap?
A source-chain confirmation proves only that the initial transaction reached its network. The route can still be bridging or settling on the destination chain. Completion requires the cross-chain status to show success and the expected output to reach the receiving address. Source and destination transaction records provide the clearest handoff evidence when both are available.
Can KyberZap withdraw liquidity into one selected token?
KyberZap can construct a Zap out to a selected output token for supported positions and integrations. The transaction may remove liquidity and route the withdrawn pool assets into that output. Availability depends on the network, pool and supported protocol, while the live route supplies the expected output, slippage condition and transaction details.