# EVM Limit Orders



EVM limit orders exchange PT or YT for a registered market's underlying,
interest-bearing token (IBT), or supported [vault share](/docs/integration-reference/evm-limit-orders/orders#rate-orders). 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-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 [#settlement-flow]

This diagram shows contract calls for a batch fill. The dotted branch is used
only when a fill needs minting or redemption.

<Mermaid
  chart="flowchart TD
  C[&#x22;Taker / router&#x22;] -->|&#x22;fillMany&#x22;| B[&#x22;Batch filler&#x22;]
  B -->|&#x22;Fill each order&#x22;| L[&#x22;1inch settlement&#x22;]
  L -->|&#x22;Pricing & fees&#x22;| F[&#x22;Fee taker&#x22;]
  F -->|&#x22;Quote&#x22;| G[&#x22;Rate getter&#x22;]
  L -.->|&#x22;Optional conversion&#x22;| T[&#x22;Tokeniser<br/>Mint / redeem PT + YT&#x22;]"
/>

* **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 [#integration-boundaries]

* The router command uses the batch filler's
  [`Fill` and `Budget` tuples](/docs/integration-reference/evm-limit-orders/quotes-and-execution#data-structures).
* 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 [#interfaces]

* [Order format and lifecycle](/docs/integration-reference/evm-limit-orders/orders):
  fields, pricing views, fills, invalidation and events.
* [Batch settlement](/docs/integration-reference/evm-limit-orders/quotes-and-execution):
  batch and tokeniser inputs/outputs, router commands and failure conditions.
* [Order-book HTTP API](/docs/integration-reference/evm-limit-orders/order-book-api):
  request/response formats, token units, enum values and errors.
* [Order encoding](/docs/integration-reference/evm-limit-orders/encoding):
  signature domain, byte layouts, extension offsets and trait bitfields.