Market limit orders for Uniswap about v1-contracts

[danrobinson]

Good news: the formula I derived above was wrong, and the true formula is much simpler! (The error is that I was assuming the marginal price of adding to the trade was the same as the marginal price at the start of the next trade—it actually isn't).

Here's the actual formula:

So it's only two additional divisions by 997/1000 (so multiplications by 1000/997).

[danrobinson]

I think this is a very good idea (and one that I believe Hayden's thought about as well).

I believe this is the formula you're looking for (incorporating fees): EDIT: this formula was incorrect; see corrected one below.

It is admittedly quite gnarly. I suspect it might be simpler if fees were charged on the way out rather than the way in, although I haven't done the math yet.

[OliverNChalk]

Hmm, what are your thoughts on having the user do this maths off chain then send a trade on chain with the result and some checks on the state of the market?

[danrobinson]

You can already do that by doing the calculation and placing a normal market order that fails if it gets worse execution than expected. The usefulness of adding this function, I would think, is its different way of handling the race condition when other transactions have changed the price between when the user submitted the tx and when it is executed on chain.

To be clear, the computation is inelegant but it’s not burdensome—it could probably be done in only a few hundred gas more than your computation.

[OliverNChalk]

Well, without fees you can pass the sqrt of the invariant to the contract and save a good portion of the gas costs. That said, I don't think the same approach would work as well when fees get involved due to the ever growing invariant. That said, you could have the trade fallback on calculating the sqrt if a trade occurs before yours.

I'm interested in your thoughts on front-running this type of transaction. I imagine that frontrunners would be incentivized to buy the first half of your order before you, then you purchase the second half of your order, then they sell into the new price you created.

This would mean in the worst case, these types of orders return slightly more than 50% of their "true" volume. Does this seem accurate?

[danrobinson]

I'm interested in your thoughts on front-running this type of transaction. I imagine that frontrunners would be incentivized to buy the first half of your order before you, then you purchase the second half of your order, then they sell into the new price you created.

I believe this is correct (ignoring fees) if there is only one front-runner and Uniswap is the only way they can buy or sell the asset.

• The result changes if there are multiple front-runners. Assuming (unrealistically) that they queue up rather than competing in a gas auction, the first would trade the asset halfway, the second would push it half of the rest of the way (so to 75% of the original order), and so on in accordance with Zeno's paradox.
• The optimal strategy also changes if the front-runner is able to combine the front-running with some arbitrage. If, for example, the front-runner can buy and sell arbitrary amounts of the token on Coinbase at the starting price, then they should let your entire buy order execute, buy that same quantity on Coinbase, and sell the full amount back on Uniswap (pushing the price back to the starting price).

This would mean in the worst case, these types of orders return slightly more than 50% of their "true" volume. Does this seem accurate?

If you have fees, then yes, I think that if someone optimally front-runs you (and the caveats above don't apply), a little more than half of your order will execute (although you will receive less than half of what you would have received, because the half that does execute is executing at a worse price).

[OliverNChalk]

I implemented this and tested i with variable fees, it appears holds true for all fees < 49.99%. I will probably implement a wrapper contract for Uniswap and do some tests relating to gas cost. Will also experiment with computing the sqrt off-chain. Thanks a tonne for your help!