Kyberswap
Kyberswap limit orders and the conditions for a fill
Updated -
Kyberswap limit orders fill when a taker can execute the trade at the signed exchange rate or a more favorable rate. A matching chart price alone does not establish an executable trade. Liquidity, order size, trading activity, network costs, wallet balance, allowance, and expiry all influence whether an order can settle. The maker signs trading terms, while a taker submits a matching fill on-chain. An order may fill partly, fill fully, or expire with a remainder. Before changing a target, distinguish an unavailable trade from an order that lacks funding or permission. Each cause calls for a different response, and cancellation has its own confirmation boundary.
Read the order state before changing the price
An open order records trading instructions that still await execution. Signing authorizes the terms; acceptance into the off-chain orderbook makes the instruction available for matching. Neither action establishes that a trade has settled. The order record and its execution details distinguish a waiting instruction from a completed exchange.
A successful token approval establishes spending permission. It does not establish that any part of the order has filled.
Review the order for the wallet and network that created it. If the instruction remains open, investigate the condition preventing settlement before assuming that its price needs changing. Funding problems and absent matching demand require different responses.
Token balance in the wallet and allowance for the contract
Settlement requires enough of the sell token and sufficient spending allowance for the limit-order contract. Both conditions concern the maker’s wallet on the order’s network. Holding the same token on another network does not supply that balance.
Allowance authorizes a particular spender to transfer a token up to the permitted amount. Permission granted to another contract does not automatically authorize this one. Check the contract, token, and allowance amount together.
The tokens remain in the wallet until settlement. Placing an order does not reserve them against other wallet activity.
Spending or transferring the sell token can leave an existing order without enough funding. Reducing its allowance can create a separate settlement obstacle even when the token balance remains sufficient. These conditions can change after the order first becomes active.
A required on-chain approval costs network gas. Its purpose is to establish spending permission; the maker signs the limit order separately. An approval alone cannot satisfy a missing balance, an expired instruction, or an unavailable matching trade.
Why can the market reach my price without a fill?
A displayed market price can cross the target without a fill because a taker still needs an executable match. A price observed elsewhere does not establish available liquidity for this order’s pair, amount, and network.
The target also has a direction. A buy limit sets the highest acceptable purchase price; a sell limit sets the lowest acceptable sale price. Read the displayed exchange rate in the intended token direction before adjusting it. A more attractive target from the maker’s perspective may require a larger market move before execution becomes worthwhile. Moving closer to an executable rate relaxes that price preference, without creating demand by itself.
Order size, liquidity, and taker economics
The taker pays the network gas for settling a limit-order fill. A taker evaluates the available trading opportunity against that cost and any applicable taker protocol fee. An order can meet its price condition while offering too little economic return to attract a fill.
Size creates competing effects. A small order may offer too little return relative to transaction costs. A larger order needs enough executable liquidity at the required rate, although partial fills can reduce the amount that one taker must absorb. Reducing an order’s size therefore does not always improve its fill prospects. Network costs and available trading demand still influence the opportunity, so there is no single order size that ensures execution.
Aggregator demand and quiet token pairs
Active limit orders can supply liquidity to swaps routed through the aggregator, giving resting orders another path to trading demand. Routing still requires a suitable rate and executable amount. A pair with little trading activity may attract fewer takers even when its orders remain valid. Pool discovery through KyberEarn concerns a separate liquidity position; here, the aggregator connects trading demand with available orders. Wider access to potential takers does not ensure that a particular order wins a route or receives a fill.
Partial fills and the amount still available
A partial fill exchanges only part of the ordered quantity, leaving an unfilled remainder available while the order stays active. Each completed portion has already settled. The remaining amount can wait for another taker, reach expiry, or become subject to cancellation. An order can therefore show execution activity without reaching a fully filled state.
The order details can show the individual taker executions that contributed to its progress. Use those quantities to distinguish the original amount from the amount still awaiting exchange. Fully filled orders appear in Order History. Disappearance from the active list alone does not identify that outcome, because expiry and cancellation also close instructions. Cancelling a remainder cannot recover tokens that a completed fill has already exchanged.
Expiry limits the matching window
The selected expiry ends the time during which an unfilled order can execute. A longer window gives the market more time to reach an acceptable opportunity; it does not accelerate matching or repair missing funds. Expiry does not force a sale at the current market price. Any completed portions remain settled, while the unfilled portion stops being available for matching. Continuing the trade after expiry requires a new active instruction, with terms that reflect the intended trade.
Choices for an order that has not finished
The edit controls for an active order change the offered amount, target rate, or expiry while retaining the token pair. Editing replaces the old instruction through cancellation and creation of a new order. Where offered, Gasless Edit and Hard Edit handle that replacement differently. The selected method determines the signatures and network transaction involved.
| Order choice | What changes | Execution boundary |
|---|---|---|
| Leave the order active | Retains the existing trading terms | Matching remains conditional and ends at expiry or effective cancellation. |
| Edit the target rate | Replaces the price condition | Requires an active order; the new rate still needs a match. |
| Edit the sell amount | Changes the offered quantity | The new amount needs sufficient balance and contract allowance. |
| Edit the expiry | Changes the matching window | Unavailable once the order has expired or filled completely. |
| Gasless Cancel, where offered | Requests cancellation off-chain | Outstanding operator authorization can delay effective cancellation. |
| Hard Cancel | Sends an on-chain cancellation | Requires gas and takes effect after successful on-chain execution. |
| On-chain Cancel All | Invalidates the maker’s existing orders on the selected contract | Applies to that maker, contract, and network; completed fills stand. |
| Pair change | Editing retains the token pair. Trading a different pair requires a new order. | |
Where available, Gasless Edit uses separate signatures for cancellation and the replacement order. Hard Edit includes an on-chain action and requires gas.
How do I stop an order from filling?
Cancel the active order or its unfilled remainder, then confirm that the selected cancellation method has taken effect. Gasless Cancel stops the operator from issuing new fill authorizations. A taker can still use an outstanding valid authorization, so a pending request leaves a temporary execution window.
Gasless cancellation through Limit Order API v1.3.0 can remain pending for up to 5 minutes after recent operator authorization. The returned authorization expiry determines when that pending cancellation completes. If no valid operator authorization remains, cancellation can complete immediately. This waiting period concerns cancellation, not a promised time for filling the trade.
Hard Cancel invalidates the instruction on-chain once its transaction succeeds. Signing or submitting that transaction alone does not establish confirmed cancellation. A fill that settles before cancellation takes effect remains completed; neither cancellation method reverses it.
The price boundary when switching to an immediate swap
The maker’s signed rate governs a limit-order fill. The instant Swap interface instead uses a quote and minimum received amount, with a slippage setting that limits acceptable deviation. Raising that setting in Swap does not revise an existing signed limit order. An immediate swap can suit a trade that no longer needs to wait for its original target. It still depends on liquidity, the selected minimum output, and network execution. Accepting a current quote changes the price condition for the new trade.
Switching to Swap does not cancel an order that can still spend the same tokens.
Practical questions about Kyberswap limit orders
Can a fill return more tokens than the signed target requires?
A limit order can execute at a more favorable rate than its signed target. The target defines the acceptable price boundary, rather than a promise that every fill uses exactly that price. Better execution remains possible when the available matching trade supports it; the order record identifies the actual completed exchange.
Which token features can interfere with limit-order settlement?
Non-standard token behavior, including transfer fees or transfer restrictions, can interfere with settlement. The ERC-20 label alone does not describe every rule that a token contract applies. A token that deducts an amount during transfer can behave differently from one that delivers the full transferred amount, even when both expose standard token functions.
Does an open limit order create recurring gas charges?
Leaving a signed limit order open does not create recurring gas charges for the maker. Waiting does not require repeated wallet transactions. An earlier token approval and a later Hard Cancel are separate on-chain actions with network costs, so gasless waiting does not make every order-related action free.
Do several active orders reserve separate token balances?
Several active orders do not create separate reserves of the same token. When creating an order through Limit Order API v1.3.0, the balance check includes the new amount and remaining amounts of the maker’s active orders on the same pair and network. The allowance check includes the new amount and remaining amounts of all active orders selling that token through the contract on that network. Later wallet activity can still reduce the funds available for settlement.
Why might an active order be missing from the taker’s open-order results?
The taker’s open-order API normally excludes orders whose maker balance or allowance cannot cover the remaining sell amount. An integrator can explicitly request insufficiently funded orders. Absence from that response alone therefore does not prove a fill or cancellation; the order’s own status and execution details establish those outcomes.
Is an order’s expiry the same as its fill authorization deadline?
An order expiry limits the maker’s instruction, while an operator’s fill authorization has a separate validity window. That authorization can expire while the maker order remains open. A taker needs valid authorization for settlement; a fill transaction that the network includes after that authorization deadline reverts.
Can a limit order move the purchased token to another blockchain?
A limit-order fill settles the selected token trade on its chosen network and does not itself bridge the output asset. Cross-chain Swap handles movement and conversion between supported networks through separate routes. Availability of both functions in one interface does not turn a standard limit order into a cross-chain instruction.