> For the complete documentation index, see [llms.txt](https://docs.pairity.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pairity.fi/protocol/liquidity-and-settlement.md).

# Liquidity and settlement

## Vault liquidity

Liquidity providers deposit the supported underlying and quote assets into the Pair Vault. The vault values its assets using the oracle and active series marks, then issues shares representing a pro-rata claim on the vault NAV.

Withdrawals return the vault's supported assets and active series inventory pro rata, subject to the vault's available liquidity and route rules.

## Inventory routes

For a trade, the router can coordinate several routes:

1. Deliver the requested asset from existing inventory.
2. Mint a complete set from underlying or strike-value quote collateral, then sell or retain the other leg.
3. Merge matching Base and Call or Base and Put tokens back into collateral.
4. Use an external asset-conversion route when the configured fallback is available.

The Pair Vault is the asset boundary. Price impact and inventory changes must be based on the assets actually received by the Pair Vault, not only on values reported by the router.

## NAV and risk

NAV combines real underlying, quote and option inventory. The oracle provides spot for underlying valuation. Active series are marked using the same Base/Call/Put decomposition as trading.

The AMM's X/Y values are pricing-state values and should not be interpreted as a complete statement of the vault's token holdings. The real balances determine route availability, collateral capacity, inventory fees and withdrawal behavior.

## Expiry

Series have a fixed expiry timestamp. Before expiry, the series can be traded if it is active and allowed. After expiry, it must not be offered as an active trading series.

At expiry:

```
Base = min(spot, strike)
Call = max(spot - strike, 0)
Put  = max(strike - spot, 0)
```

The keeper can trigger the settlement or state transition flow. The backend indexes the resulting contract events and exposes separate settlement records for separate legs, even when multiple legs are emitted in one transaction.

## Settlement records

A single transaction can settle more than one leg. The backend records each leg independently:

* Base settlement
* Call settlement
* Put settlement

This preserves the actual number of settlement outcomes and lets the frontend display profit or loss for each leg rather than collapsing everything into one transaction row.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.pairity.fi/protocol/liquidity-and-settlement.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.