> ## Documentation Index > Fetch the complete documentation index at: https://pond.dflow.net/llms.txt > Use this file to discover all available pages before exploring further. # Maker Flows > End-to-end flows for each fill type, showing what happens offchain and what happens onchain These charts follow a trade from the user's request to settlement. Each one separates what happens offchain from what happens onchain, so a maker can see which steps it serves over HTTP, which steps it performs in its own systems and which steps are Solana transactions. [Maker Quotes](https://pond.dflow.net/equities/makers/quotes.md), [Maker Direct Fills](https://pond.dflow.net/equities/makers/direct-fills.md) and [Maker Escrow Fills](https://pond.dflow.net/equities/makers/escrow-fills.md) define each endpoint, field and check. This page shows how they fit together. ## Reading the Charts * **Offchain:** the grey group. The user's app, DFlow, the maker's HTTP endpoints and the maker's own systems. * **Onchain:** the blue group. Solana and the orchestrator program, which holds the order and its escrow. * **Crossing the line:** an arrow from the offchain group to Solana is a transaction or an account read, and an arrow back is something the offchain side observes. DFlow never sends a transaction for the maker. * **Arrows:** solid arrows are requests or transactions, dashed arrows are replies or observed results, and open-headed arrows are notifications that nobody waits on. | | Direct fill | Escrow fill | | - | - | - | | `actionType` | `rfqFill` | `rfqOrder` | | Maker holds the output before the trade | Yes | No, it acquires it after the order opens | | Transactions | One, with two orchestrator instructions | Two, a user transaction and a maker transaction | | Who submits the fill | The maker, after last look on `/submit-transaction` | The maker, on its own schedule before the deadline | | Can the maker decline after selection | Yes, at last look | Yes, by closing the order or not filling it | | Sells | Yes | No | ## Direct Fill: Buying an Equity The maker quotes `rfqFill`, so it holds the equity. The user's transaction opens an order and fills it in the same transaction, and the maker co-signs the fill. ```mermaid theme={null} sequenceDiagram box rgba(130, 130, 130, 0.14) Offchain participant App as User App participant DFlow participant MM as Maker end box rgba(90, 140, 255, 0.16) Onchain participant Chain as Solana end App->>DFlow: GET /order, USDC to equity DFlow->>MM: POST /quote MM-->>DFlow: rfqFill quote with the maker's token accounts DFlow->>DFlow: Pick the best quote and build the transaction DFlow-->>App: Transaction with open_rfq_order and fill_rfq_order DFlow-)MM: POST /selected, a notification Note over MM: Store the quote ID and order address
The fill must name this order App->>App: User signs App->>DFlow: POST /submit-transaction with the signed transaction DFlow->>MM: Forward to the maker's POST /submit-transaction MM->>MM: Last look: check the order, the terms and the quote's expiry alt If the maker accepts MM->>Chain: Co-sign and submit rect rgba(90, 140, 255, 0.16) Note over Chain: open_rfq_order escrows the user's USDC
fill_rfq_order moves it to the maker net of fees,
pays the equity to the user and closes the order end MM-->>DFlow: accepted with txSignature DFlow-->>App: Result else If the maker rejects MM-->>DFlow: rejected with a rejectionCode DFlow-->>App: Error, nothing was submitted end ``` 1. **Quote:** the maker answers `/quote`. The quote names the maker's own input and output token accounts. 2. **Selection:** DFlow builds the transaction after it picks the quote. The order address exists only from this point, so `/selected` carries it. DFlow does not wait for the answer. 3. **User signature:** the user signs before the maker sees the transaction. 4. **Last look:** the maker checks the transaction against the quote ID and order address it stored from the notice. Nothing is onchain yet, so a rejection costs nobody anything. 5. **Settlement:** the maker co-signs and submits. The order opens, fills and closes in one atomic transaction. The user never holds an open order. ## Direct Fill: Selling an Equity A sell is always a direct fill. The maker pays USDC from its inventory, so it needs the settlement mint on hand. The flow matches a buy with the token directions reversed. ```mermaid theme={null} sequenceDiagram box rgba(130, 130, 130, 0.14) Offchain participant App as User App participant DFlow participant MM as Maker end box rgba(90, 140, 255, 0.16) Onchain participant Chain as Solana end App->>DFlow: GET /order, equity to USDC DFlow->>MM: POST /quote with acceptedActionTypes of rfqFill only MM-->>DFlow: rfqFill quote DFlow-->>App: Transaction with open_rfq_order and fill_rfq_order DFlow-)MM: POST /selected, a notification App->>App: User signs App->>DFlow: POST /submit-transaction DFlow->>MM: Forward to the maker's POST /submit-transaction MM->>MM: Last look alt If the maker accepts MM->>Chain: Co-sign and submit rect rgba(90, 140, 255, 0.16) Note over Chain: open_rfq_order escrows the user's equity
fill_rfq_order moves it to the maker net of fees,
pays USDC to the user and closes the order end MM-->>DFlow: accepted with txSignature DFlow-->>App: Result else If the maker rejects MM-->>DFlow: rejected DFlow-->>App: Error, nothing was submitted end ``` ## Escrow Fill: Buying an Equity The maker quotes `rfqOrder` because it does not hold the equity. The user's transaction only opens the order and escrows the USDC. The maker acquires the equity offchain, then fills the order in a transaction of its own. ```mermaid theme={null} sequenceDiagram box rgba(130, 130, 130, 0.14) Offchain participant App as User App participant DFlow participant MM as Maker Endpoints participant Src as Maker's Equity Source end box rgba(90, 140, 255, 0.16) Onchain participant Chain as Solana end App->>DFlow: GET /order, USDC to equity DFlow->>MM: POST /quote MM-->>DFlow: rfqOrder quote with no token accounts DFlow->>DFlow: Pick the best quote and build the transaction DFlow-->>App: Transaction with open_rfq_order DFlow-)MM: POST /selected, a notification Note over MM: Queue the order address
The account does not exist yet App->>App: User signs App->>Chain: Submit transaction 1 to Solana rect rgba(90, 140, 255, 0.16) Note over Chain: open_rfq_order escrows the user's USDC
The order stores the maker, quoted_in, quoted_out
and last_fillable_slot end loop Until the blockhash expires, about 150 slots MM->>Chain: Look for the order account end Chain-->>MM: Order account and escrow balance rect rgba(130, 130, 130, 0.14) MM->>Src: Acquire the equity offchain Src-->>MM: Purchase confirmed end rect rgba(90, 140, 255, 0.16) Src->>Chain: Move the equity tokens into the maker's output token account Chain-->>MM: Maker reads the token balance end alt If the maker fills by last_fillable_slot MM->>Chain: Submit transaction 2 with fill_rfq_order rect rgba(90, 140, 255, 0.16) Note over Chain: The maker receives the USDC net of fees
The user receives the equity at the destination
Unused USDC returns to the user
The order closes and emits a fill event end Chain-->>App: Order account closed, fill event else If the maker cannot acquire the equity MM->>Chain: Close the order rect rgba(205, 170, 110, 0.28) Note over Chain: The whole escrow returns to the user
A cancel event is emitted end Chain-->>App: Order account closed, cancel event else If nobody fills by last_fillable_slot Note over Chain: Anyone can close the order
The whole escrow returns to the user
An expire event is emitted Chain-->>App: Order account closed, expire event end ``` 1. **Quote:** the quote carries no token accounts, because the maker picks them when it fills. 2. **Selection:** `/selected` arrives before the user signs. The order account may never exist if the user declines or the transaction fails, so the maker waits for it and does not refuse the notification. 3. **Transaction 1:** the user's app submits it to Solana itself. DFlow does not forward it, and the maker does not co-sign it. Its orchestrator instruction only opens the order and escrows the USDC. 4. **Acquisition:** the maker starts once it sees the order account. The purchase is offchain, but the equity must then arrive as tokens in the maker's output token account, which is an onchain step. The next section describes both. 5. **Transaction 2:** the maker fills the order with its own transaction. DFlow does not call `/submit-transaction` for an `rfqOrder` quote. 6. **Outcome:** the order ends in a fill, a cancel or an expiry. The app watches transactions that mention the order for its final `RfqOrderEvent`. [Detecting Escrow Fill Outcomes](https://pond.dflow.net/equities/onchain-fill-parsing.md#detecting-escrow-fill-outcomes) describes how. ### Acquiring the Equity Offchain DFlow sees none of the acquisition. The maker buys the equity through whatever source it uses, in its own systems and on its own terms. Everything the maker needs to size and time the purchase is onchain in the order account and its escrow. The acquisition has an onchain half. A purchase offchain gives the maker no way to pay the user until the equity exists as tokens in the token account the fill pays from. Your source or your own systems must mint or transfer those tokens to that account with a Solana transaction, and the maker confirms the balance before it fills. | The maker reads | From | Use | | - | - | - | | The USDC escrowed | The order's escrow token account | Sets how much equity the fill can need. | | `quoted_in` and `quoted_out` | The order account | The price is `quoted_out ÷ quoted_in`, and the maker pays at most `quoted_out`. | | `last_fillable_slot` | The order account | The deadline for the purchase and the fill. | * **Amount:** the maker pays `received × quoted_out ÷ quoted_in`, rounded down, where `received` is the USDC that reaches its account after any platform fee or Token-2022 transfer fee. The escrow can be smaller than the quote's ceiling, so the maker sizes the purchase from the escrow it reads. * **Price risk:** the price is fixed by the quote and the maker alone bears any move in the market while it acquires the equity. * **Deadline:** the fill must land by `last_fillable_slot`. The maker also needs the equity in the token account it pays from before it submits, because the transaction reverts if that account cannot cover the payment. * **Failure:** a maker that cannot acquire the equity closes the order by `last_fillable_slot` instead of leaving it to expire. The close returns the user's USDC at once. The maker fills with the equity already in its token account. The fill itself is the same instruction a direct fill uses, described in [Read the Fill Instruction](https://pond.dflow.net/equities/makers/direct-fills.md#read-the-fill-instruction). ### Order Lifecycle An order has one onchain account. Each transition emits an `RfqOrderEvent`. A fill, cancel or expiry also closes the account. ```mermaid theme={null} stateDiagram-v2 [*] --> Open: User's transaction, open event Open --> Filled: Maker fills by last_fillable_slot Open --> Cancelled: Maker closes by last_fillable_slot Open --> Expired: Anyone closes after last_fillable_slot Filled --> [*] Cancelled --> [*] Expired --> [*] ``` | Transition | Who | When | Result for the user | | - | - | - | - | | Fill | The order's maker | At or before `last_fillable_slot` | Receives the equity, and any unused USDC returns. | | Cancel | The order's maker | At or before `last_fillable_slot` | The whole escrow returns. | | Expire | Anyone | After `last_fillable_slot` | The whole escrow returns. | The user cannot close the order. `last_fillable_slot` is the earlier of the slot of the quote's expiry and the open slot plus up to 150 slots. [Fill Deadline](https://pond.dflow.net/equities/makers/escrow-fills.md#fill-deadline) describes how it is set.