EVM Limit Orders
Contract architecture for APY-priced PT/YT orders, partial fills and atomic settlement.
EVM limit orders exchange PT or YT for a registered market's underlying, interest-bearing token (IBT), or supported vault share. A maker signs the amount offered and an implied APY. The counter-amount is computed at fill time from that APY, the remaining time to maturity and live token values.
Orders are stored offchain in an order book. Settlement, pricing, fees and token conversions are enforced by the contracts below. A Curve pool is not required to fill a signed order.
Contract roles
| Contract | Responsibility |
|---|---|
1inch LimitOrderProtocol v4.3.2 | Validates authorization, expiry and invalidation; computes fill amounts through getters and executes transfers. |
SpectraPtYtRateAmountGetter | Prices PT/YT at the signed APY using registered market identity and current claim values. It only performs read operations. |
SpectraRateFeeTaker | Applies the taker fee through the amount-getter and post-interaction callbacks, then distributes payment to the maker and fee collector. |
SpectraLimitOrderBatchFiller | Takes per-token budgets from its caller, fills multiple orders and refunds unused amounts. |
SpectraLimitOrderTokeniser | Mints IBT into PT+YT or redeems PT+YT into IBT during settlement; converts the maker's underlying or vault-share leg where required. |
SpectraLimitOrderSigner | Allows a Safe-authorized delegatecall to approve a structured order hash for contract-wallet signatures. |
SpectraAuthorizedTakersGuard | Optionally restricts the immediate settlement caller through a signed address list. |
| Router's 1inch limit-order module | Exposes command 0x27 for batch fills within a larger atomic transaction. |
Settlement flow
This diagram shows contract calls for a batch fill. The dotted branch is used only when a fill needs minting or redemption.
- Payment: the fee taker forwards the maker's fee-free payment and sends the fee to the registry's fee collector.
- Output: the caller receives the maker asset directly, or the tokeniser's proceeds when a conversion is needed.
- Refund: the batch filler returns unused budgets to its caller.
The maker approves the offered token to LimitOrderProtocol and authorizes
the order before it can fill. Signing does not escrow or reserve tokens.
For batch fills, settlement and guards see the batch filler as the immediate
taker. When the caller is the router, later commands convert, check and
transfer outputs and refunds to the recipient.
A failed fill reverts its state changes. A batch can skip failed settlement calls when requested, but its final minimum and the transaction's output checks can still revert the whole transaction.
Integration boundaries
- The router command uses the batch filler's
FillandBudgettuples. - During router flash loans, callback authorization is consumed before executing commands. An external hook cannot reuse it; an explicit nested loan establishes its own authorization.
Interfaces
- Order format and lifecycle: fields, pricing views, fills, invalidation and events.
- Batch settlement: batch and tokeniser inputs/outputs, router commands and failure conditions.
- Order-book HTTP API: request/response formats, token units, enum values and errors.
- Order encoding: signature domain, byte layouts, extension offsets and trait bitfields.