- On-chain toxic-flow protection:
- toxic-flow checker that makes predicted-toxic swaps unprofitable, so they don’t execute.
- oracle slippage protection that refunds you when the market moves against you between signing and execution, while letting you keep positive slippage.
- Maker pre- and post-hooks: Arbitrary maker logic the router runs in the same transaction as the swap, letting you:
- Mint a liquid-staking, wrapped, or RWA token as a pre-hook so the settlement contract can pull it.
- Borrow or redeem from a lending protocol (e.g., Aave, Morpho) as a pre-hook, then re-supply leftovers as a post-hook.
- Wrap or convert the token you receive as a post-hook.
- Any other on-chain logic you can implement in a contract.
What’s different?
We are using the same settlement contract underneath and do not introduce any breaking changes to the overall flow, so a request coming from RFQA looks like a normaltaker_quote request, except:
- taker identity:
sourceisrfqa,taker_addressis the BebopRouter contract0xBeb0009ACa35087ce7cCF11637E24dd1Aad3bf2A,receiveris also the router, since the router is the immediate recipient of your maker tokens.
- swap flow: the contract pulls maker tokens, applies fees and slippage, and forwards the remainder to the user; the order signing mechanism remains unchanged.
- new accounting fields in Trade history API and the Trades WebSocket :
onchain_maker_amount: what actually left your wallet, net of the refund.refunded_maker_amount: your share of the recovered slippage.
Example
This trade swaps 18 USDC to WETH, with the maker paying out WETH.- At signing, the oracle reference (blended with the Binance price) was
1777.258USDC/WETH. - By execution, about two blocks (~24s) later, the oracle mid had risen to
1779.710USDC/WETH,+0.1379%above the reference price. - The router charged 13.79 bps of slippage and refunded the maker’s share.