TxManager should be able to confirm a transaction every single block

[haydenshively]

The idea behind the price wave / prices posted motif is that when somebody becomes liquidatable (or nearly liquidatable) based on Coinbase prices, we should prepare for them to become liquidatable on-chain. They get added to a list, and the TxManager attempts to maintain a pending transaction that, if confirmed, would try to liquidate the users in the list.

As soon as Compound (the company) updates prices, the code updates[1] the pending transaction to use the same gas price as Compound's transaction. In theory, this would ensure that the transactions happen right after one another, giving us a good chance of "winning" the liquidation.

In practice this doesn't work too well. The only way to ensure that a transaction gets mined in the block it was sent on is to use an incredibly high gas price -- and even then it can sometimes be delayed by 1 block. This is because miners give some priority to transactions that have been waiting longer. This explains why I try to have the TxManager maintain a pending transaction. The issue is that it only maintains 1 at a time. If a pending transaction happens to go through on the block before a price update transaction, the TxManager will replace it with a new one, but that new one will be brand new, and thus it has a very low chance of actually going through soon enough to win the liquidation.

To fix this, we need to have a rolling queue of pending transactions. For example, assume a transaction takes N blocks to be accepted. Instead of sending transactions at blockNumber=0, blockNumber=N, blockNumber=2N... we should send transactions at blockNumber=0, blockNumber=1, blockNumber=2 so that they get confirmed at N, N+1, N+2. This requires some very careful management and heuristics, especially since it gets expensive fast[2].

[1] Note that this update can only happen if the pending transaction has a lower gas price than Compound's transaction (gas prices can only be raised after tx submission, never lowered) [2] After implementing this, we may find that it's too expensive to do it for all accounts. Nantucket may need to become more targeted: focus on just 1 or 2 accounts that get liquidated often, and ignore the rest. After making some money, we can then reinvest it and broaden Nantucket's scope again

[haydenshively]

Now that liquidators will be front-running instead of side-running, we don't need to do this