Preparations for the Merge (Part 2) - MEV Extraction Method

[kiriyha]

Introduction

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.

Summary

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.

Summary

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:

1. Adopts MEV-Boost as the preferred tool for MEV extraction and requires all StakeWise node operators to run it;
2. 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;
3. Adopts a no-tolerance policy towards acts of malicious intent by the StakeWise node operators, such as:
   1. Not setting the fee_recipient address to the StakeWise DAO contract for MEV accrual
   2. Using relays not included in the StakeWise DAO-approved whitelists
4. 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;
5. Reviews the above policy at least once every 12 months, or more often in case of significant changes to the operating environment.

Discussion

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.

LFG

References used:

Two-slot Proposer/Builder Separation
Why Run MEV-Boost
MEV-Boost repo on Github

[porcupine]

Thank you for the extensive write-up of the team’s thoughts on moving forward with MEV. The proposals sound reasonable to me.

Is it really that difficult to monitor validators’ compliance?

[rustedpopcorn]

It’s difficult for me to support something enabling censorship on a decentralized platform. This is a dangerous start.

To add to this, fear shouldn’t be a deciding factor of legal uncertainty.

Im no lawyer, but Ethereum is a distributed ledger, node operators at no point have possession or control of assets from sanctioned addresses. They are only recording the existence of those transactions which does not violate an existing law.

[bgraham-vh]

I am going to drop a few thoughts in here as a stakewise node operator. I am a bit grumpy from being up early watching logs to make sure Bellatrix went smoothly for stakewise users.

Enforcement:
At first glance while the proposal seems reasonable “How to ensure we get max returns in the new world of post-merge”. However, the way it is presented doesn’t feel great as a node operator; especially the second part of the post.

I for one, as a node operator, am not interested in supporting a community or platform that might feel ok with pointing gun at me. If that is how the relationship is going to function then we are already down a dark path.

Node operators are not serfs to be subjugated to the will of the Crown (DAO) by force if need be. We are partners in our efforts to secure the chain and reap the rewards.

Node operators are interested is maxing profits as well, because we get paid out of those profits. But Node operators have another pull against maxing profits and that is stability as we own the uptime. In our business if we are down, no one makes any money and I am more inclinded to protect that beyond eeking out extra profit in the short term.

While I think mev-boost and other PBS schemes are the future, I believe it too early to be talking about enforcing the use of them. The lighthouse devs agree with me as do many others.

“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”

That is great that Stakewise has tested their setup with mev-boost. That is probably wise since stakewise still holds a vast majority of the validators still for the pool.

That being said VeriHash has run into many little issues using the canned helm charts that we have had to tweak for our setup. We are independant and this should be expected as not runing like for like infra as stakewise is good for diversity which is good for stakewise.

However, just because it worked in one setup doesn’t mean it will work in all setups and just because it is in the helm charts doesn’t mean all node operators are ready to support it.

Each node operator should be allowed to integrate it when they are comfortable and ready. If that means they are doc’ed performance points because they aren’t returning max APR so be it. They may have very good reasons for not doing so.

My point is that instead of enforcing relay lists/mev-boost/etc via the gun point of the DAO holding operators keys to force exit for non-compliance (which is something even Lido to my understanding doesn’t have over node operators). Why don’t we focus on how we are going to measure operator performance and returns and set performance bands that allows them to get their next key filled?

The above would be incentiving max returns, without falling back to “if you don’t do this, I pull this trigger”.

Exiting an operator because they don’t share EL rewards does seem reasonable to me. But I for one want to see a documented process for how that happens.

What are the steps invovled to exit an operator for such an action, how is that action determined. Remember when using PBS/mev-boost the fee recipient is overrided and operators no longer have control of where the EL rewards go so how is it going to be determined that a node operator is widtholding in that scenario, what is that process, and how does an operator have “their day in court”?

Also, I would like to see a DAO vote be enforced for removing an operator. I believe is is mentioned that a vote will be held, but how is that enforced as opposed to it being left up to simple majority of the shard holders?

OFAC and Sanctions and US Persons:
Each US person/entitiy that is pool participant and/or node operator needs to do their own research and potentially engage in thier own council to determine their risk. We have and our expensive coucil that specilizes in these things hasn’t painted a pretty picture; but that is sort of their job it is up to us to decided how much risk we want to take.

