💸
MEV Harnessing System
Shell opens new possibilities for fighting MEV
This article explains the mechanics and game theory behind the upcoming MEV harnessing system. It does not dive deeply into details on technical implementation, which will be explored in a forthcoming white paper.
What if you could turn MEV bots from frontrunning nuisances into blockchain navigators competing to complete your trade with optimal efficiency? With the new MEV harnessing system in Shell, it happens automatically with every trade. How? To understand what makes this method work, we need to lay out a few things about MEV.
MEV, short for ‘maximal extractable value,’ occurs when a block producer strategically orders transactions to extract value from the ecosystem. (See another overview from Paradigm Research here.) In some cases, MEV can be a good thing, making DeFi more efficient. For example, arbitrage bots keep DEX prices aligned with each other. Additionally, liquidator bots help protocols such as Maker or Aave stay over-collateralized.
However, some types of MEV exploitation can be rather pernicious. One particularly common example is the act of frontrunning. Before users’ transactions get added to a block, they sit in the mempool. This means that frontrunning bots can view your trades before they happen. Using this information, these bots can trade against you and take your money before your transaction is processed.
Frontrunning has existed as a problem for markets since their inception. With the Ethereum blockchain, transactions are publicly viewable before they are added to a block. That means a potential front runner can see your transaction before it happens and immediately trade against you. There is no way to fix this problem without fundamentally changing how Ethereum works.
Fortunately, with Shell, we don’t need to eliminate MEV. We can instead harness it, incentivizing MEV bots to execute trades on behalf of our users. With this change, MEV makes trades more efficient, not more expensive. The previously adversarial goals of transactors and block producers are now aligned.
To understand how the harnessing system works, let’s first take a closer look at a typical sandwich attack. A form of MEV, sandwich attacks place exploitative bot transactions before and after a user’s transaction in the block. By manipulating prices, this ‘order sandwich’ causes the user to pay higher fees than she otherwise would.
Say Alice wants to swap 100 DAI for USDC using a DEX. In a world without MEV, here’s what would happen:
This is the basic idea of a blockchain transaction. In an adversarial environment, however, it’s not always that simple. In the next example, Eve is a frontrunner. She’s monitoring the mempool, and she sees Alice’s pending swap transaction before it gets ‘mined,’ or committed to the blockchain. With this knowledge, Eve decides to execute a sandwich attack, placing her own orders just before and after Alice’s transaction:
By swapping 1,000 DAI for USDC right before Alice’s trade, Eve moves the price balance between USDC and DAI in the trading pool. As a result, Alice’s trade is executed at a less favorable exchange rate than normal, causing her to receive less USDC than expected for her traded DAI.
After this, Eve’s second transaction goes through, reversing Eve’s prior swap and capturing the DAI that Alice lost due to the temporary shift in exchange rate.
Generally, Alice can protect herself from sandwich attacks like these by using slippage protection. Slippage is the difference between the expected and actual cost of her trade. Slippage protection works by allowing Alice to specify the largest actual cost she’s willing to accept. Here’s an example of slippage protection in a submitted transaction:
The ‘require’ statement in Alice’s transaction specifies the minimum amount of DAI she’s willing to accept in exchange for her USDC. In the example above, Alice requires that for every 1 DAI she trades, she must receive at least 0.99 USDC. If the threshold isn’t met, her trade does not execute. Thus, Eve has no reason to sandwich attack the trade, since manipulating the exchange rate would simply cause Alice’s transaction to cancel.
This works for simple swaps. But what happens if Alice wants to execute a complex transaction, one which invokes many different financial primitives on the blockchain? With our MEV harnessing system, Shell provides an elegant solution.
To understand how it works, we need to go over some of the core mechanisms in Shell. Specifically, we need to look at the Ocean, Shell’s central accounting system.
The Ocean seamlessly connects every contract in the Shell v2 ecosystem.
DeFi is made up of many independent smart contracts known as financial primitives. These can be tokens, exchanges, or anything else you can think of. Since each primitive is built in a different way, connecting them together for a big transaction can be hard and expensive. Shell makes this easier by providing a unified accounting layer known as the Ocean. When a primitive is built on top of the Ocean, developers can save time by allowing Shell to handle token balances, allowing the devs to focus solely on the financial model of their primitive.
The end result is an easily scalable network of primitives with automatically linked and standardized accounting logic. This makes the prospect of complex, multi-primitive transactions way, way cheaper. It also allows these big transactions to be performed in a single block instead of multiple time-consuming and vulnerable steps. This saves a huge amount of gas, creating a new world of possibility for projects that utilize the potential of Shell’s complex transactions.
But let’s talk about how the Ocean allows everyday traders to harness MEV for their own gain.
Say, for example, that Alice wants to make a complex series of trades. She wants to swap DAI for USDC, then USDC for ETH, then use ETH to purchase an NFT. Without Shell v2, Alice would have to conduct these trades across multiple transactions, each one of which would be vulnerable to MEV exploitation. Here’s how her transactions might look without Shell v2:
At each step of this transaction, Alice has to worry about MEV. That means she needs to set slippage protection parameters for every trade. The more trades she has to do, the harder it is to know the appropriate level of protection, because the price of early trades will have downstream effects on the price of later trades.
Shell can dramatically simplify slippage protection for complex transactions like the one above. Instead of protecting each step individually, Alice can check to make sure that the input (DAI) and the output (NFT) are what she was expecting. Shell makes this possible because it seamlessly bundles multi-step transactions and can check the net changes to Alice’s DAI and NFT balances.
With only two checks, one for DAI and one for the NFT, Alice can protect her entire transaction against frontrunning — no matter how complicated the intermediate steps might be. With the right user interface, this example case can appear to a user as one seamless step, allowing traders on a marketplace to purchase NFTs with any supported denomination of fungible token they like. Under the hood, it’s one transaction, meaning there’s no opportunity for hostile actors to ‘inject’ exploitative transactions in between the steps.
Because Shell’s Ocean contract supports any type of DeFi primitive, this single-transaction schema can be extended to encompass AMMs, lending pools, and even primitives yet to be invented.
So MEV is solved, right? GG, EZ. We saved the ecosystem…
…but we can do even better.
Although we can now write simple balance checks to limit the value extracted by frontrunners, we haven’t fundamentally changed Eve’s incentives. She and her bot army are still out there, watching and waiting for Alice to make a mistake. Whenever the bounty looks good enough, she’ll pounce. But, what if there was a way to harness Eve’s incredible talent and ambition for the purpose of good?
With some clever cryptography, it turns out that Alice can completely realign Eve’s incentives to the point where Alice herself doesn’t even need to execute the trade. Instead, Eve will execute it for her, as efficiently as she possibly can.
How is this possible?
Right now, our transaction-writing paradigm begins with a transaction path, then includes appropriate checks to make sure Alice doesn’t get ‘ripped off’ in the process. But, what are we actually trying to accomplish here? Alice wants a specific NFT, and she wants to spend DAI to buy it — even though the NFT sale contract trades in ETH. As long as she spends what she has and gets what she wants, she’s happy. The steps her tokens take to get there don’t need to be set in stone.
With the right touch, Alice can harness the incredible power of the Ocean Accountant.
So, let’s flip things around. Instead of starting with a path, Alice writes a transaction stating that she wants to spend 100 DAI to purchase a specific NFT. Alice can then sign the message, telling Shell’s Ocean Accountant that she will accept any transaction path which meets these specifications.
You can think of Alice’s signed transaction as a job posting, a bounty open to any intrepid Ocean navigator. She’s willing to spend 100 DAI as long as she ends up with the NFT she wants. Anyone, including Eve, can submit a transaction that fulfills it. If Eve finds an even more efficient path, she gets to keep the difference in DAI as profit.
Here’s an example.
In the above case, Alice wrote and signed a transaction offering to spend 100 DAI in exchange for a specific NFT. Eve, seeing Alice’s offer, plotted a path to complete the trade with high efficiency, routing Alice’s DAI through multiple stablecoin pools to reduce the slippage cost. Why would Eve help Alice? It’s because she gets to keep the change on Alice’s 100 DAI. After buying the NFT, Eve’s transaction delivers it to Alice, keeping the saved 1.00 DAI as compensation for her efforts. Even better, Alice’s price is all-inclusive. Eve handles the gas, and Alice doesn’t have to worry about spending anything past her 100 DAI budget.
Eve not only found a valid path through the Shell v2 network, she actually found a more efficient path than Alice’s original plan. With this system, Alice doesn’t have to worry about figuring out trade paths. She posts her bid as a signed transaction, then waits for Eve or someone like her to fulfill it. Eve, meanwhile, gets to focus on doing what she does best — using her considerable powers to find arbitrage opportunities. She’s no longer waiting for Alice to make a mistake. Instead, she’s competing to fulfill Alice’s bid, earning more and more the better she gets at efficient routing.
The former frontrunner is now the executor of Alice’s trade. Alice signs an offer transaction and Eve fulfills it. The incentives are aligned, and the on-chain actors are able to specialize symbiotically according to their skills. A bandit is now a bodyguard. Eve is Alice’s protector, her navigator-for-hire.
Alice and Bob are ready to explore the Shell World for fun and adventure.
This innovation is even bigger than it sounds. For every individual offer transaction, of course, Eve’s incentive is to find the most efficient possible path. That much is clear. Now, what about when a block contains a multitude of offer transactions? Say Eve is the block producer here. Not only will she find the best swap routing paths, she will also find the best transaction order. Eve controls every aspect she can to bring trade costs down, maximizing her profits and increasing the efficiency of the system.
Last modified 4mo ago