1inch
1inch limit orders let takers execute swaps under signed price and fill conditions
1inch limit orders let a taker exchange your tokens on-chain when a signed order permits the trade. You are the maker: you specify the tokens, exchange amounts, and any expiry before signing the order off-chain. A taker discovers that order and submits a transaction that fulfills its terms, paying the settlement gas. Your tokens remain in your wallet until execution, so the required balance and spending permission must exist at fill time. Reaching a displayed market price does not ensure a fill. Executable liquidity, taker economics, and the order's quantity settings determine whether settlement happens.
Waiting for a limit price or submitting a market swap
A fixed-price limit order suits a trade that can wait for its specified exchange terms. Market mode submits a swap using available aggregated liquidity, subject to its execution settings and blockchain confirmation. Fusion also uses signed orders with auction pricing. Its auction conditions belong to that execution mode; a conventional fixed-price order keeps its signed exchange ratio.
Why can the market reach my price without a fill?
A displayed price can differ from executable liquidity, and a taker needs an economic reason to fill the order. A chart crossing alone cannot establish either condition.
Prices that a taker can execute
Charts combine price observations that can differ from the rate available for the selected trade. The order's size matters because liquidity that supports a small exchange may not support the entire quantity. Takers weigh the exchange terms against gas costs and their potential margin. A thinly traded pair may attract few participants, while a brief price movement may leave little opportunity for profitable settlement.
Balances and spending permission
The signed order can remain visible while its maker wallet lacks sufficient tokens or the required spending permission. Publication does not reserve a balance for later execution. Other transfers or trades can therefore change the quantity that remains available. If partial fills are permitted, a smaller funded quantity may still be executable under the order's terms.
Orderbook status data distinguishes insufficient balance, missing approval, and an unfavorable price, identifying different obstacles to settlement.
What does a taker submit to settle the trade?
A taker submits the signed order, a fill amount, and the execution arguments that the chosen contract function requires. Settlement occurs through an on-chain transaction.
The signed amounts and contract checks
The 1inch Limit Order Protocol v4 uses EIP-712 typed signatures on Ethereum Virtual Machine (EVM) networks. The maker asset is the offered token, and the taker asset is its payment. Their signed amounts define the basic rate; changing them requires a new signature. Publication through the Orderbook API makes orders discoverable through aggregation.
The contract checks authorization, remaining availability, expiry, and any permitted-caller restriction. An extension can add a predicate, a condition that the contract tests during execution. A plain fixed-price order encodes exchange amounts without needing a chart feed. The submitted quantity must meet the fill settings, and applicable extensions must match the signed data.
The token transfers
For an ordinary token fill, the protocol transfers the maker asset to the taker's specified recipient. It transfers the payment asset to the receiver named in the order, defaulting to the maker when no separate receiver is specified. Both transfers settle atomically: a failed required transfer reverts the fill.
Fill settings control quantity and counterparty access
Protocol v4 separates who may fill an order from how much may fill and which additional conditions apply. These capabilities can combine, although a particular trading interface may expose only some settings.
| Order setting | Settlement requirement | Fill opportunity | Maker control |
|---|---|---|---|
| Open taker access | No allowed-sender restriction | Any taker meeting the remaining terms | Tokens remain in the maker wallet until execution |
| Restricted taker access | Caller matches the allowed sender | Only the permitted caller | Maker limits who may execute the order |
| Full-amount execution | The full maker amount fills | One complete fill | Maker excludes partial execution |
| Repeatable partial execution | Partial and multiple fills are both enabled | Several fills within the remaining quantity | Unfilled tokens remain in the maker wallet |
| Conditional execution | The on-chain predicate evaluates true | A fill while the additional condition holds | Maker specifies an additional execution condition |
| Settings can combine in one order, and each fill must satisfy the resulting terms. | |||
A basic fixed-rate partial fill exchanges amounts proportionate to the signed totals, subject to integer rounding. Permission for partial fills allows a smaller execution. Permission for multiple fills allows later executions against the remaining quantity. Enabling the first permission alone does not preserve repeatable execution. Disallowing partial execution requires the full maker quantity in one fill.
Signing, token approval, and settlement have different gas costs
Signing an order off-chain does not consume blockchain gas, while an on-chain token approval requires a network fee. Existing spending permission may remove that approval step. A permit can avoid a separate approval transaction where the token and chosen spending mechanism support it. The approval or permit authorizes token spending; the order signature authorizes the specified trade. Neither operation, by itself, proves that tokens have been exchanged. Manual on-chain cancellation also costs gas, even though creating the signed order does not.
The taker funds the transaction that settles the fill. More expensive gas can make the same order less appealing without changing its terms.
Expiration and cancellation limit future execution
An order with an expiration deadline cannot be filled after that deadline. Expiration prevents further execution without a separate cancellation transaction. It does not return tokens because an ordinary off-chain order never deposited them into escrow. If the order already filled partially, expiration applies to the remaining opportunity; it does not reverse the completed transfers.
Manual cancellation invalidates the order through an on-chain transaction. Its cancellation mechanism depends on the signed fill settings, so invalidation can operate through an order hash or nonce. Submitting a cancellation leaves a period before blockchain confirmation during which a still-valid order may fill. The order of confirmed execution matters; cancellation cannot undo a fill that completed first.
Moving tokens away can prevent a fill without permanently invalidating the signature. Restoring sufficient funds can make an otherwise valid order executable again. Changing the desired price creates new signed terms, so the earlier order also needs cancellation or expiry if it must stop being fillable.
Order records and confirmed transfers show different states
An order hash identifies signed terms, while a confirmed fill records an executed exchange. The Orderbook API exposes fill and cancellation events associated with an order, alongside its remaining maker amount. A valid or active listing indicates an execution opportunity, not receipt of the bought tokens. Partial fills leave an executed quantity and a remaining quantity. A zero remaining amount needs context because cancellation and completed execution can both prevent further fills.
Transaction status and token-transfer records establish what settled and which addresses received the assets. A fixed-price order can wait unfilled while preserving its exchange terms. A market swap submits against available liquidity under its execution constraints, with completion subject to blockchain confirmation.
Frequently asked questions about 1inch limit orders
Can a smart-contract wallet create a limit order that takers can fill?
Yes, Protocol v4 includes fill functions for orders with contract-based signatures. The maker contract's signature-validation logic must accept the supplied signature, and the taker must use the corresponding contract-order fill function. The trading interface also needs to support the wallet's signing flow; protocol-level support does not establish compatibility with every interface.
What makes a fixed-price limit order different from a stop-loss instruction?
A plain limit order defines exchange amounts, while a stop-loss design requires an additional trigger condition. Protocol v4 supports predicates that check on-chain conditions at fill time. A stop-loss application must define its trigger and acceptable execution terms. Selecting a limit price alone does not establish that trigger or ensure a taker when it activates.
Does an off-chain signature keep my limit-order terms confidential?
Off-chain signing does not make an order confidential. Orders published to the orderbook can be retrieved by other participants, and successful fills produce on-chain transaction records. A restricted-taker setting controls which caller may execute the order. It does not, by itself, encrypt the order's terms or conceal the settled token transfers.
Can an allowance change affect several open limit orders?
For orders using direct ERC-20 approval, changing the shared allowance can affect several orders from the same maker wallet. That permission belongs to a specific token, spender, and network. Reducing it may prevent otherwise valid fills. Order cancellation changes the protocol's invalidation state without necessarily changing the token allowance.
Why can a partial-fill calculation show a rounding difference?
The standard fixed-rate calculator uses integer token units and rounds its calculated amounts. When a fill specifies the maker-token quantity, it rounds the required taker-token payment upward. When the fill specifies the payment quantity, it rounds the maker-token output downward. Small quantities can make rounding more visible; custom amount getters can apply different calculations.