Settlement Architecture
Bebop uses separate contract systems for each API:RFQ API
The RFQ API uses a single settlement contract that handles both approvals and execution:| Contract | Address | Purpose |
|---|---|---|
| BebopSettlement | 0xbbbbbBB520d69a9775E85b458C58c648259FAD5F | Verifies signatures, executes atomic swaps, manages approvals |
approvalTarget and settlementAddress in quote responses both currently point to this contract.
Aggregation API
The Aggregation API uses a two-contract architecture:| Contract | Address | Purpose |
|---|---|---|
JamSettlement (settlementAddress) | 0xbeb0b0623f66bE8cE162EbDfA2ec543A522F4ea6 | Executes the swap - verifies signatures, enforces minimums, transfers tokens |
Balance Manager (approvalTarget) | 0xC5a350853E4e36b73EB0C24aaA4b8816C9A3579a | Holds token approvals and manages taker balances during settlement |
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.
| Approval Type | Description | Compatible With |
|---|---|---|
| Standard | ERC-20 approve() on the token contract | Self-execution and gasless |
| Permit2 | Approval bundled into the signed message (no on-chain tx) | Gasless only |
EIP-712 Domains
Each API uses its own EIP-712 domain for signature verification:| API | Domain Name | Version |
|---|---|---|
| RFQ API | BebopSettlement | 2 |
| Aggregation API | JamSettlement | 2 |
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.