maker_signature in rfq.maker.respond, together with the fields in the respond frame. The venue rebuilds the same contents from the open request and that frame, checks the signature against them, and reports a quote_id that identifies the signed quote in every later message.
What the signature covers
The two maxima are consent, not estimates. The venue’s risk signer may attest any fee and lock at or below them and nothing above, and the on-chain program refuses a fill that exceeds either one, so a compromised signer cannot charge more than the maker agreed to. The open request’s
maker_funding object shows, for each taker side you may quote, the unbuffered requirement (fee and post_fill_locked) and a buffered suggestion (max_fee and max_locked_balance). The venue refuses a quote whose maxima are below the largest fee or post_fill_locked across the sides you price, recomputed at your signed bid and ask; sign at least the buffered figures for those sides, plus your own headroom for price movement between quoting and the fill. Zero is a valid value, but it is accepted only when the requirement it must cover is zero: a zero fee maximum passes while the maker rate is zero, and a zero lock maximum passes only on a package that leaves you short no leg. On a fill where you write at least one leg, the signed lock maximum is stored on your subaccount as its collateral ceiling, which a later standalone lock may not exceed; the owner can move that ceiling with the vault’s set_collateral_limit instruction. The numbers are on Fees and Limits.
The program ids and config accounts for each cluster are on Program Addresses.
Nonce and expiry
quote_nonce must be higher than every nonce the account has used before, across restarts. expires_at can be at most one hour after issued_at, and a quote must reach the venue with more than 2 seconds of life left. The full rules are under Responding on Quoting RFQs.
When a signature is refused
RFQ_INVALID_SIGNATURE: the signature does not verify over the contents the venue rebuilt. Usually the maker serialized a field differently, or signed with a key other than the wallet that owns the maker subaccount.RFQ_CANONICAL_MISMATCH: the contents decoded, but a field differs from the venue’s record of the request, such as the deployment, the legs, a subaccount that does not belong to the signing wallet, or a maximum that differs from the frame. Resending the same frame produces the same result.RFQ_SIGNED_LIMIT_BELOW_REQUIREMENT: the signature verifies, butmax_maker_feeormax_maker_locked_balanceis below the current requirement on one taker side, so the quote could never fill. Sign larger maxima; the frame is not retried unchanged.