> For the complete documentation index, see [llms.txt](https://docs.perennial.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.perennial.finance/protocol/intents/offchain-infrastructure.md).

# Offchain Infrastructure

Perennial's Intent specification focuses on the onchain mechanism that make intents possible. Interfaces, Makers and/or Infrastructure provides are welcome to implement their own offchain system that efficiently handles & distributes Perennial's Intents.\
\
However when designing the Intent system, an example **Solver API** used:

## Market Orders

<figure><img src="/files/Ut5DKUjADUB5LEH2mOKF" alt=""><figcaption><p>An example offchain flow for Intents describing market orders</p></figcaption></figure>

The above diagram describes a centralized Solver API for:

1. Accepting, aggregating & distributing information about the pricing of **Maker** liquidity
2. Accepting a signed Intent from a **Taker** & returning it to the originating **Maker**&#x20;
3. The execution of the Intent order by the **Maker**

### Key Concepts

#### Continuous Pricing

**Makers** within the system continuously post arrays of order sizes and their corresponding prices to the **Solver API**. The quotes they post are valid for 30 seconds. These prices include all fees accrued by the **Maker** when executing this order to ensure the user gets guaranteed execution at the quoted price.

These prices are then aggregated by the Solver API and pushed out to all subscribed **Takers**. The **Taker** will input the size of their transaction, the price for that order size will be shown, they then sign and return the order to **Solver API** which relays it to the maker for execution.

#### Fill Rate

Not pictured in the diagram, but crucial for the operation of the **Solver API** is a "fill rate". Where **Makers** must maintain a minimum fill rate (filled intents / signed intents returned) when participating in the Solving system. This grants some flexibility in cases of extreme price movement, while ensuring a good trading experience to the **Takers**.

## Trigger Orders

<figure><img src="/files/5l0NTW42YjhmDUZ1wnl7" alt=""><figcaption><p>An example offchain flow for Intents describing trigger orders</p></figcaption></figure>

The above diagram describes a flow for a Solver API to handle trigger Intents:

1. **Taker** publishes signed intent with direction, size, and desired execution price to the **Solver API**
2. **Makers** poll the **Solver API** periodically, and when they find an intent with a desirable price, they execute the transaction.&#x20;

### Key Concepts

#### Competitive Fills

In order to ensure reasonable execution for **Takers**, its key that the trigger orders are shared amongst all **Makers** within the Solving system. In a scenario where there is a single **Maker** in the Solving system, a **Takers** intent may be neglected for the benefit of the **Maker**.

#### Culling Invalid Orders

Periodically the **Solver API** should review the submitted trigger orders for validity. This includes things like the expiry of the order but also the collateral balance of the **Taker** which has submitted the Intent order.&#x20;