For Uniswap sandwiches, the UI is conflating expected price slippage with extra slippage
Can you clarify what you mean by “extra slippage”? Often when I’ve set my slippage to a low value, I’ve had my transaction fail, at huge expense in gas costs.
How does the dapp or its front-end minimize the risk of transaction failure through price slippage, while preventing sandwich attacks?
Intuitively your claim seems wrong: obviously if dapps could eliminate MEV, they would have already. They don’t, because they can’t.
I didn’t say they could eliminate MEV. All harmful extractions can be prevented though.
After I explained to a Uniswap engineer that this frontrunning was the fault of their default slippage being so high, they introduced an auto slippage feature that seems more intelligent. I think it does something similar to what I describe later in this reply.
The configuration in the Uniswap UI is for extra slippage: how much less than the exact output calculated that you are willing to accept without reverting.
An easy heuristic is to double your swap fees. If the dex charges 0.05%, you can specify 0.1% extra slippage and it cannot be profitable to sandwich you.
For smaller swaps you can calculate how much your transaction fee is worth as a proportion of your output and allow for that.
The configuration in the Uniswap UI is for extra slippage: how much less than the exact output calculated that you are willing to accept without reverting.
How is this distinguished from “expected price slippage”? Earlier you identified two different types of slippage: For Uniswap sandwiches, the UI is conflating expected price slippage with extra slippage
Also, your analysis does not address swap failures due to slippage, which are more likely to occur when the slippage tolerance variable is set to a lower value.
An easy heuristic is to double your swap fees. If the dex charges 0.05%, you can specify 0.1% extra slippage and it cannot be profitable to sandwich you.
How is that supposed to help the trader? The trader has just changed which party is extracting fees, from the MEV miner, to the dApp.
Clearly MEV is a very serious problem for market efficiency on Ethereum, and if an architecturally sound means of dealing with it could be found, it would benefit users.
Indeed. This proposal would significantly raise the bar for imposing censorship on Ethereum at the validator level.
I understand that your opinion is that harmful MEV should be prevented by dapps. I believe that any transaction impacting the state, can create unforeseeable MEV.
If you make a DEX trade that brings imbalance to the market, even with 0% “extra slippage”, you create an opportunity for others to profit from the new market state. It could be that market observers will want to race to profit from the new state. You created a back-running MEV opportunity, from which you are not explicitly the victim.
I do not think dapp builders can imagine every possible MEV opportunity they might create with their protocol. I think the application layer is the wrong place to “fix” MEV, and it should be done whenever possible at the base layer.
Who is the victim here? Are you saying the sender is implicitly the victim because they didn’t use an aggregator? I don’t think any consensus level proposal can fix that problem.
I don’t think you understand my post at all. It’s possible your confusion originates from not knowing that Uniswap charges fees, but I have no idea what you’re on about here.
I don’t think you understand my post at all. It’s possible your confusion originates from not knowing that Uniswap charges fees, but I have no idea what you’re on about here.
Yes, I don’t understand how what you proposed is a solution. In your hypothetical, you suggested doubling swap fees. Higher fees are to the disadvantage of the trader. Perhaps you can elaborate on this to help me understand.
Thank you. I think I can help you understand my point now.
I say “expected price slippage” to refer to implicit AMM price movement from the trade, in contrast to “extra slippage” which is what the user allows beyond that to allow successful confirmation in case the price moves against them before their transaction confirms. The implicit price movement is a monotonic function of the size of trade. This means that the larger your trade, the worse your effective price.
In the Uniswap UI (below) this extra slippage is presented as a percentage. In your transaction, the percentage is used to calculate the minimum output you would accept for your input without reverting (Fill-Or-Kill). I believe that the reason most of the Uniswap users getting rekt have set their extra slippage exceptionally high is that they mistakenly believe the “Slippage tolerance” to refer to implicit slippage.
Ok I see now. Here is what I mean. I recommend setting your extra slippage to equal double the swap fee. So if the Uniswap router is sending you through the UniswapV3 0.05% USDC-WETH pool, you should set extra slippage to 0.10%. This heuristic works because the extra slippage you allow times the size of your trade is the maximum theoretical revenue a sandwicher can extract from you. The would-be sandwicher’s maximum profit (0.10%) would be completely offset by exchange fees on their two swaps. So you cannot be sandwiched because it is not profitable.
Understood. And I see that the old Uniswap UI used the “additional slippage” terminology.
Thank you for the explanation. Yes, this is a useful heuristic. But you will need to set your slippage tolerance (i.e. additional slippage) to a higher value than what’s safe against sandwich attacks at times, when the market for that pair is exceptionally volatile, and/or when gas fees are exceptionally high. The reason is that there can be legitimate additonal slippage, from real traders, that exceeds the slippage tolerance you set, that can cause your transaction to fail otherwise, and thereby cost you a significant amount in wasted gas fees.
I would go one step further. If we accept that sandwiching happens, then why does Uniswap let frontrunners take the difference between the amountOutMinimum and the actual output, instead of paying the difference to liquidity provides? If Uniswap would never pay out more than amountOutMinimum, the abusive MEV opportunity goes away and the benefit would go to liquidity providers instead. Traders get the same price as they would get when abusive MEV is present. It’s a bit worse than without sandwiching, but I think MEV is forcing us to accept that swaps are limit orders, not market orders. In hindsight, treating swaps as market orders was naive, like thinking that nobody would enter adversarial inputs in a website in the early days of the internet. That ship has sailed.
I agree, and this is why I think we should treat this in the same way that we treat bugs. In a sense, abusive MEV opportunities are game-theoretic vulnerabilities: profitable ways to use the protocol that the dapp developer had not anticipated, and that harm the intended users. It’s a class of vulnerabilities that was previously never considered, but now that the genie is out of the bottle, we will have to deal with them, similar to how pre-Meltdown/Spectre speculative execution vulnerabilities were not on anybodies radar.
If you find a (game-theoretic) 0-day, you try to report it to the developers, and hopefully you get a bounty. If the developers don’t fix it, then one way to force their hand is to release a PoC, or to start exploiting. I don’t approve of exploiting abusive MEV opportunities, but ultimately I think the dapp developers are at fault for enabling them.
For the same reason that dapp developers cannot imagine every possible MEV opportunity that they might create, I don’t think base layer developers can either. In the end, transactions are selected and ordered in some particular way. There are going to be strategies to maximize profit within those constraints. Changing the constraints changes what the best strategies are, but it’s not obvious to me that this new set of constraints admits no (or even just fewer) harmful strategies. With opaque transactions, maybe the guaranteed profitable strategies could be eliminated, but I can imagine probabilistically profitable strategies will remain.
You seem to be suggesting that because the sandwich profits go to the LP instead of the searcher you have fixed the exploitation. But the outcome in this case is the same for the victim (or in fact worse as you admit).
Base layer developers don’t have to imagine every possible MEV opportunity. It’s very simple. Toxic MEV = miners reordering transactions for profit. There can be no satisfactory solution in the app layer until you have mitigated this power that miners have in the base layer.
There are broadly two solutions to MEV:
fair order transactions - so miners can’t reorder
encrypt the mempool - so miners can’t determine the advantages of reordering
Both mitigate the vast majority of toxic MEV without leaving dApp developers with a literally impossible task. This proposal opts for (2).
Sure, Uniswap could do more, but the app layer is not the layer that toxic MEV is happening in.
An encryption solution that prevents miners reordering is a generalized solution because the problem is fundamentally miners reordering.
Decrypted transactions are put at the top of a block, it’s not something which a proposer has control over. And they can be decrypted before the next block is produced, if the key is released sufficiently in advance, in which case the initial state of the next block is known
That’s not desirable because it incentivizes block producers to censor those transactions to avoid risking their conditional payments. Is there some reason they shouldn’t be at the end of the block?
Step 1: Submit a transaction with the data hashed. Eventually, it is included in a block. 5/3 of the value of the priority fee is locked, and 1/3 of the value of the priority fee is sent to the coinbase.
Step 2: Submit a transaction with the data unhashed and a link to the first transaction receipt. Eventually, it is included in a block. 2/3 of the priority fee is sent to the coinbase of the second block (twice as much to incentivize producers to include those over new step 1 transactions). The rest of the ether is unlocked. If two epochs pass since the step 1 transaction was included and no step 2 transaction is included, locked 5/3 of the priority fee is burned.
about the sandwiching, sandwichers wouldn’t get any profit (they would actually lose money from gas) from sandwich attacking a transaction so these should stop happening
I’m trying to think how the proposer can be made to see the decrypted contents before anyone else. There are a few advantages to this.
proposer reveal
when keypers reveal their portion of the eon key, it must be in an envelope encrypted using a one-off public reveal key published by the validator, or they can be slashed
the validator then publishes their block containing
transactions decrypted by the validator using the keyper envelopes only they can read
the valid private reveal key they used to do this
a new public reveal key ready for their next proposal
Do you think something like this would work? Is there a better way of doing it perhaps?
What’s the advantage of this? In general, it seems risky because it gives a single proposer the ability to withhold blocks if they don’t like the decrypted transactions.
How exactly would the slashing mechanism work? I’m not sure if it’s possible to build a secure one as the proposer can always decrypt an honest keyper’s share and then pretend the keyper was dishonest and published it in plaintext. It’s essentially an unattributable fault.
What you could do instead is make the users encrypt transactions twice. First for the proposer and second to the keypers.
To avoid this step, you could use something like HD wallets.
So honestly, it doesn’t really add anything to shutter as it stands. I’m researching an idea for combining shutter with fair ordering where it would be significant.
Good point about the proposer being able to withhold blocks, although in my application I think the proposer would be spiting themselves, as the transactions would be included in the same order in next block anyway.
Yup, your right. We are already trusting keypers not to reveal early though aren’t we? So perhaps slashing is not required anyway.
Thanks for the input. I hope these questions haven’t distracted from the main thread. It’s a great proposal and I back it wholeheartedly. My only comment is that it needs to be non-optional to be truly effective.
Reading through again, a couple of things struck me:
This is not necessarily a disadvantage. It has the benefit that backrunners will be more selective when sending txs because they have to pay as if execution is successful even if it reverts. This should reduce spam.
This would impact users setting tight slippage for mev protection, except that this will no longer be required as transactions are protected from sandwiching anyway. Slippage can be used as it was designed, as a volatility parameter, not an MEV parameter.
I am very interested in a non-optional version of this proposal where all txs must be encrypted. This avoids a two-tier system where those exposing MEV are otherwise prioritized.
It seems trivial to require that all txs are originally submitted in ciphertext. The failsafe above seems like a good method of recovering liveness in the event keypers go offline. Do you think that is enough for a non-optional version, or are further steps required?
Hey everyone - @jannikluhn and I went ahead and developed a proposal on how to be able to try out this concept with minimal changes. In our proposal validators will opt in and voluntarily commit to building blocks following the rules of the shutterized beacon chain. In further steps, slashing could be introduced, and eventually, it could become part of the consensus.
To even simplify integration further, there could be one (or a few) “mev-boost relays” that build blocks according to those rules. All a validator would need to do is connect to them.
On Gnosis Chain we are confident that we can get a decent % of validators to opt into this scheme. To make it as easy as possible for users to use such transactions a “trusted RPC” can be introduced that can accept regular transactions but then encrypt them and schedule them for the next block that will be built by a participating validator.
