What you’ll build: A complete trade flow using solver auction liquidity.Time required: 10-15 minutesPrerequisites: Basic understanding of EVM wallets and token approvals.
How It Differs from the RFQ API
The RFQ API provides firm market maker quotes with guaranteed execution and guaranteed fill. The Aggregation API runs a solver auction - multiple solvers compete to fill your order across all available on-chain liquidity. This gives you broader token coverage (including long-tail assets) at the cost of requiring a slippage tolerance.| RFQ API | Aggregation API | |
|---|---|---|
| Liquidity source | Direct market maker quotes | Solver auction across DEXs and aggregators |
| Token coverage | Major pairs | Broad, including long-tail |
| Slippage | None - guaranteed execution and fill | Configurable tolerance |
| Execution | Self-exec or gasless | Self-exec or gasless |
| Base URL | /pmm/{network}/v3/ | /jam/{network}/v2/ |
1. Request a Quote
| Parameter | Description | Example |
|---|---|---|
sell_tokens | Token(s) you’re selling (contract address) | 0xC02a... (WETH) |
buy_tokens | Token(s) you’re buying | 0xA0b8... (USDC) |
sell_amounts OR buy_amounts | Amount in base units. Use one, not both. | 1000000000000000000 (1 WETH) |
taker_address | Wallet executing the trade | 0xYourWalletAddress |
| Parameter | Description | Default |
|---|---|---|
gasless | Set to false for self-execution | true |
approval_type | Standard or Permit2 (gasless only) | Standard |
slippage | Max acceptable slippage (0-50%, up to 2 decimal places) | Determined by solver |
receiver_address | Address to receive bought tokens (if different from taker) | taker_address |
Choosing sell_amounts vs buy_amounts
Choosing sell_amounts vs buy_amounts
- Use
sell_amountswhen you know exactly how much you want to sell (e.g., “Sell 1 WETH”) - Use
buy_amountswhen you know exactly how much you want to receive (e.g., “Buy 5000 USDC”)
Understanding the Response
The response structure depends on whether you requested gasless or self-execution mode. Gasless response - includestoSign (the EIP-712 message you must sign). No tx object since Bebop handles on-chain submission:
tx object (settlement calldata ready to broadcast) and toSign:
| Field | Description |
|---|---|
quoteId | Unique identifier - you’ll need this for order submission and status polling |
solver | Name of the solver that won the auction |
expiry | Unix timestamp - the order is invalid after this time |
buyTokens.minimumAmount | Worst-case amount after slippage. The amount is the expected fill. |
gasFee | Estimated gas cost in native token and USD |
approvalTarget | The contract you must approve. Do not hardcode this address or confuse it with settlementAddress. Approving the wrong contract may lead to loss of funds. |
toSign | EIP-712 message fields. Present in both modes; used for gasless signing. |
tx | Ready-to-broadcast transaction (self-execution only) |
2. Approve Tokens
Before the settlement contract can move your sell tokens, you need an ERC-20 approval on theapprovalTarget address from the quote response. See the Token Approvals guide for the full check-and-approve flow.
3. Sign & Submit
The Aggregation API supports two execution modes. Choose the one that fits your integration:- Self-Execution
- Gasless
With self-execution (With self-execution, there’s no separate EIP-712 signing step and no
gasless=false), the quote response includes a tx object containing the complete settlement calldata. You broadcast the transaction yourself./order POST. The tx object contains everything needed for settlement.Permit2 Signing Variant
When usingapproval_type=Permit2 with gasless execution, the signing structure changes. Instead of signing JamOrder directly, you sign a PermitBatchWitnessTransferFrom that wraps the order:
toSign will contain permitted, spender, nonce, deadline, and witness (which is the JamOrder data) instead of the flat JamOrder fields.
4. Poll for Settlement
Both execution modes support status polling via/order-status.
| Status | Meaning |
|---|---|
Pending | Bebop received the order and is preparing to submit |
Success | Solver accepted - transaction is being broadcast |
Settled | Transaction confirmed on-chain - tokens transferred |
Confirmed | Final success state - settlement fully confirmed |
Failed | Order failed (solver rejection, on-chain failure, expiry, or validation error) |
| Field | Description |
|---|---|
txHash | Transaction hash (available once broadcast) |
amounts | Actual token amounts received after settlement |
surplus | Price improvement the solver achieved beyond the quoted minimum amount |
Full Example
- Self-Execution
- Gasless
Next Steps
Token Approvals
Set up ERC-20 approvals before trading.
RFQ API Quickstart
Compare with the RFQ API for firm market maker pricing.