The ability to generate Maximal Extractable Value, or MEV in short, is perhaps the most significant change that Ethereum validators will experience post-Merge. While MEV has been extensively discussed in the crypto community, its extraction in the PoS era is not a straight-forward process. There is a wide range of decisions to be made about transaction censorship, choice of MEV extraction tools, solutions to the principal-agent conflict of interest in delegated staking, and other aspects of MEV extraction. Naturally, our DAO must address them to be prepared for the Merge.
In this post, we will explore the challenges of MEV extraction and propose solutions to them, with a goal of formalising our policy for tackling MEV on a DAO level.
High-level overview of MEV and the extraction process
If you are new to MEV and the challenges around it, this section is for you. If you’re familiar with MEV, feel free to skip the next section.
In the post-Merge world, Ethereum will rely on a network of validators to bundle together pending transactions into blocks. Interestingly, validators have the ability to choose which pending transactions will be included into the next block, as well as the order in which they will be executed.
Anyone who has ever tried to mint an NFT from a hot collection or submitted a large trade through Uniswap can confirm that the order of transactions & the mere fact of their inclusion into the nearest block are immensely important for traders and other users of the network. For example, you can gain an (potentially unfair) advantage over others by looking at all the trades waiting to be included in the block and paying extra to get your trade included first, effectively front-running the others for profit. It sucks to be on the receiving end of this.
In a mature state, the practice of front-running evolves into algorithms that squeeze out every possible penny of opportunity by including transactions in the “right” order, sometimes even to make use of the opportunities cross-chain. This is exemplified in sandwich attacks, front-running, back-running, toasting, you name it. The ultimate goal is to generate what we call Maximal Extractable Value, or MEV - the additional profit that becomes available when users take advantage of the way transactions are organized into and within blocks.
When left unchecked, MEV is bad news for the ecosystem. Its high complexity and potential for relying on private deals made between traders and validators create a barrier of entry for those who do not possess the relevant knowledge and tools. This process has massive economies of scale, and so over time unchecked MEV leads to less competition, centralisation of block production around those “in-the-know” and less value left to the average user of the network. Sad.
Fortunately, there is a group of researchers called Flashbots that work on democratising access to MEV by making use of the Proposer-Builder Separation architecture, or PBS in short. Whereas previously validators (node operators) were both the builders and the proposers of blocks, block construction now becomes the job of MEV searchers & dedicated builders. This leaves validators with the sole role of proposing blocks and removes the need to enter exclusivity agreements with trading firms/purchasers of block space. Proposer and builder roles are separated, hence the name.
The benefit of this approach is two-fold: all the validators can benefit from MEV instead of a select few, and their profit per block may increase as builders are forced to compete with each other in a market without barriers to entry. This eliminates the centralising effect of MEV extraction on the network (on the validator level) and instead democratises access to MEV.
While immensely beneficial, MEV extraction and the required use of PBS-based tooling introduce a whole new set of interesting challenges for StakeWise. Below, I will explore the topics our DAO must figure out to ensure the smooth running of our MEV strategy, and outline the suggestions of the development team on each topic.
Defining the StakeWise DAO MEV extraction approach
Which middleware should we use for MEV extraction?
MEV-Boost from Flashbots is the sole MEV extraction tool currently available on the market. It was developed in consultation with the Ethereum Foundation and uses PBS to democratise the access to MEV and enhance validator returns.
The PBS architecture used by MEV-Boost allows to choose multiple relays - de-facto communication channels through which Builders submit their bundles - and helps validators pick the payloads with the highest value.
With over 90% of miners in PoW using Flashbots, MEV-Boost will likely have a similar if not greater penetration, especially thanks to its first-mover advantage.
It is our opinion that StakeWise and its node operators must use MEV-Boost to amplify validator returns, but the DAO must remain open to using alternative tools if they emerge. The team has pre-emptively integrated the tool into the StakeWise infra package and has successfully tested it on the Goerli testnet. From the technical standpoint, all of our operators are ready to run MEV-Boost as of today, and are waiting for the DAO sign-off on the decision.
How should we collect MEV?
In the PBS setup adopted by MEV-Boost (and likely by the solutions that come after it), builders are free to choose the relays to work with. Their choice will depend on how reliably their bundles get picked up by the validators, likely leading to a centralisation in relays over time due to the network effects. At the same time, it is possible for relays to fail, so there will likely be a few popular relays out there for the sake of diversity.
If we want to maximise validator profitability and avoid single points of failure, the StakeWise DAO should create & consistently update a list of the most profitable relays that the operators can use & fall back on. This presents several challenges:
- The profitability of various relays must be monitored, but no tools are currently available for it
- The list must be periodically updated with DAO approval, which may present governance challenges due to time sensitivity
- Additional considerations other than profitability, like sanction compliance, may influence the composition of the relay whitelist (more on this below)
As a solution to these challenges, the team suggests that the DAO:
- Maintains a sufficiently broad list of popular relays to capture most of the available bundles while the team builds the monitoring tools to filter out underperforming relays
- Establishes clear criteria for relay inclusion into the whitelist to simplify the governance process & possibly automate it / fast-track it
- Maintain different whitelists for the node operators to choose from to filter out undesirable transactions without hurting profitability
Will StakeWise engage in transaction censorship?
The recent law enforcement action against Alexey Pertsev, a Tornado Cash developer, has put the Ethereum ecosystem on its toes. The Office of Foreign Assets Control (OFAC), a US-based government agency known for curating a list of individuals with whom transactions are forbidden for US security reasons, has added a bunch of new Ethereum addresses to its sanctions list. Interacting with said addresses is considered a violation of US sanctions and supposedly may lead to financial penalties and criminal proceedings.
While it is not explicitly mentioned in any official statements made by the authorities, some node operators are concerned that merely proposing blocks that include transactions from the sanctioned addresses will constitute a violation of the sanctions. In light of this risk, it is possible that some of the node operators in the StakeWise validator set will prefer to censor (i.e. not pick bundles with) the transactions from the sanctioned addresses. This is especially true for the US-based node operators.
All of us may have different views on whether such risks are real or not, but one thing is clear: until withdrawals are enabled and off boarding for node operators is possible, our operators will want to have the option to censor such transactions. The team proposes that the DAO create a separate whitelist of relays that do not accept the transaction bundles that contain OFAC sanctioned addresses in them (for example, Flashbots-operated relay). The whitelist would still include only the most profitable relays, but their subset would be limited to those that block sanctioned addresses from interacting with the network. Unfortunately, this seems to be the only available workaround until validator withdrawals are enabled
How to ensure that our policy is being followed?
One issue with delegated staking is that the node operators that run validators on users’ behalf fully control the validator setup. In the post-Merge era, this includes the ability to set the
fee_recipient address, i.e. the destination address for MEV accrual. They also have the capacity to pick any relay they want, or even decide to start building blocks of their own, not running the MEV-Boost client.
The key implication here is that StakeWise users may underperform the market if the node operators cheat the protocol by setting another
fee_recipient address instead of the contract StakeWise has dedicated for MEV accrual, or by choosing relays not included in the StakeWise DAO-approved whitelist(s). The issue is made worse by the absence of a method to verify whether a certain node operator has set the correct
fee_recipient address and chose the right relay. Naturally, this requires us to put a lot of trust into our operators, unless there are mitigating factors.
One of such factors that StakeWise relies on is the control of the exit signatures of all the operators in the protocol. This means that if the wrongdoing is detected and is identified to have been malicious in its intent (and not merely an operational error), the misbehaving operator can be removed from the StakeWise network by having all the validators it is running shut down and funds returned to the users / reinvested with a reliable operator.
However, it solves the issue only partially - in the absence of monitoring tools, it is difficult to detect any wrongdoing, let alone verify intent. To deal with this, the StakeWise team is considering whether to build its own monitoring tools or use third-party solutions that are expected to reach the market by the end of 2022. Unfortunately, no comprehensive solution to the problem exists, so at this time the team has elected to build basic monitoring tools that may show non-compliance with the StakeWise DAO policy, albeit with a delay. Improving the monitoring system will remain a priority area after the basic tools are introduced. The team will keep the DAO posted on the progress towards full resolution of this issue.
And thus, these difficult topics seem to form into somewhat of a policy for MEV extraction for StakeWise. To recap, the team proposes that the DAO:
- Adopts MEV-Boost as the preferred tool for MEV extraction and requires all StakeWise node operators to run it;
- Adopts two whitelists of supported relays, one that includes relays that don’t engage in transaction censorship and another that includes relays that do censor, and requires all StakeWise node operators to only connect to relays included in these whitelists;
- Adopts a no-tolerance policy towards acts of malicious intent by the StakeWise node operators, such as:
- Not setting the fee_recipient address to the StakeWise DAO contract for MEV accrual
- Using relays not included in the StakeWise DAO-approved whitelists
- Frequently reviews the whitelists of relays and includes / removes the relays that stop meeting the quality criteria, to be determined after the Merge based on empirical data;
- Reviews the above policy at least once every 12 months, or more often in case of significant changes to the operating environment.
While this can be a lot to digest, I invite everyone to weigh in and ask questions / drill down into any subject that they felt was not sufficiently addressed. We will proceed to the voting stage in a week’s time so let’s use the next 7 days to discuss this proposal and find the optimal way forward.
Two-slot Proposer/Builder Separation
Why Run MEV-Boost
MEV-Boost repo on Github