RFQ engine design for onchain execution

Specify the requested outcome before soliciting prices

An RFQ starts with an exact request. For a spot trade this may be a token pair and input quantity. For leveraged exposure it also includes the account's contribution, the permitted debt asset, a maximum debt increase, minimum collateral received and maximum fees. An unwind request may instead require a minimum debt repayment and a minimum amount returned to the account.

Separate the user's authorization from the solver's offer. The user defines the acceptable outcome; the solver specifies what it will deliver and receive. A settlement contract must verify their intersection. A solver quote should not gain authority to withdraw unrelated collateral because it references a generally authorized account.

Requests also need scope: chain, settlement contract, account or subaccount, permitted recipient and expiry. Explicit units prevent a price or fee expressed in one decimal convention from being interpreted in another. A documented request schema makes independent solver implementations and reproducible quote comparisons possible.

Bind the signature to the complete transaction

EIP-712 defines typed structured signing and domain separation. It does not supply replay protection. An RFQ application must enforce nonce consumption, expiry and cancellation itself. Include every field that changes the economic or authorization outcome in the signed payload, and bind the domain to the intended deployment.

The settlement implementation should distinguish the quote signer from the party providing inventory. If delegated signing is supported, specify how delegation is granted, limited and revoked. Smart-contract signers require an appropriate validation path; ERC-1271 defines a contract signature-validation interface. Validation can depend on current contract state, so an earlier offchain check is not sufficient evidence at settlement.

Decide whether quotes permit partial fills. A single-use nonce is simple for all-or-nothing execution. Partial fills require cumulative accounting against signed quantity limits and exact rounding rules. Cancellation and filling must resolve consistently when both transactions are pending.

Measure an executable quote, not just a displayed price

A quote is useful only if the solver can settle it within the promised window. Compare all-in outcomes after fees, gas assumptions, asset transfers and financing costs. A nominally better price can be worse if it relies on a fragile route or regularly expires before inclusion.

A proposed solver policy can track successful settlement, rejection reasons, fill latency and inventory availability without pretending those observations guarantee future performance. Make competition rules clear: which solvers receive a request, how long they have to respond, and whether the request reveals information to other participants. The response window is a market-design tradeoff between competition and information leakage.

Solver permissions should be narrow. An allowlist identifies who may submit a quote; it does not validate the quote's economics or provide inventory. Enforcement belongs in the settlement path. Plan for all solvers to decline a request, and return an explicit no-quote outcome instead of silently increasing the user's bounds.

Settle target leverage as a bounded state transition

The partner-instance architecture proposes RFQ execution for target exposure. A solver can deliver the requested asset while the transaction combines the user's contribution, credit draw and solver payment. This can reduce the number of separate user actions, but it requires rigorous end-state accounting.

1. Validate both authorizations, deadlines, permissions and cancellation state.
2. Check available credit and asset policy against the intended final account.
3. Move the specified contribution and solver inventory through approved paths.
4. Record collateral and debt from actual transferred amounts.
5. Pay the solver and apply the signed fee limits.
6. Verify final account health and consume the authorized fill.

The exact order depends on callback and funding requirements. The invariant is that external calls cannot expose an unguarded intermediate state, and failure of a required leg reverts the atomic operation. An offchain promise to deliver later is a different credit arrangement and must not be described as atomic settlement.

Use RFQ liquidation with a timed fallback

An RFQ can solicit a bid for collateral or a transfer of an eligible distressed position. The potential benefit is a price for the complete operation, including debt repayment and execution cost. The risk is waiting for competition while collateral value deteriorates.

Define a bounded solicitation period and the conditions for accepting a bid. The liquidation engine should compare the actual improvement to account solvency, the debt repaid and the residual exposure. A bid that leaves an expensive dust position may be worse than a slightly lower headline price. Position transfers also require the receiving account to meet its own permissions and margin rules.

If no valid bid arrives, the system needs a documented fallback such as an auction, permitted market execution or a funded backstop. Fallback activation must not depend on the unresponsive solver. RFQ is an execution mechanism within a liquidation policy, not a substitute for that policy.

Make failed execution diagnosable

A rejected fill can result from stale authorization, insufficient solver inventory, an expired quote, changed account health, a blocked token transfer or a route reverting. Distinguish these conditions in application errors and monitoring. Repeated user retries should not create new economic authority or consume a successful fill twice.

Keep audit records sufficient to reconstruct an outcome: request identifier, quote digest, configuration version, actual transfers and rejection category. Avoid embedding private commercial instructions in public events when an opaque reference will suffice.

Test the complete authorization boundary

Test altered recipients, assets, quantities, fees, chains and verifying contracts against the same signature. Try expired and cancelled quotes, repeated fills, contract signers whose authorization changes, and partial fills at rounding boundaries. Every signed field should have a test demonstrating that changing it changes or invalidates the authorized result.

Execution tests should include callback-capable assets, failed transfers and solvers that return less than promised. Check actual balance movements rather than trusting adapter return values. Where the design supports fee-on-transfer or rebasing tokens, define the expected measurement explicitly; otherwise reject them under the asset policy.

Finally, run a market simulation with slow, absent and competing solvers. Measure fill probability and time under the intended request sizes, then test the liquidation fallback under the same conditions. These are deployment-specific validation tasks. The architecture described here does not claim that every proposed RFQ module is live or that any solver will always provide liquidity.

Common engineering questions