Maker Direct Fills

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.

{
  "requestId": "<same across retries>",
  "quoteId": "<the maker's quote id>",
  "actionType": "rfqFill",
  "taker": "<user wallet, base58>",
  "orderAddress": "<base58>"
}

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": "<text>" }. 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:

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.

{ "requestId": "<id>", "transaction": "<base64 transaction>" }

The fill is the orchestrator’s fill_rfq_order instruction, described in Read the Fill Instruction. Before co-signing, the maker checks that:

Exactly one instruction names the maker’s wallet, and it is a fill_rfq_order.
The fill names the ticket’s orderAddress. A fill for an unknown order is rejected.
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.
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.
The fill’s mint accounts are the quote’s tokenIn and tokenOut, and its token accounts are the quote’s makerInputTokenAccount and makerOutputTokenAccount.
The quote has not expired.
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 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.

{ "state": "accepted", "txSignature": "<fee payer signature>" }

{ "state": "rejected", "rejectionCode": "terms_mismatch", "rejectionReason": "<text>" }

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`.

Spot Trading

Crypto

Tokenized Equities

Equity Makers

Cross-Asset

Maker Direct Fills

Selected Quote

Read the Fill Instruction

Fill Instruction Data

What the Fill Data Guarantees

Fill Instruction Accounts

Example: Reading a Fill

Last Look

​Selected Quote

​Read the Fill Instruction

​Fill Instruction Data

​What the Fill Data Guarantees

​Fill Instruction Accounts

​Example: Reading a Fill

​Last Look

Selected Quote

Read the Fill Instruction

Fill Instruction Data

What the Fill Data Guarantees

Fill Instruction Accounts

Example: Reading a Fill

Last Look