- We have decided to now support calling our executors normally (without using delegatecalls) since they now support specifying token transfers.
- This was disabled for UniswapV3 in the past also because of data decoding issues. This seems to be the solution, though.
- Renamed ExecutorTransferMethods to TokenTransfer to avoid leaking information about how the transfer happens into the executor. The executor shouldn't care if there are multiple methods or one single method that takes care of everything.
- Also renamed TransferMethod to TransferType to match the rust encoding
- Properly decode, update tests with proper decoding
- Added test case for each transfer method
- Also fully tested permit2 transferFrom and it works perfectly.
TODO:
- Fix integration tests once encoding is implemented.
- Also do some renamings and comment improvements:
transfer method -> type
- Remove integration tests since we no longer support direct calls to USV3 executor, even for testing.
- Renamed ExecutorTransferMethods to TokenTransfer to avoid leaking information about how the transfer happens into the executor. The executor shouldn't care if there are multiple methods or one single method that takes care of everything.
- Also renamed TransferMethod to TransferType to match the rust encoding
- Properly decode, update tests with proper decoding
- Added test case for each transfer method
- Also fully tested permit2 transferFrom and it works perfectly.
NOTE:
UniswapV3 doesn't support NONE as a transfer method.
TODO:
- Fix integration tests once encoding is implemented.
- Properly decode, update tests with proper decoding
- Added test case for each transfer method
- Also fully tested permit2 transferFrom and it works perfectly.
TODO:
- Fix integration tests once encoding is implemented.
With this, we don't need the univ3 specific method in the router contract. This should be flexible enough for most protocols that integrate
TODO: is this safe enough??
--- don't change below this line ---
ENG-4411 Took 1 hour 52 minutes
Took 4 minutes
Took 5 minutes
- Needed to take pool code init hash as input param for executors
- Added tests for ethereum. Will test base on-chain.
- Important note: Pancakeswap uses their deployer instead of their factory (this is a different address) for target verification.
- This factory is not the same for Ethereum and Base, so Base txs were failing when verifying pool addresses.
- I've double checked that we don't have this problem for Balancer V2 - the vault address in the same on Base and on Ethereum Mainnet.
The selector and executor are decoded inside this function now.
For Uniswap V3 I had to manually slice the msg.data from uniswapV3SwapCallback to get the data that matters for the callback
Took 3 hours 12 minutes
- Note: I think we can get the fee straight from the pool... why did we always encode this and send it from the solver? Is this bound to change sometimes?