While OFAC has not explicitly called out node operators for producing blocks with sanctioned addresses they also don’t have to as the sanction langauge is broad in order to ensure coverage of cases that OFAC may want to pursue.

Quote from the Tornado Cash Sanction but really just boiler plate in all OFAC sanctions:

“These prohibitions include the making of any contribution or provision of funds, goods, or services by, to, or for the benefit of any blocked person and the receipt of any contribution or provision of funds, goods, or services from any such person”

Depending on how you read that any US person staking, node operating, or other wise benefiting an sanctioned entity (address) or assets (deposits from sanctioned addresses to the pool) is in violation of the sanction.

Let take a couple quick examples of how that might happen:

1. An EU node operators proposes a block with n sactions transaction in it. The priority tips from the block on the EL layer are returned back to the pool and disitrbuted to stakers/node operators. Because the payment for the TX from from the sanction address, and then that payment was ditrubuted to the pool, ALL US persons/entities particapting in the pool as stakers or operators benefit from the sanctioned assets/entity. This puts them in violation of the OFAC sanctions.

2. A sanctioned address deposits eth into the POOL, this is staked on a US/EU node operator. If node operator that sanction eth is distrubuted to is an US node operator they are now in violation of OFAC sanctions. Secondly, any rewards returned to the pool (proposals, attestations, EL rewards) that are generated from said sanctions assets, regardless of node operator, puts any US persons in violation of sanctions much like (1)

Additionally, a very conservative interpretation of the sanctions and its limits on US Persons also may include US Persons participating in DAO activities outside of investments in the pool; if said DAO is found to be in violation of OFAC sanctions.

Each US person needs to figure out what their risk tolance is themselves though and none of the above is advice of any kind. I am simply just sharing what I have paid for so that others may consider it.

Will the OFAC go after individual US persons staking or individual US node operators? That hasn’t been the case so far not even for bitcoin/ethereum miners now. But most US miners also censor now so maybe there isn’t a reason to.

That also doesn’t mean they wont and while there is a generally accepted escalation process for OFAC (letter, angry letter, action civil, action criminal) they have proven to both follow that process and jump straight to club fed if they think the act aggregious enough.

Let just ask the mom and pop that got fined 150K for accidently using a shipper that benefitted North Korea and how that cheap shipping price that saved them a bunch up front turned out to be the ruin of them.

Or how it doesn’t matter if you “didn’t know” because OFAC sanctions are “strict liability” meaning that it is always on the US person to ensure they are doing a safe transaction…all ways, no excuses.

Then again, Stakewise/Lido and others aren’t mining pools they are staking pool which accept deposits. This is different than mining where the only thing in control of the miner is the TXs they include the block.

In a staking pool there is control over deposits that can be put in place that turn into validators that then produce blocks that node operators have control over in regards to TXs included.

VeriHash’s ask here is that the DAO do an audit of deposits to the pool and verify how much eth has been deposits by sanctioned addresses.

This is something we will have to ask for anywhere if the OFAC comes knocking on our door so having that data point updated on a regular basis would be helpful.

Also if the DAO refuses to reject deposits by sanctions addresses this could put their US participants at risk and it will be up to each participant to decide their tolerance of said risk.

I for one do not want to censor anything but I also am beholded to the jurdiction I am legally operating out of and am a person within. I will fight it any way I can within my legal boundaries but if adoption is important (which is it as it drive utlility and thus value) and ethereum/crypto in general is going get past “the great filter” this test and how it is navigated will likely determine the future.

Plus, we had no problem rolling back the DAO hack unilaterally is that also not a form of censorship?

[ottodv]

There’s a lot of stuff to take in here!

Requiring validators to distribute MEV rewards to the DAO is definitely a must, but requiring them to censor certain addresses should not be.

The way I see it, each validator operator is responsible for following the laws in their own jurisdiction, our decision is if we allow them to censor if they believe they legally must. Unfortunately that answer would be yes, as any validator must be able to follow any laws that apply to them.

In regards to the whitelisting of filters and use of MEV-boost, could we not set it up in a way that a validator is motivated to extract the maximum/optimal value, but the tools and filters they use remain largely their own operational choice. The DAO would keep track of performance of different operators, and certain decisions, like new validator assignments, could be made using that info.

