taker_quote response must include a signature field: the maker signs the filled quote inline. See Quotes › Responding for the response shape. This page covers the EIP-712 order types, the sign schemes Bebop accepts, and a full Python signing example.
RFQA order signing is unchanged from what’s described here. If you attach maker hooks, each hook needs a separate EIP-712 signature over the
BebopHook struct, using the BebopRouter domain rather than BebopSettlement.Order types
UseSingleOrder for single-pair, single-maker swaps. Use MultiOrder whenever Bebop’s router involves multiple makers or multiple legs on your side: middle-token routing, and 12M / M21 multi-token trades. The order_signing_type property on the incoming quote indicates which type to use.
SingleOrder: single pair, single makerMultiOrder: multi-maker, and/or multiple legs on your side (middle-token or12M/M21)
Middle-token routing
A quote withorder_type: 121 can arrive with onchain_order_type: MultiOrder when the router uses middle-token routing (passing through an intermediate token to get a better price). This is the most common reason a signature that worked in testing fails in production:
- Multi-maker middle-token routing can’t be reproduced with only your own maker in the loop.
/maker-statusincludes a hardcoded middle-token test case. When the signature test fails, the response includes the expectedsignable_messageso you can compare against yours byte-for-byte.- Bebop runs random signature spot checks on production quotes.
/maker-status as the canonical reference.
Sign schemes
Return asign_scheme alongside the signature bytes in your taker_quote response:
EIP712: EOA signing. Use this for a standard externally-owned maker address.EIP1271: contract-wallet signing. Bebop verifies the signature on-chain by callingisValidSignatureon the maker contract.