This is a simpler option than #5 that does not require a smart contract.

The current bot does not swap USDFC back into FIL. Consequently the price might drift considerably, affecting profitability, and the bot will require operational overhead to cycle back into FIL. By cycling back to FIL, it will refuel itself automatically.

There are two approaches we could consider. We can submit a subsequent transaction at the same time as burnForFees with nonce+1, or we can wait to see if burnForFees will succeed. The downside of waiting is that the sale can be frontrun intentionally or unintentionally. By submitting both transactions simultaneously, it is more likely that the price quoted to determine profitability might still be valid. On the other hand, by waiting for successful confirmation, we can use eth_estimateGas for the swap, though that might not be strictly necessary if the Sushiswap routing API can provide a gas estimate.

If the sale fails or if there is dust leftover, it is probably best to hold onto it until the next burnForFees, to ensure it can be batched.

You would want to sell both the USDFC in the account and the USDFC acquired from burnForFees. I believe the Sushi API should supply routing information and their SDK might help assemble the transaction.

An estimated gas cost of this swap should also be part of the profitability calculation.