6 ms·

I predict this winds up as a giant gift to the arbitrage bots. Right now, the only real way to front run is to take liquidity ahead of a large order. Since swa

I predict this winds up as a giant gift to the arbitrage bots. Right now, the only real way to front run is to take liquidity ahead of a large order. Since swapping costs fees, this restricts front running to trades larger than 0.3% of the liquidity in the pair. In V3, it will now be possible for liquidity providers to “jump the queue”, by adding liquidity in a narrow range. If an arbitrage bot is monitoring the pending block, it’ll be able to predict exactly how much the price will move on the next block. It can then add liquidity at exactly that range, collect the lion shares of the LP rewards, then instantly remove the liquidity at the end of the block. The only remaining hurdle is the gas cost to add->remove liquidity (which on L2 will be virtually zero). I really hope they beta test this, because it could potentially be disastrous. Right now, front running really only costs money from large traders. Liquidity providers actually benefit from collecting fees on the extra swaps. But this has the potential to destroy the incentives to LPs, and drain all the liquidity out of the market.

Tenoke 6y ago
Is it really draining the liquidity or switching it to flash liquidity instead? That would make the estimates worse though.
xiphias2 6y ago
Can't these narrow ranges be misused by miners who can decide which transactions they want to put in the next block? I think it would make sense for them to start looking at the contracts themselves, not just the gas fees, and take part of providing liquidity. Even ordering the transactions matter a lot, as they could find arbitrage opportunities.
- arberx 6y ago
  Yes, but this is solved by PoS. Also, there's https://libsubmarine.org/ https://libsubmarine.org/
  - gruez 6y ago
    >Yes, but this is solved by PoS. How so? Now rather than colluding with miners and/or mining pools they'll collude with stakers and/or staking pools.
flixic 6y ago
Moving to Optimism L2 will remove miner advantage. Edit: of course, Optimism "Chain Organizers" can front-run, but if they will be run by Uniswap themselves, then they have no incentive to ruin their own product.
- deleted 6y ago
  [deleted]
- dcolkitt 6y ago
  This is a misunderstanding. You don't need to be a miner to front-run transactions. You simply need to run a full node, with visibility into the P2P network. It's true that miners always have "right of first refusal", in that whoever mines the block can choose to prioritize his own transactions over anyone else. But if miners don't exercise that option, then any third party can front-run the target by outbidding them. Getting rid of miners, does not in anyway remove the issue of front-running. Currently, less than 5% of front-running activity is performed by miners. As long as transactions are propagated over a P2P network, then front running is still possible. So Optimism only fixes this problem, if Uniswap LLC is hosting the entire side chain and participants are directly submitting their transactions to Uniswap's servers instead of the block chain. However if that's the case, then they almost certainly will be legally obligated to perform KYC/AML on all clients, at which point they are essentially a centralized exchange. For reference, even Binance Smart Chain, which is heavily criticized for being a centralized exchange in disguise, does not take this approach. Centralize validators are used, but the network itself is still P2P instead of centrally hosted.
  - flixic 6y ago
    There's a lot of semi-incorrect information here. With Optimism, there can be multiple L2 chains, by different "Chain Organizers". When you submit a transaction, you get a receipt from Organizer, a cryptographic promise that it will be included in future rollup. It means only Organizers can attempt to front-run, by adding a transaction before giving out your receipt. And users can always choose to use different Organizers, those that don't front-run. Since Organizers gain a small amount of fees, it doesn't make sense to be a bad, front-running Organizer.
threwaway4392 6y ago
Can't crypto kill front running entirely? Alice, wanting to transact, writes down two opposing orders, say buy 1 share of A for $10 and sell 1 share of A $10, plus a signed secret stating which order it actually is. Other players subscribe to one of the two opposite orders. Next thing (whatever that means in these blockchains, but after other players have subscribed to one of the two opposite orders), Alice reveals the secret using her private key. This reveals which order it was (buy or sell). Alice then makes a deal automatically with whoever subscribed to that order. The other opposite order is cancelled.
- Kinrany 6y ago
  Bots can probably still front run arbitrage opportunities where it's clear which transaction is the correct one, but the same can probably be done by encrypting the whole transaction and only specifying the wallets involved.