[TobiWo]

First of all, thanks @kiriyha for the extensive write-up. I think it covers most of the problems we are facing right now. However, it feels like that it is impossible to discuss everything and come to an reasonable conclusion in 7 days.

Full disclosure: This is my personal opinion and may differ from what my employer (T-Systems-MMS, as we are a future node operator) supports.

@bgraham-vh made a beautiful post why a lot of points of the proposal are hard to tackle currently. I mean there is no clarity about almost all mev related things.
Maybe to add another one: There are already discussions about social slashing in case validators censor transactions. So it feels like that if we fulfill OFAC sanctions we will get kicked by the community . I know, all of this is not solution centric.

I fully understand that Stakewise needs to be able to compete with other protocols (in terms of APR) but I agree with @bgraham-vh that it is probably a good idea to get rid of the general “pull the trigger” like verbalizations for node operators in the first place.

Couldn’t Stakewise start with a popup on the website that the APR may differ from other protocols because everything is so new and unclear? It could point to the fact that decisions were made because of stability and APR will most likely increase over time as the tooling gets more mature and things get clarified in general. Maybe this is too naive because people just see the dollar sign. So my technical point of view is most probably not a good reference . Pretty hard topic.

[Steel.Key]

First off @bgraham-vh – want to thank you for being a node operator and a valuable SWISE partner. I’m sure @kiriyha did not mean to be too crude with the gun photo but I think we both would agree that there needs to be proper monitoring/accountability on the node operator side. I’m sure if bad actors were siphoning MEV off for themselves, you would want them held accountable? As I’m sure you would like for the DAO have the ability to reallocate that collateral towards good actors like yourself no?

In regards to OFAC censuring transactions – I know this is a sticky subject but IMO the ethos of ETH as a blockchain is a permissionless blockchain that everyone is free to use. It’s a slippery slope to start to say we can exclude a transaction unilaterally because X, Y or Z . What if Russia or China make proclamations on sanctioned wallets? Illicit activities are most definitely a concern but ultimately that is an issue for fiat on/off ramps (i.e. exchanges) and/or the application level to reduce the usability/ultimate value of sanctioned collateral. One of the beautiful things of the Ethereum blockchain is that it has perfectly visibility and I think it is more than appropriate for node operators (who are so inclined) to flag said transactions to relevant authorities should they see fit.

That said – node operators definitely should have the choice on OFAC compliance and I believe that the teams proposal to have dual relay option (OFAC compliant vs noncensuring) feels extremely fair.
While node operators aren’t being forced into a non OFAC compliant situation with this proposal, as stewards of other people’s ETH deposits, there should accountability on the relays that they do choose & how the share the related MEV. I agree that there should be fair warning of any potential actions and a DAO vote in the event changes need to be made on the operator level.

Ultimately we are all stewards of the ETH deposits that have been entrusted to StakeWise DAO and we likely need to come to a decision as a collective DAO on where we stand on the subject of transaction censuring. As a Decentralized Autonomous Organization – IMO we uniquely are positioned to lean into the ethos of a decentralized Ethereum while maximizing MEV/the security of the Ethereum network (vs other centralized peers)

Few question I have for @kiriyha –
• Why do we have to wait until validator withdrawals enabled to make changes? Can we not take actions before hand/reallocate ETH?
• Who are the various relays/builders the team you are considering and how will they be accessed?
• Node operator monitoring tools - Buy vs build – who are you considering working with/would building out ourselves be a competitive advantage vs peers and/or perhaps something we can sell to the market/use to find/recruit top node operators?
• What are Blockdaemon/institutional capital’s views here?
• I’m sure this is a technical long shot but is there a way to have a dual node operator set up, where if OFAC related transaction is spotted in a block, a node operator who wishes to stay compliant is able to pass off validation to a non OFAC compliant node operator?

[Steel.Key]

Would also point everyone to Paradigm’s recent report on the topic Base Layer Neutrality - Paradigm which is in agreement with me on the subject.

“We believe that the public recording of the order of data blocks at the infrastructure layer is no more “facilitating” a transaction, or dealing with, or contributing or providing services to sanctioned parties than the existing communications infrastructure that routes financial messages daily around the world, whether through internet service providers, routers, network switches, email and chat programs, DDoS filters and other network security protocols. In our opinion, the fact that crypto’s base layer infrastructure has been decentralized by distributing basic functions to independent participants makes each actor’s actions even less likely to meet this threshold.”

