# 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="https://2608572446-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FesXIGSYvKcOjqMTCdsjo%2Fuploads%2FRR2YIL8mMudumd7lQS0M%2FScreenshot%202024-11-11%20at%202.02.27%E2%80%AFPM.png?alt=media&#x26;token=b9814511-344e-4b12-8cac-ab1b9454360a" 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="https://2608572446-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FesXIGSYvKcOjqMTCdsjo%2Fuploads%2FTiW5EFuZM99PKPGzUe4P%2FScreenshot%202024-11-11%20at%202.24.25%E2%80%AFPM.png?alt=media&#x26;token=f2458802-6894-4442-9971-cf749e2ec59f" 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;