feat: add SwapRouter02ExecutorWithPermit to support 2612 style permit tokens #187
Conversation
| ISwapRouter02 public immutable swapRouter02; | ||
| address public immutable whitelistedCaller; | ||
| IReactor public immutable reactor; | ||
| WETH public immutable weth; |
There was a problem hiding this comment.
making these public so swapRouter02ExecutorWithPermit can inherit
| function executeBatchWithPermit( | ||
| SignedOrder[] calldata orders, | ||
| bytes calldata callbackData, | ||
| bytes[] calldata permitData |
There was a problem hiding this comment.
doing array of permitData for executeBatch and single for execute single doesn't seem like a perfect matchup - like in the batch of orders they might not all need permits, so just cuz its a list of orders doesnt mean its necessarily a list of permits.. likewise maybe for executesingle we might want to send multiple permits for some reason?
i think we should just decouple it and have a multicall and permit function so the permits can be layered on granularly
There was a problem hiding this comment.
maybe we should make a base contract that other executors can inherit from that has this shared logic? wdyt
There was a problem hiding this comment.
ooo good point about the multiple orders not all needing permits, it would be weird to have the inputs be different lengths...
how would you layer permits on granularly? are you thinking of bundling the orders together with any applicable permits like [ (order, permits[]), (order, permits[]), ...] ?
|
Closing this in favor of #202 |
Add SwapRouter02ExecutorWithPermit, an extension of the current sample executor which introduces two new entrypoints for filing orders:
executeWithPermitandexecuteBatchWithPermit.This allows fillers to fill orders sent by users who have not yet made the necessary approvals to Permit2 for the input tokens in their order. The executor will simply confirm the 2612 permit before calling the respective execute function on the reactor.