[brianchilders]

completely understand the challenge that mev-boost brings in terms of centralization.

[bgraham-vh]

Lots of great stuff here, and most of it I agree with. But there are a few things that from my perspective as a US based node operator I still have to deal with.

1. The ethos of Ethereum and the idea of base layer neutrality all make sense and are all things I agree with. The problem is that until there is a tested and established legal argument around things like base layer neutrality and ethereuem’s ethos its just like…someones opinion and that isn’t something that short-circuits the real concerns around strict liability that are present today; even if I am a conscientious objector to my juridisction’s requirements.

2. Parts of ethereum fall under things like SWIFT and being a neutral network. The “Berman Amendments” specifically added to IEEPA exclude the sanctioning of information in any form. This is how SWIFT claims to be a neutral network. SWIFT doesn’t have to kick banks off its network, it does so because it feels it benefits the overall “community” to do so, but they aren’t strictly legally required to.

   When a node operator attests to a block they are acting like SWIFT. They didn’t put the block on the chain, they are simply passing information along and validating the state of the chain locally as part of that function. In short the act of “Increasing the Probabiltiy of Finality” of any given transaction already on the chain is likely a neutral act and protected under the “Berman Ammendments” and thus not sanctionable.

3. When a node opertator produces a block, this isn’t simply moving information around and broadcasting to the network as the production of a block invovles tips from TXs. These tips are payments, and thus when a block is produced with a TX in it from a sanctioned address it is paid from that address and thus a sanction violation on the face of it for a US person.

   An argument could be made that the node operator is just moving information around, thus they are still neutral, and the TX tip paid is at the very core of how the network ensures its function. The rub here is that the block producer/builder has control over what goes in the block and that control is what weakens that arguement a bit.

   You could just exclude the “problematic” TX from the block you produce and that is sort of the point of the sanctions. To change the behaviors of those that have the ability to exercise control in the “problematic” situation.

4. Beyond the above which just deals with who touches sanctioned property/entity and/or who benefits from those interactions via payments there is the entire notion of servicing sanctioned entities/property.

   A US node operator staking ethereum from an sanctioned address/entity is servicing it. There isn’t a question about that I don’t think because if the node operator doesn’t do their job and service that ethereum the on-chain effects are pretty clear.

   Servicing sanctioned property is a violation for a US person and even if I as a node operator cannot know where the ethereum came from, simply that it came from a pool, strict liability still applies even if I don’t want it to.

5. The only plausible way I have found thus far to claim that I am not in violation is based on a generally unwritten rule within the US Dept of Treasury that says US persons holding stock or interest in a business which does less than 10% of its total business with a sanctioned entity is “clear” to continue holding an interest/stock in said business.

   Extending that out to my situation if the pool I am operatoring for proves that less than 10% of the staked assets in the pool are from sanctioned addresses. Then if OFAC comes calling I can say “well the sanctioned property is so dilutited that it isn’t really a benefit to the sanctioned entitiy and that is why I claim I am not in violation”.

   This is still an unwritten rule and thus not real guidance on the part of judging where OFAC would take things.

6. I was not making an argument that we shouldn’t hold node operators accountable for their performance. I was bristling at the idea that enforcement is the thing to focus on first before actually establishing what we are measuring.

   We know we want to measure performance. We know we do not want to reward bad behavior. But I still think we need to classify, define, categorize, and agree to what those things are before we start talking about how to enforce anything.

   I am sure no harm was intended, but you don’t start off a conversation with establishing who is holding who at gunpoint. It isn’t productive and it only serves to highten tension and place participants on different sides of the table.

