Settlement Architecture
Bebop uses separate contract systems for each API:RFQ API
The RFQ API uses either the router or the settlement contract depending on the type of the trade:
The
approvalTarget and settlementAddress in quote responses would point to either of those.
Aggregation API
The Aggregation API uses a two-contract architecture:These are two distinct contracts. Takers must approve the balance manager, not the settlement contract. The quote response handles this for you via the
approvalTarget field - see Token Approvals for the full flow.Chain-Specific Addresses
The addresses above apply to all supported EVM chains except zkSync Era (chain ID 324), which uses different contract addresses. Always use the values from the quote response rather than hardcoding. See Supported Chains for the full list of networks.How Settlement Works
When you request a quote, Bebop returns an EIP-712 typed message representing the exact trade terms - tokens, amounts, and price minimums. You sign this message to authorize the trade. The settlement contract then verifies your signature on-chain, checks that the execution price meets the agreed minimums, and atomically transfers tokens between you and the maker(s) in a single transaction. If any condition fails, the entire transaction reverts - no partial state changes, no stuck funds, the contracts enforce the same guarantees and Bebop never takes custody of your tokens.Approvals
Token approvals target theapprovalTarget address from the quote response. The general pattern is the same across both APIs - see Token Approvals for the full check-and-approve flow.
EIP-712 Domains
Each API uses its own EIP-712 domain for signature verification:
The
verifyingContract is always the settlementAddress from the quote response. The chainId is the chain the trade executes on.
See the RFQ gasless execution guide and the Aggregation API quickstart for the full EIP-712 type schemas.