Skip to main content
In gasless mode, the user signs a quote and Bebop submits the settlement transaction on-chain. The user never pays gas - making it ideal for wallets and super-apps where UX simplicity matters. The trade-off: market makers retain last look, meaning they can reject a quote before settlement. In return, pricing is tighter than self-execution.
When to use gasless: You’re building a consumer-facing product where users shouldn’t think about gas. For solvers and aggregators executing trades programmatically, see the self-execution quickstart.

How It Differs from Self-Execution

1. Request a Gasless Quote

Add gasless=true and the relevant approval parameters to your quote request:

Approval Parameters

Which approval type? Standard (the default) requires the user to have already approved the settlement contract. Permit2 removes the need for a separate approval transaction but adds a second signature step. For bundled approvals without a separate transaction, see Using Permit2 Approvals below.

2. Sign the Quote

Sign the EIP-712 typed data from the quote response - the same signing flow as self-execution:
The RFQ_EIP712_TYPES dictionary contains the EIP712Domain and all three order type definitions. The API selects the order type automatically based on the trade structure - use the onchainOrderType from the quote response as your primaryType.
SingleOrder - simple one-to-one swaps (e.g. WETH → USDC):
MultiOrder - single maker fills a multi-token trade:
AggregateOrder - multiple makers fill a multi-token trade:

3. Submit the Order

Unlike self-execution, gasless orders are submitted to Bebop’s /v3/order endpoint. Bebop handles the on-chain settlement:
At this point Bebop has your signed order and will submit the settlement transaction on-chain.

4. Monitor Settlement

Poll the order status endpoint to track progress:

Order Statuses

The order-status response also includes txHash (when available) and amounts (received token amounts after settlement).
Last look rejections are expected in gasless mode. When a maker rejects, the status will be Failed. Your integration should handle this gracefully - request a new quote and retry. The user’s tokens are never at risk during a rejection.

Full Example

Dependencies: pip install httpx eth_account (or uv add httpx eth_account)

Using Permit2 Approvals

With approval_type=Standard, the user must have approved the settlement contract before trading (a one-time on-chain transaction per token). Permit2 removes this requirement by using an off-chain signature for token approvals instead.
This differs from the Aggregation API’s Permit2 flow. The Aggregation API wraps the order inside PermitBatchWitnessTransferFrom - you sign a single combined message. The RFQ API keeps order signing unchanged and adds a separate PermitBatch signature for token approvals.

How it works

  1. One-time setup: Approve the Permit2 contract (0x000000000022D473030F116dDEE9F6B43aC78BA3) for your sell tokens. This is a standard ERC-20 approve() - the same kind of transaction you’d do for the settlement contract with Standard approvals, but targeting the Permit2 contract instead.
  2. Request a quote with approval_type=Permit2:
  1. Sign the order the same way as Standard - BebopSettlement domain, same order types. The toSign data is identical.
  2. Check requiredSignatures in the quote response. If it contains token addresses, generate a PermitBatch signature:
  1. POST to /order with the additional permit2 field:
On subsequent trades for the same token, requiredSignatures will be empty once the Permit2 allowance is active. In that case, no permit2 field is needed in the POST body - it works the same as Standard.

permit2 Field Reference