- dcolkitt 6y ago
  This has been proposed quite a few times, but the problem comes down to that it requires letting a single participant "lock down" the entire liquidity pair. For the above scheme to work, Alice's reveal would have to occur at a later block than her initial commit. Otherwise an arbitrage bot could simply peek at the reveal before the commit is mined. Also Alice's commit has to lock the chain until its reveal. Otherwise when her reveal is propagated on the P2P network, the arbitrage bot could jump the queue in front of her commit and still exploit her. You're now talking about the market freezing for 12-seconds (the block time) on every single trade. That's completely infeasible for any sort of liquid pair like ETH/USDT. Not to mention a single malicious player could DDoS the entire market. Or use it as a free option during periods of high volatility: lock the market then "reveal" in whatever direction the centralized exchanges moved in the lock-up period. Maybe you could only lock "big trades", but that in itself reveals a lot of information. You don't necessarily know the direction, but you can likely infer it with high certainty. For example if Alice doesn't own much of a token, then it's nearly certain she's buying not selling.
- qqii 6y ago
  Front running cannot happen if the mempool is encrypted. These types of blockchains are current being explored but have tradeoffs are are not widely adopted. Here are two example blockchains: SCRT (Hardware TEE, functional on Cosmos) Partisia (MPC, no working product) Other theoretical methods include homomorphic encryption and indistinguishable obfuscation.
waterside81 6y ago
What do you mean by "take liquidity ahead of a large order" and "adding liquidity in a narrow range"?
- chrisco255 6y ago
  When a user creates a swap transaction on Uniswap, it goes into the ETH transaction queue (prioritized by gas amount). If a bot notices that a user has a large swap (say swapping $1.5M USDC for 1K ETH), a bot could theoretically 'front-run' the order (by paying a higher gas fee than the original swap) and inject say, $10M of liquidity into the expected price-band of movement caused by the trade. They could then pocket a portion of the transaction fees (whatever their fraction of the 0.3% trade fee that Uniswap charges is), and then immediately pull the liquidity out of the LP to then wait for another front-running opportunity. This doesn't harm the person doing the swap, per se. It harms the Liquidity Providers that hold their capital in the pool for longer term.
pshc 6y ago
Would it help if Uniswap implemented a cooldown on adding/removing liquidity?
qqii 6y ago
It seems to me that the opportunities you are describing will be rare. If we classify liquidity providers into static and dynamic, under an efficient market it should be expected that the static liquidity providers will over time distribute their funds efficiently along the curve. The event you describe will only occur if volatility is greater than expected and the dynamic liquidity provider has a large share.
deleted 6y ago
[deleted]

Tenoke 6y ago

Is it really draining the liquidity or switching it to flash liquidity instead? That would make the estimates worse though.

xiphias2 6y ago

Can't these narrow ranges be misused by miners who can decide which transactions they want to put in the next block? I think it would make sense for them to start looking at the contracts themselves, not just the gas fees, and take part of providing liquidity. Even ordering the transactions matter a lot, as they could find arbitrage opportunities.

arberx 6y ago
Yes, but this is solved by PoS. Also, there's https://libsubmarine.org/ https://libsubmarine.org/
- gruez 6y ago
  >Yes, but this is solved by PoS. How so? Now rather than colluding with miners and/or mining pools they'll collude with stakers and/or staking pools.

flixic 6y ago

Moving to Optimism L2 will remove miner advantage. Edit: of course, Optimism "Chain Organizers" can front-run, but if they will be run by Uniswap themselves, then they have no incentive to ruin their own product.

