Skip to main content
Bebop has introduced the BebopRouter 0xBeb0009ACa35087ce7cCF11637E24dd1Aad3bf2A contract, which now settles some RFQ trades instead of going straight to BebopSettlement. The router is used for highly liquid tokens; BebopSettlement still handles multi-token swaps and less liquid tokens.

​
Do you need to migrate?

If your integration already reads these fields from the quote response, no changes are required. Confirm both:
  • Approvals. You approve the approvalTarget from the quote response, not a hardcoded address. See Token approvals.
  • Broadcast. You send the returned tx object as-is; tx.to already targets the correct contract.
If you hardcoded the BebopSettlement address anywhere (for approvals or as the transaction target), switch to reading approvalTarget and tx from the quote response.

​
Reading the calldata

You don’t build the router calldata yourself. Bebop returns it ready to broadcast in tx.data. If you want to decode it (for verification or logging), it’s a call to the router’s swap function: 
function swap(
    int256 exactAmount,
    BebopRouterOrder calldata order,
    bytes calldata extraInfo,
    bytes calldata routerSignature,
    bytes calldata bebopPmmCalldata,
    Hook[] calldata hooks
)
ParameterDescription
exactAmountFill mode. > 0: exactIn, you send exactly this amount of fromToken. < 0: exactOut, you want exactly |exactAmount| of toToken after fees. == 0: use whatever fromToken balance the router holds.
orderThe signed order struct. fromAmount / toAmount define the quote ratio used for scaling.
routerSignatureThe router signer’s EIP-712 signature over the order.
bebopPmmCalldataThe raw BebopSettlement.swapSingle / swapAggregate calldata the router wraps.
For a concrete reference, see this example transaction.