7. In regards to redistrubuting eth and re-allocating stake eth across the operators when there is a bad actor; that can truely only come with widthdrawls. There is likely no way to ensure the safety of the staked eth on a new node operator without first ensuring a validator exit, and then doing a widthdrawl to restake.

   Even the exiting a bad operator will likely still result in leaking because duties must still be fufilled even while in the exit queue. Why would a force exited operator continue to expend resources maintaining on-chain operations of validators in that situation?

   Node operators know/see their validator keys, they have to in the present situtaion. We can’t simply take the keys from a bad actor and give them to a good one and expect the bad actor not to willfully slash the validators as an act of retalition.

   SSV addresses many of these concerns and it is inching closer to mainnet. But it comes with other things like Smart Contract risks and such. I also still wonder if operator selection still isn’t made carefully if you couldn’t have 3 out of say a set of 4 node operators collude to get the key that is sharded amongst them. A thought experiement for another time perhaps.

   Node operators knowing their keys in the present system does lead to another question though. If you exit a validator and it is queued, can you still slash it? One would assume so if duties are still required while sitting in the exit queue in order to avoid inactivity leaks. If so how does force exiting a bad operator solve anything since the bad actor could just slash the “waiting to exit” validators anyways? And yes this can really happen I was asking rhetorically.

   Once slashed attestations and proposals from that validator are invalid and thus the validator will effectively inactivity leak until it extits. Slashing penalties are applicable even after exit so long as the validators is not in “withdrawable” status. If the queue is long enough you exit with 0. Even if the queue isn’t that long it will still take around 39 days to fully exit a slashed validator and it will inactivity leak the entire time.

   Now imagine the DAO exiting 200 + validators held by a single bad node operator for not sharing MEV. That is a lot of damange a bad node operator can choose to inflict on vulnerable validators. And that damage is going to be WAY WAY WAY higher than then any MEV they didn’t/wont share. Sure they will lose the stakes, loose the income stream, and news will spread of their misdeeds likely making it much harder for them to stake for other pools, platforms, people.

   But that may not matter to them and how long will it take the pool to recover from node operator wanting to watch the world burn after being forced exited with nothing to potentially lose vs missed MEV back to the pool?

   This is why these things need to be carefully thought out as to what, when, why, and how actions are taken especially with a forced exit and considering impacts in different cases.

   The DAO holds operators keys as a last resort to ensure they can force exit a bad actor to minimize damage or when withdrawls are allowed and/or node operator doesn’t want to stop staking the eth requested for widthdrawl.

   That is the reasoning used by the DAO to justify holding operator keys. On the face of it I buy that it MAY in very controlled circumstances reduce damage done by a bad node operator to the pool. But it also feels like a security blanket/paper tiger.

   It can a have real chilling effect on good node operators as well if they feel pressured due to standing on a trap door without good definitions of when said trap door is activated and that activation is not ideally secured by a required DAO vote.

8. The argument that not censoring is more profitable is just one I don’t buy at least not in the real world case but maybe in the theoretical.

   As of yesterday there was 475K active eth wallets and my rough count of the sanctioned addresses on the OFAC SDN list is about 250. That represents 0.0005 percent of the total eth active average wallet addresses. Ethereum does on average about 30 TPS, so about 2.6M transactions per day. The average transaction “value” in TX tips is about 0.78 cents USD.

   Given that, it would take about 348.29 days to see one transactions from one sanctioned address…or to make .78 cents for the pool if MEV sharing. Since the average effectiveness of all eth validators is about 96%. A node operator will likey loose more $ in a three month period just because “p2p networks and head votes are hard” than they will blocking sanctioned addresses.

   I know my math is rough here, and yes tornado cash smart contracts are likely busy and represent more TXs per day and thus more “profit”. I haven’t taken the time to actually drill down that far because it still likely isn’t worth the liability of handling the transactions on the money/legal side as a US person anyways.

9. Point (8) above cuts both ways, you could say “then why spend the time blocking the sanctioned TXs as the effort to block is far more expensive than allowing them”. That is true, and this is where it comes down to what wager you are making.

   Does that .78 cent reward maybe once a year, given the strict liability and overall legal grey area right now until this is settled, outweigh the risk? For VeriHash that is a hard no regardless of the position the DAO or ethereum community at large takes and at least on the “profitability” face of it .78 cents is a rounding error given other factors.

   If the DAO really wants that .78 cents a year I will gladly throw that amount of ETH into the MEV sharing contract once a year and call it done. My goal isn’t to widthold earnings from stakers it is to ensure stability of operations and remove variables out of the equation which in the longer term fundementally results in more consistent returns for stakers.

   If the ethereuem community at large wants to social fork and slash censoring operators I guess that is ethereum’s ethos showing its will and choosing the nuclear option. Such an action would destroy my buisness and livelihood but at least I know where I will stand and can move on to other ventures to apply my skills while I watch ethereum eat itself and likely die from such a choice.

   Not censoring TXs is still likely only theoretically more profitable while the real world likely begs to differ which makes things more philisophical I think. This is fine, but it isn’t something I am going to bet my business on. I am thankful the proposal doesn’t ask me to either.

