Smart contract to batch burnForFees with SushiswapV3 #5
Description
We can reduce price risk by performing both steps in one atomic transaction.
If we do this after Filecoin gets EIP-7702 support, this code can be in the EOA. Otherwise it can be done as a code account that holds no assets.
This does not guarantee profit because the transaction can still revert, and the probability of that is difficult to model.
Basic Interface
swapFees(address token) external payable
This function would forward the payable amount (msg.value) to burnForFees after querying accounts for the token amount. It would then swap that token through SushiswapV3 for WFIL and unwrap the WFIL to the immutable owner, reverting if this was less than or equal to the payable amount.
It is important to forward the profit to a hardcoded owner instead of msg.sender because that is the cheapest way to make parasitic generalized frontrunning slightly more expensive; they would have to also deploy their own contract. The way such an attack works is that they do not perform any computation themselves but instead watch pending transactions for profitable opportunities, and then substitute themselves but with a slightly higher priority fee. If they also have to deploy code, this can make such a substitution unprofitable. However, there is no general solution to this problem (besides keeping your transaction hidden until you can propose it in your own block).
An even simpler design might hardcode the token address and even the pool.
Optionally, the actual FIL price of burnForFees could be computed during the transaction with auctionInfo. Can import the Dutch library from FilOzone/filecoin-pay/Dutch.sol to perform the calculation.
A SushiswapV3 pool can be used directly without a router if you implement uniswapV3SwapCallback. This callback would not need to be secured if the account keeps no assets, but would need to be secured if it was a 7702 EOA.
A fancier way to do this would be to flash swap, using the WFIL from the swap to get the FIL for the burnForFees. This would allow larger burns with less funding, but I don't think that will be worth the marginal cost compared to supplying the account with slightly more funds.