Nice!. The simple arbitrage bot was my framework which I started :) But I changed so many things that I just kept the BundleExecutor and FlashBotsUniswapQuery contracts hehe
I just was discussing this possibility with my teammate to get rid of the burden of upgrading our arbitrage contract for each new dex callback function we want to incorporate... but this seems to solve that precise challenge.
I am intrigued and looking forward to the new flash borrow to swap using this method to see if we can also apply to the callback wrapper functions.
It's a game changer, I'm very excited about this one. I've also been retooling the callback stuff and I think I can eliminate the use of storage variables 🤞 at least for the uniswapv2call style contracts, they pass the original calldata back so if we send a predictable payload, we can process it without relying on reading from storage.
I had the idea of encoding those 5 storage params into a bytes array and pass them into the swap function "special" param instead of passing the typical arbitrary string, because the callback also receives that calldata param as 3rd argument, but I didn't prioritise that because I still need to learn about how to encode-decode multiple params into a bytes field and I also was not sure about how much gas savings would be involved.
My guess is that doing the decoding operations is cheaper than writing/reading/blanking the storage slots. There are many more knowledgeable on the topic and I always see them saying to avoid manipulating storage whenever possible.
Nice!. The simple arbitrage bot was my framework which I started :) But I changed so many things that I just kept the BundleExecutor and FlashBotsUniswapQuery contracts hehe
If I knew Javascript I would have built off that same base. But naturally I'm retarded and did it the hard way 😬
Thank you! Amazing as always!
I just was discussing this possibility with my teammate to get rid of the burden of upgrading our arbitrage contract for each new dex callback function we want to incorporate... but this seems to solve that precise challenge.
I am intrigued and looking forward to the new flash borrow to swap using this method to see if we can also apply to the callback wrapper functions.
It's a game changer, I'm very excited about this one. I've also been retooling the callback stuff and I think I can eliminate the use of storage variables 🤞 at least for the uniswapv2call style contracts, they pass the original calldata back so if we send a predictable payload, we can process it without relying on reading from storage.
The ride never ends!
I had the idea of encoding those 5 storage params into a bytes array and pass them into the swap function "special" param instead of passing the typical arbitrary string, because the callback also receives that calldata param as 3rd argument, but I didn't prioritise that because I still need to learn about how to encode-decode multiple params into a bytes field and I also was not sure about how much gas savings would be involved.
My guess is that doing the decoding operations is cheaper than writing/reading/blanking the storage slots. There are many more knowledgeable on the topic and I always see them saying to avoid manipulating storage whenever possible.