10. I still hold firm that US persons participating in pools as stakers need to be aware of their risks and judge it for themselves. This isn’t fear mongering this is just accepting the fact that “sanctioned property” in the pool likely taints it for all US persons at least to a degree.

    That degree of contagion and if it brings action to individuals in my mind, again with no real tested legal framework around it beyond “opinions” at the moment, is the biggest thing each US person gets to reckon with that participates in an unrestricted pool.

    I have staked in the pool here personally, and will continue to do so because I am willing to make the bet the OFAC is more interested in in fiat off-ramps (exchanges). But that doesn’t remove the logical arguement I don’t think. It just makes a bet on how far the argument will be taken for which I have no real control over.

    Each US person particiapting should know what bet they are making and that they are comfortable with that bet and not trying to hide behind ethos, or opinions unless they are willing to test those and establish those legally.

    I would love to get a “coalition of the willing” together and fund an effort to seriously establish legal precedent for protecting the ethos of etheruem in the sizable US market. Some are doing this already but more help, money, and time are needed if it is to be won.

    Communities like stakewise can significantly help such goals with support in various forms as well if they so choose.

11. Flashbots MEV-BOOST in my opinion will likely lead to further centralization and control over block contents. And our worries about node operators censoring things is like TXs overwrought given that once everyone just “uses flashbots” and the normal TX pool dries up there wont be a choice. I understand there are plans to push more decentralization within the MEV-BOOST ecosystem with more relays and builders and all that.

    That all sounds great, but I honestly think many in the community are forgetting the power of first mover advantage and what that means to market dominance. Let alone what being a second mover in a market while making it easier for users to use your product can do the that first mover (I am looking at you Zune vs IPod).

    I want to eat my hat on this but my bet is that we are going to be talking about the “problem with block builder/MEV-BOOST centrallzation” this time next year. That all being said, I love money so eff-yeah we are running MEV-BOOST or whatever we need to increase profits.

    As a business that is my #1 goal, and to that end we intend on supporting and running MEV-BOOST post merge because I also love money and that comes with stabilitity. I don’t think it wise to introduce too many variables to a once-in-a-lifetime event that has seen emergency patching of software to fix issues at the 11:59:59th hour. But you can bet the farm on use running MEV-BOOST shortly after merge proves to be stable.

    Oh and 100% on pushing EL rewards back to the pool, I mean it is not my eth it is the stakers that ultimately allow for me to propose blocks and collect those rewards to begin with. They deserve the bulk of the rewards (minus my fee for the effort to make it happen which is still just as important)

12. Last thing and I then will promise to STFU. The fact that stakewise has deployed a pool for insitutional staking that does support AML/KYC/whitelisting addresses serves only to further to prove the point that it can be done and isn’t a technial limitation. Instead it is a choice being exercised by the controlling parties of the main pool NOT to implement such controls.

    This puts the pool at least risk (at least for US persons) in my mind because this is exactly what sanctions are meant to curb; behaviors and to influence the controlling entity’s “deemed as harmful” choices.

    Disagree, agree, abstain but the fact is if OFAC decided to go after pools in the same way it went after tornado cash (until legal arguments are won and established that you can’t sanction non-sentient code) the DAO may consider what it might mean if it lost a majority of its US participants.

    Again, not fear mongering simply asking for a thought exercise.

    We do this all the time in the infra world. We call them DR exercises. We table top them and sometimes legit do full blown failovers to new DCs to prove our plan works.

    So what is the DAO’s plan if it decides not to comply with OFAC sanctions, is subsequently targeted by OFAC/“tornado cashed”, and that effetively cuts most US Persons out of partcipating the pool beyond “the rebels”. And everyone likes to be an armchair rebel until things start impacting their real world lives.

    I am curious what that DR/business continuity plan of the DAO looks like as US person holding SWISE and staking GNO and ETH.