Airswap RFQ lets clients review maker-signed orders before on-chain settlement

Airswap RFQ lets a client request a maker-signed token order, inspect its terms, and submit it for atomic on-chain settlement. A signed order is an offer with an expiry. Completion requires successful execution by the matching settlement contract, with valid permissions, sufficient balances, and the correct signature.

Establish the network and maker configuration

A request-for-quote session needs a maker that supports the intended protocol, network, settlement contract, and tokens. These details establish the exchange that the maker can quote. They do not establish that a particular order will execute. A token symbol alone leaves the token contract unidentified. The discovery method getProtocols exposes supported protocol configurations, including the chain ID, swap contract address, and maker wallet. Keep these consistent with the request and wallet network. The client requests an order for that configuration through the maker's JSON-RPC server over HTTPS or WebSocket. Reviewing the reply does not itself transfer tokens or require submitting a swap.

Translate signer and sender into the proposed exchange

In RFQ, the maker signs the order, and the client sends it for settlement. Consequently, signerToken and signerAmount describe what the maker supplies. senderToken and senderAmount describe what the client supplies. The method names follow these protocol roles, which can feel reversed when reading from a buying interface.

The order expresses token quantities in atomic units, using each token's decimal precision. Compare displayed quantities only after the application converts those units correctly. A wallet-specific signature also commits to the sender wallet. Token compatibility and the settlement contract's order format remain prerequisites; a familiar ticker cannot establish either one.

Should the request fix the amount sold or received?

Fix the selling amount when spending is the constraint; fix the receiving amount when the intended output is the constraint. Both RFQ request directions return maker-signed orders. The difference is which amount the request supplies and which amount the maker calculates.

Fix the amount to sell

getSignerSideOrderERC20 takes senderAmount and returns the corresponding signerAmount . The client specifies the amount it will provide and asks the maker to price the other side. Compare returned receiving amounts only across requests that hold the selling amount and configuration constant.

Fix the amount to receive

getSenderSideOrderERC20 takes signerAmount and returns senderAmount . The client specifies what it wants from the maker, which quotes the required payment. Different makers may quote different payment amounts.

Distinguish soft pricing from a signed order

A pricing response can describe indicative pricing through levels or a formula, while an RFQ order contains signed exchange terms.

The signed order identifies the token amounts, expiry, and nonce, together with the signature information. Its signing domain binds the authorization to the relevant chain and verifying contract. Copying the displayed rate into different order fields does not preserve the maker's authorization.

Receiving that order leaves settlement unexecuted. The client can decline the terms before submitting a transaction. Existing approvals, if any, remain separate permissions.

Changing the pair, amount, sender restriction, or settlement configuration requires an order that authorizes the changed terms. A new request may return different pricing. Retaining the original display while changing the underlying request would misrepresent which exchange the signature actually covers.

Prepare allowances without confusing them with signatures

Token allowances permit the settlement contract to transfer tokens, while the maker's signature authorizes the order terms. Both parties need sufficient balances and applicable allowances for the selected execution method. An approval for another contract does not give this settlement contract permission to spend.

The client's readiness concerns its payment token and, when it submits an Ethereum transaction, ETH for gas. Maker readiness concerns the tokens it must deliver and any additional protocol fee. An authorized signatory may sign for the maker wallet; that authorization does not replace the wallet's token allowance. None of these checks reserve balances against subsequent spending.

The swapLight path is intended for known tokens. It still validates the signature, expiry, and nonce. Those order checks do not establish that an arbitrary token implements the expected transfer behavior. Token behavior therefore matters before choosing the execution method.

Keep settlement fees separate from gas

Method-specific protocol fees

SwapERC20 signing-domain version 4.3 distinguishes protocolFee for swap from protocolFeeLight for swapLight . Each method checks a signature that includes its applicable fee setting. Reusing an order across methods requires matching signing terms; the method names alone do not establish compatibility.

The protocol fee uses the maker's signerAmount as its base and charges the maker in signerToken . Multiply that amount by the applicable basis-point setting and divide by 10,000, with integer truncation. For swap , the sender's balance of a configured staking token determines any bonus from this fee. A positive bonus goes to the transaction sender, with the remainder going to the fee wallet. Without a positive bonus, the full fee goes to the fee wallet. This distribution does not change the maker's fee base.

The submitting wallet pays network gas

An Ethereum transaction consumes gas even when its execution reverts. Gas is separate from the token-denominated protocol fee. Approval transactions can also consume gas. An exact exchange amount therefore describes the token trade without establishing the transaction's total cost.

Expiry follows the execution timestamp

An order's expiry is an absolute timestamp, expressed in seconds since 1 January 1970. It describes the settlement boundary, not a universal quote lifetime. Request latency and transaction inclusion consume part of the interval that remains before that boundary.

SwapERC20 signing-domain version 4.3 rejects settlement when the block timestamp is equal to or greater than the order's expiry. Submitting a transaction beforehand does not establish that execution will occur beforehand. Signature validity also depends on the applicable fee setting and authorization, while nonce status can change independently of expiry.

Read failures at the layer that produced them

A maker returns a request error

A JSON-RPC error means the maker did not return the requested order. It differs from a settlement revert. The error message can identify a pair, amount, or parameter issue, so interpret it before changing the request. A server response does not establish an on-chain failure.

The contract rejects authorization

A signature failure can reflect mismatched order fields, signing-domain details, or the method's fee setting. A consumed or cancelled nonce prevents reuse within that deployment's signatory state on the selected network. Altering a signature field cannot repair a maker authorization that covers different terms.

A token transfer cannot complete

A balance or allowance shortfall can arise after an order arrives. Token transfer restrictions can also block execution. These failures concern settlement readiness. Repeating the same submission does not replenish balances, grant allowances, or change the token's transfer rules.

What confirms that the RFQ swap completed?

A successful settlement transaction containing the matching swap event confirms execution, while a quote response or pending transaction does not. Match the receipt to the intended network, settlement contract, maker, and nonce. Inspect the token transfers for the actual movement of funds.

View image file

Atomic settlement makes the exchange succeed together or revert together. Reversion rolls back the transaction's token transfers, although Ethereum still charges execution gas. A transaction identifier locates a transaction; its receipt establishes whether that transaction succeeded.

LastLook uses the opposite signing roles

LastLook gives the client the signing role and the maker the submission role. The maker streams prices and decides whether to settle the client's signed order. Its effectively gasless client settlement applies to that arrangement; it does not describe the client-submitted RFQ sequence.

A WebSocket connection alone does not identify the trading protocol because a server can support both RFQ and LastLook. Read the advertised protocol and signing roles together. That distinction determines whether the next authorization comes from the maker or the client, and which party submits the settlement transaction.

Airswap RFQ questions, answered