> For the complete documentation index, see [llms.txt](https://docs.term.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.term.finance/terminal-1-execution/workflows/intents-limit-orders/takers-filling-intents.md).

# Takers (filling intents)

As a taker, you fill an existing intent by matching it within its constraints. If the required tokens are available and the necessary approvals, permits, and authorizations remain valid at execution time, the fill is guaranteed to execute according to those constraints. However, intents displayed in the UI may become stale as on-chain state changes. Terminal 1 revalidates each intent at execution and fails safely if its constraints can no longer be satisfied.

### When to fill an intent

* You want to take the displayed rate in a specific market (Term Repo) and maturity.
* You want a defined outcome (fixed term) without negotiating bilateral terms off-platform.
* You want to fill immediately (or opportunistically) when liquidity is present.

### What you are filling (market scope)

Every intent is scoped to a specific **Term Repo (market)**. The market defines:

* Maturity date
* Loan token (purchase token)
* Collateral token(s)
* Collateral ratio / risk parameters

### What the intent constrains

* **Direction:** borrow or lend
* **Rate:** minimum (for lender-side intents) or maximum (for borrower-side intents)
* **Size:** requested size and any minimum fill constraints (if applicable)
* **Expiry:** the intent must be unexpired
* **Optional taker:** if set, only the specified taker can fill
* **Partial fills:** you may fill less than the full remaining size if the intent and route allow it

### Preview vs execution

* **Preview/UI display:** best-effort view of intents and estimated fillability under current conditions.
* **Execution-time checks:** the onchain transaction is the source of truth. At execution time, Terminal 1 verifies the intent can be filled under its constraints and that the required funding/authorizations for settlement are available.

A key implication: **intent validity is dynamic**. Funds can move, approvals can be changed or revoked, and what you see in the UI may be stale.

### Common reasons fills fail

* The intent expired.
* Optional taker restriction blocks your fill.
* The remaining fillable size changed (already partially filled or cancelled).
* Maker-side validity changed:
  * underlying funding source availability moved (wallet balance, ERC‑4626 withdrawable, Aave/Morpho capacity)
  * approvals/authorizations changed or were revoked
* Route constraints fail at execution time (fees, slippage exposure, UI buffers, venue compatibility).
* Venue-level revert (market paused, capacity unavailable, external venue conditions changed).

### What to review before executing

* The market (maturity, tokens, collateral parameters) and the intent constraints (direction, rate, size, expiry, optional taker).
* Whether the intent is likely to be fillable *now* (recent activity, remaining size, current liquidity).
* The execution path and dependent steps (route sequence, venues used where visible).
* Fees/slippage exposure if the fill relies on swaps or external venues.
* Any warnings about validity or staleness surfaced by the UI.

### Notes

Offchain signed intents are distributed through our current order store for discovery; fills are still enforced by onchain constraints. If an intent is fillable under its constraints, any eligible taker can attempt to fill it by submitting a transaction.