> ## 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 Direct Fills > How a maker confirms a selected quote and gives last look before a direct fill settles A direct fill settles in one transaction with two orchestrator instructions. The first opens an order that escrows the user's input. The second, `fill_rfq_order`, fills that order from the maker's inventory. The user signs, then DFlow sends the transaction to the maker's `/swap`. The maker co-signs and submits. ## Selected Quote DFlow calls `POST /selected` before it hands the transaction to the user. ```json theme={null} { "requestId": "", "quoteId": "", "actionType": "rfqFill", "taker": "", "orderAddress": "" } ``` The maker checks that `quoteId` is one of its live quotes and records a ticket: the `orderAddress` that the fill must name. To refuse, the maker returns `409` (or `422`) with `{ "reason": "" }`. Any 2xx accepts. * **Idempotent:** the same `quoteId` and `orderAddress` can arrive more than once. * **Budget:** 0.9 seconds including retries. DFlow retries once after 250 ms on a transport error, a timeout, `429` or `5xx`, with the same body. * **Failure:** any answer other than a 2xx fails the selection, so the user never receives a transaction the maker will not sign. ## Read the Fill Instruction The fill is the orchestrator's `fill_rfq_order` instruction. A maker can decide whether to co-sign from this instruction alone. Its data states the price and the most the maker receives, and the program reverts the fill unless the order carries the same terms. The instruction that opens the order cannot change them. ### Fill Instruction Data The data is 24 bytes: | Bytes | Field | Type | Meaning | | - | - | - | - | | 0-7 | Discriminator | `[50, 203, 135, 122, 42, 118, 61, 47]` | Identifies `fill_rfq_order`. | | 8-15 | `quoted_in` | u64, little-endian | The most input the maker receives, after any input-side platform fee. | | 16-23 | `quoted_out` | u64, little-endian | What the maker pays for `quoted_in`, before any output-side platform fee. | ### What the Fill Data Guarantees * **Price:** `quoted_out ÷ quoted_in`. Platform fees never enter it. * **Ceiling:** the maker receives at most `quoted_in` of the input mint and pays at most `quoted_out` of the output mint. * **Payment:** the maker pays `received × quoted_out ÷ quoted_in`, rounded down, where `received` is what its receiving account gained. A smaller fill pays the same price. A fill that receives nothing reverts. * **Terms:** the program reverts the fill unless the order's `quoted_in` and `quoted_out` equal these two values. * **What the opening instruction controls:** how much input the user escrowed, which sets how much arrives, up to the ceiling. It cannot change the price or the ceiling. * **Destination:** where the payment goes does not change what the maker pays or receives. ### Fill Instruction Accounts The instruction has 18 fixed accounts. The program pins each one to the order or to a known program id, except the maker's own token accounts, 12 and 13. | Position | Account | Writable | Meaning | | - | - | - | - | | 0 | `maker` | Yes, signer | Must be the order's maker. Pays rent for any user token account the fill creates, reimbursed from the order's rent. | | 1 | `order` | Yes | The RFQ order. The fill closes it. | | 2 | `order_vault` | Yes | The order's escrow token account. | | 3 | `input_mint` | Yes | The mint the maker receives. Writable so withheld Token-2022 transfer fees can be harvested. | | 4 | `output_mint` | No | The mint the maker pays. | | 5 | `input_token_program` | No | The owner of `input_mint`. | | 6 | `output_token_program` | No | The owner of `output_mint`. | | 7 | `destination_ata` | Yes | The destination wallet's token account for `output_mint`. It receives the payment. | | 8 | `destination_wallet` | No | The order's destination wallet. | | 9 | `refund_ata` | Yes | The refund wallet's token account for `input_mint`. It receives any unused input. | | 10 | `refund_wallet` | No | The order's refund wallet. | | 11 | `rent_recipient` | Yes | Receives the order's rent. | | 12 | `maker_receive_account` | Yes | The maker's token account that receives the input. Its mint must be `input_mint`. | | 13 | `maker_source_account` | Yes | The maker's token account that pays the output. | | 14 | `associated_token_program` | No | The associated token program. | | 15 | `system_program` | No | The system program. | | 16 | `event_authority` | No | The program's event authority. | | 17 | `program` | No | The orchestrator program. | When the order has a platform fee, the next three accounts are the fee recipient, which must be the order's fee account, DFlow's fee token account, and DFlow's fee authority. Any Token-2022 transfer hook accounts follow. DFlow keeps accounts 0, 1, 3, 4, 12 and 13 as static keys in the transaction. The others may come from address lookup tables, so the maker resolves lookups before reading them. ### Example: Reading a Fill This instruction data is 24 bytes, shown by field: ```text theme={null} 32cb877a2a763d2f 4004fb0b00000000 4015e73b00000000 discriminator quoted_in quoted_out ``` `quoted_in` is 201,000,000 and `quoted_out` is 1,005,000,000, so the price is 5. The maker pays for the input its account receives: | Input received | Output paid | | - | - | | 201,000,000 | 1,005,000,000 | | 100,000,000 | 500,000,000 | | 1 | 5 | ## Last Look DFlow calls `POST /swap` with the user-signed transaction. ```json theme={null} { "requestId": "", "transaction": "" } ``` The fill is the orchestrator's `fill_rfq_order` instruction, described in [Read the Fill Instruction](#read-the-fill-instruction). Before co-signing, the maker checks that: 1. Exactly one instruction names the maker's wallet, and it is a `fill_rfq_order`. 2. The fill names the ticket's `orderAddress`. A fill for an unknown order is rejected. 3. The ticket has not been co-signed already. An exact repeat of the same transaction bytes returns the same `txSignature`. Different bytes for a used ticket are rejected. 4. `quoted_in` is the quote request's `maxAmountIn`, or its `amount` when the request has none, and `quoted_out` is `quoted_in × amountOut ÷ amountIn`, rounded down. 5. The fill's mint accounts are the quote's `tokenIn` and `tokenOut`, and its token accounts are the quote's `makerInputTokenAccount` and `makerOutputTokenAccount`. 6. The quote has not expired. 7. If the maker pays fees, the compute budget and priority fee instructions are within the maker's limits. The maker does not need to read the order. The program reverts the fill unless the order names this maker and these mints, and the maker pays the order's price for the input it receives. [Maker Escrow Fills](https://pond.dflow.net/equities/makers/escrow-fills.md#fill-an-order) describes how the program prices and checks the fill. The maker should still simulate the transaction and compare its own balance changes with the quote. The maker then co-signs, submits the transaction, and answers within 8 seconds. DFlow never retries `/swap`. ```json theme={null} { "state": "accepted", "txSignature": "" } ``` ```json theme={null} { "state": "rejected", "rejectionCode": "terms_mismatch", "rejectionReason": "" } ``` `accepted` requires `txSignature`. DFlow checks that it belongs to the transaction and does not confirm it. `rejectionReason` is logged and never shown to the integrator. `rejectionCode` is the only rejection detail the integrator sees: | `rejectionCode` | When | | - | - | | `quote_expired` | The quote's lifetime has passed. | | `quote_unknown` | The maker has no live quote or ticket for the transaction. | | `quote_already_used` | The quote was already filled. | | `terms_mismatch` | The fill does not match the quoted terms. | | `transaction_not_allowed` | Another instruction names the maker, or the transaction has a disallowed fee payer or disallowed compute budget settings. | | `declined` | The maker declined at last look. An absent or unrecognized code reads as `declined`. |