deleted 6y ago
[deleted]
dcolkitt 6y ago
This is a misunderstanding. You don't need to be a miner to front-run transactions. You simply need to run a full node, with visibility into the P2P network. It's true that miners always have "right of first refusal", in that whoever mines the block can choose to prioritize his own transactions over anyone else. But if miners don't exercise that option, then any third party can front-run the target by outbidding them. Getting rid of miners, does not in anyway remove the issue of front-running. Currently, less than 5% of front-running activity is performed by miners. As long as transactions are propagated over a P2P network, then front running is still possible. So Optimism only fixes this problem, if Uniswap LLC is hosting the entire side chain and participants are directly submitting their transactions to Uniswap's servers instead of the block chain. However if that's the case, then they almost certainly will be legally obligated to perform KYC/AML on all clients, at which point they are essentially a centralized exchange. For reference, even Binance Smart Chain, which is heavily criticized for being a centralized exchange in disguise, does not take this approach. Centralize validators are used, but the network itself is still P2P instead of centrally hosted.
- flixic 6y ago
  There's a lot of semi-incorrect information here. With Optimism, there can be multiple L2 chains, by different "Chain Organizers". When you submit a transaction, you get a receipt from Organizer, a cryptographic promise that it will be included in future rollup. It means only Organizers can attempt to front-run, by adding a transaction before giving out your receipt. And users can always choose to use different Organizers, those that don't front-run. Since Organizers gain a small amount of fees, it doesn't make sense to be a bad, front-running Organizer.

threwaway4392 6y ago

Can't crypto kill front running entirely? Alice, wanting to transact, writes down two opposing orders, say buy 1 share of A for $10 and sell 1 share of A $10, plus a signed secret stating which order it actually is. Other players subscribe to one of the two opposite orders. Next thing (whatever that means in these blockchains, but after other players have subscribed to one of the two opposite orders), Alice reveals the secret using her private key. This reveals which order it was (buy or sell). Alice then makes a deal automatically with whoever subscribed to that order. The other opposite order is cancelled.

Kinrany 6y ago
Bots can probably still front run arbitrage opportunities where it's clear which transaction is the correct one, but the same can probably be done by encrypting the whole transaction and only specifying the wallets involved.
dcolkitt 6y ago
This has been proposed quite a few times, but the problem comes down to that it requires letting a single participant "lock down" the entire liquidity pair. For the above scheme to work, Alice's reveal would have to occur at a later block than her initial commit. Otherwise an arbitrage bot could simply peek at the reveal before the commit is mined. Also Alice's commit has to lock the chain until its reveal. Otherwise when her reveal is propagated on the P2P network, the arbitrage bot could jump the queue in front of her commit and still exploit her. You're now talking about the market freezing for 12-seconds (the block time) on every single trade. That's completely infeasible for any sort of liquid pair like ETH/USDT. Not to mention a single malicious player could DDoS the entire market. Or use it as a free option during periods of high volatility: lock the market then "reveal" in whatever direction the centralized exchanges moved in the lock-up period. Maybe you could only lock "big trades", but that in itself reveals a lot of information. You don't necessarily know the direction, but you can likely infer it with high certainty. For example if Alice doesn't own much of a token, then it's nearly certain she's buying not selling.
qqii 6y ago
Front running cannot happen if the mempool is encrypted. These types of blockchains are current being explored but have tradeoffs are are not widely adopted. Here are two example blockchains: SCRT (Hardware TEE, functional on Cosmos) Partisia (MPC, no working product) Other theoretical methods include homomorphic encryption and indistinguishable obfuscation.

waterside81 6y ago

What do you mean by "take liquidity ahead of a large order" and "adding liquidity in a narrow range"?

chrisco255 6y ago
When a user creates a swap transaction on Uniswap, it goes into the ETH transaction queue (prioritized by gas amount). If a bot notices that a user has a large swap (say swapping $1.5M USDC for 1K ETH), a bot could theoretically 'front-run' the order (by paying a higher gas fee than the original swap) and inject say, $10M of liquidity into the expected price-band of movement caused by the trade. They could then pocket a portion of the transaction fees (whatever their fraction of the 0.3% trade fee that Uniswap charges is), and then immediately pull the liquidity out of the LP to then wait for another front-running opportunity. This doesn't harm the person doing the swap, per se. It harms the Liquidity Providers that hold their capital in the pool for longer term.

pshc 6y ago

Would it help if Uniswap implemented a cooldown on adding/removing liquidity?

qqii 6y ago

It seems to me that the opportunities you are describing will be rare. If we classify liquidity providers into static and dynamic, under an efficient market it should be expected that the static liquidity providers will over time distribute their funds efficiently along the curve. The event you describe will only occur if volatility is greater than expected and the dynamic liquidity provider has a large share.

deleted 6y ago

[deleted]