Discussion: Protection Against MEV on dYdX v4

co-authored with @MylesOneil and @Derek

dYdX v4 will use an in-memory orderbook design that may allow block proposers to perform MEV. This malicious behavior would come at the expense of dYdX users and the protocol’s trading experience.

To protect users, we think it’s important to proactively mitigate opportunities to benefit from MEV of any kind. Social slashing is one way to accomplish this goal, which would involve punishing validators who engage in any malicious behavior.

Social slashing can be enabled through a method of reliably detecting MEV activity, combined with a governance-based approach to evaluate and punish bad actors. As described in prior blog posts, MEV activity on v4 can be detected through Skip’s orderbook discrepancy dashboard. Combined with a slashing review committee and the power of governance, the protocol can take a proactive stance against malicious MEV extraction.

In this post, we explain why MEV is a threat and what a potential solution might look like. The post should also serve as an invitation to discuss MEV on dYdX more broadly. Given that v4 is expected to launch in late September, we think it’s worthwhile to kick off discussions early and start gathering thoughts today. MEV is an important issue that will affect all dYdX stakeholders – we encourage you to share your thoughts.



First, a quick explanation of why MEV is a problem on dYdX v4. Through the in-memory orderbook design, validators have an opportunity to reorder or censor trades before proposing a new block to extract profits. These actions wouldn’t break anything in the consensus process; other validators would only see the final orderbooks and order fills. In other words, there is nothing within the protocol to prevent validators from engaging in order manipulation as a form of MEV. Given dYdX facilitates billions of dollars of trades daily, we can assume that validators stand to gain a lot of money from doing this, and users lose a lot on the other side.

Based on what we know, dYdX v4 is set to launch with no in-protocol solution for mitigating MEV. In this world, the protocol would be at risk of validators deploying MEV strategies that can pose a significant threat to the trading experience of dYdX users.

As an appchain, dYdX does have the ability to take a more proactive stance toward mitigating MEV. Unlike general purpose chains like Ethereum, Cosmos chains are dedicated to a single application, allowing them to be more opinionated on which behaviors to incentivize (and disincentivize), all enforced through on-chain governance. MEV is one area where app-chains can take a proactive stance, with Osmosis setting an example of a community signaling in support of MEV mitigation.

Social Slashing

In order to address the problem of MEV, the dYdX community can adopt a governance-enforced social slashing model to ‘disincentivize and punish bad actors’. In this model, the community can take retroactive action against infringing validators engaged in malicious MEV. Punishment could take shape in a few different ways: it could involve reputation based punishments (e.g. publicly highlighting negative actions by validators and encouraging undelegation), and/or a more direct approach of slashing a validator through governance.

The social slashing mechanism presents a credible threat to malicious validators by retroactively punishing undesired behavior. Profit earned from MEV is now clouded by potential losses from slashing and reputational damage. The validator has to think twice before trying any funny business.

Measuring MEV

How do we measure MEV and catch these bad actors?

Using the dashboard built by Skip, the community can look for orderbook discrepancy among active validators as an indication of malicious behavior. Skip measures discrepancies by deploying multiple nodes that construct orderbooks the same way block proposers do. When a block proposer submits the matching orders of an orderbook, Skip compares that orderbook against their own, which is constructed honestly based on all trading orders published. We can assume that any material divergence in orderbooks, once normalized for network jitter (which the dashboard accounts for), is a result of malicious MEV activity performed by the proposing validator.

All discrepancies are measured and assigned to the proposing validator on the dashboard. As these accumulate over the time, the community can identify offenders with above average orderbook discrepancy. A completely honest validator set should display little to no divergence on the dashboard.

To help test the dashboard, the dYdX Trading research team has been running a malicious validator on testnet. The validator employs a sandwiching strategy that manipulates orders to capture MEV. This is exactly the kind of behavior that we would want to catch and punish to protect the integrity of dYdX v4. The dashboard has successfully captured the behavior, with the malicious validator displaying noticeably higher discrepancy compared to other validators. Using this data, the community could take action on the validator by proactively recommending undelegation or potentially slashing their stake through governance.

However, as pointed out by the research team, some minor discrepancies could also appear due to validator latency or other networking issues. There could be false positives in the context of identifying malicious MEV. The community should be careful to review discrepancies such that honest validators are not mistakenly punished for these false positives. We also expect ongoing improvements to the dashboard to reduce such instances. Significant divergence should only ever occur in the event of active manipulation. Any honest validator, even those with occasional latency or networking issues, should not expect to rank highly on the dashboard.

Slashing Review Committee

How can the community efficiently enforce social slashing?

A slashing review committee, made up of qualified community members, can be assigned to proactively review the discrepancy data and recommend action based on their findings. We believe that a committee can accomplish two important goals:

  1. Pose a credible threat to malicious validators through proactive enforcement
  2. Protect honest validators from false positives

The community as a whole may not be able to catch malicious actors efficiently given coordination constraints. By delegating that responsibility to a committee, validators now know that a group of qualified individuals is actively monitoring their behavior for malicious intent. This introduces a threat of swift retroactive action to malicious actors.

Similarly, the community may be quick to pull out the pitchforks at any sign of discrepancy. However, some discrepancy could be the result of non malicious activity, like network latency or improper maintenance. The committee can be responsible for conducting in-depth assessments, both on-chain and off-chain, to determine the nature of a discrepancy. Based on these findings, the committee can put forward a recommendation for action, with the final decision ultimately up to governance.

With that in mind, we envision the committee adopting the following process:

  1. Review all discrepancy data on a regular cadence (e.g. weekly).

  2. If a noticeable discrepancy is found, the committee initiates a review process on the validator. The review will include:

  3. In-depth analysis of the orderbook data

  4. Off-chain inquiry on the validator, which if possible can involve engaging the validator directly to identify the source of discrepancy

  5. The committee will report to the community their findings and include a recommendation for action (or inaction). The severity of recommendations will vary based on their findings. In the early phase of implementation, we expect slashing to occur only in the event of egregious and repeated offenses. Proactively undelegating is the expected outcome for most early instances of discrepancy.

  6. If needed, the committee will submit a governance proposal based on their initial recommendation and overall consensus from community discussions.

A future version of social slashing may leverage historical discrepancy data to adopt a standard methodology for slashing conditions and severity tiers (e.g. 5% slash if 10bps divergence). If a validator meets certain thresholds for discrepancy, an automatic proposal can kick off to enforce retroactive action based on the severity. The committee could still play a role in catching false positives, veto-ing proposals within a given period of time to stop honest validators from being slashed. The goal is to gradually reduce the subjectivity of slashing standards.

For now, we think a manual approach through an appointed slashing committee accomplishes our goal of imposing a credible threat to bad actors. Naturally, the committee must consist of unbiased members of the community that gain nothing from slashing a validator.

Closing Thoughts

Implementing social slashing requires on-chain data gathering, off-chain coordination, and then governance action – all done retroactively to punish bad actors. While this is not the end game for MEV protection, it’s a big step in the direction of mitigating MEV on dYdX v4. We firmly believe that social slashing is the best option available to protect dYdX v4 from harmful MEV activity at launch.

The threat of being slashed, or of being shut out of the protocol, is a powerful deterrent to stop validators from thinking about MEV. Active validators will think twice before engaging in MEV, and delegators will be more careful in their delegation choices. Ultimately, the goal is to build an efficient, but credibly neutral threat to validator economics that puts into question any potential profit earned from malicious activity.


We’d love to hear the community’s feedback and thoughts on this post, but also MEV more broadly. Any community-based slashing mechanism should be done with feedback from all stakeholders, whether it’s users, tokenholders, validators, or market-makers.

Here are some open questions to kick off discussion:

  1. How do you feel about MEV on dYdX v4 overall?
  2. What do you think about a social / governance approach to mitigating MEV?
  3. How do validators feel about being at risk of slashing for MEV? Is it possible that we deter honest validators from participating on v4?
  4. Should we appoint a social slashing committee to review activity on behalf of the community?


MEV Blog Post #1: dYdX v4 and MEV
MEV Blog Post #2: An update on MEV - Catching a Bad Validator
Skip’s Order Book Discrepancy Dashboard: https://dydx.skip.money/
Chorus One’s MEV Research Report: MEV on the dYdX v4 chain
dYdX Technical Architecture: v4 Technical Architecture Overview - dYdX


Thanks for the post here Carl - very practical.

Re: the slashing committee, I still have some questions.

  1. Who do you have in mind to be on the committee? And how important do you think it is that they’re impartial / unbiased?
  2. What organizational structure do you have in mind for the committee? Should this be as formal as a Guernsey trust? Or should it be a lightweight gaggle of volunteers?

Hey guys! This is great! I’m thrilled to see a discussion going up about taking proactive action to combat MEV.

MEV harms traders by giving them suboptimal execution pricing. Many holders of the dYdX token are no doubt traders themselves, so this is something that should be a primary concern. However, even if you’re a dYdX tokenholder that doesn’t also participate in trading (maybe you’re an LP or a MM or just a passive investor), this should still be a concern. Suboptimal execution pricing drives away traders, especially advanced traders or trading bots that drive a lot of volume to dYdX. This harms the protocol overall. MEV is something we should be actively seeking to fight against.

Currently, this social slashing mechanism seems to be the best option to ensure validators aren’t incentivized to misbehave, but we should be careful to place significant limitations on this power. For example:

Enshrined Governance Agreements
Assuming governance’s power to slash validators is parameterized in a proposal, there’s no real way to stop someone from putting up a proposal to slash a validator that they don’t like, or even for bad behavior that isn’t related to MEV. It’s a slippery slope because if the power is there, people will be encouraged to use it.

An example of this might be if a validator sets a low commission to draw in delegations, and then hikes the commission to 100%. Another example might be a validator that falsely promises an airdrop to get delegations. Or maybe a validator issues a token for an unrelated project and rugs the project. All of these things are clearly reprehensible behavior, and we’d probably be tempted to socially slash validators for them. But overuse of this power is dangerous and harms delegators to that validator.

Given that, I think it makes sense to have governance ratify a proposal that sets forth the conditions under which social slashing is acceptable (and ideally that would be only for this explicit MEV-related purpose). That could be done as part of this proposal or as an independent proposal.

Strict Procedural Rules for the Committee

This is important in light of the rules re: slashing and undelegation / redelegation times for Cosmos chains, as well as for the time it takes for proposals to go through governance. I’ll give a brief background on these:

Cosmos chains have governance-adjustable parameters governing how long it takes to undelegate your tokens, or redelegate them to another validator. For example, for Osmosis this parameter is currently set to 14 days. During this time period, your tokens are still subject to slashing, but after these periods have concluded, your tokens will no longer be at risk of a slash on that validator.

Similarly, Cosmos chains have a governance-adjustable proposal voting time.

So the issue that arises here is what happens when a validator engages in MEV and too much time elapses between the MEV event and the slash event. If we wait too long, this gives sophisticated delegators (or even the validator’s own self-bonded stake) the opportunity to remove their at risk stake from the validator, whereas more passive delegators would be subject to the slash. This also gives sufficient time for much more stake to be delegated to the misbehaving validator. It doesn’t make a ton of sense to me to slash delegators that weren’t even delegated to the misbehaving validator at the time of the MEV event.

So imo we should ensure that the process by which MEV is caught, verified, proposed to governance, and executed is, in all cases, less than the applicable redelegation period. If that redelegation period is 14 days, for example, and the voting period is 7 days, the review/ratification period should be no more than 7 days (and that would be cutting it pretty close).

It would be helpful here to know what these proposed initial parameters are, but that’s probably worthy of a separate forum discussion :sweat_smile:


I know we’re probably a ways off from having tooling for this in place, but now that dYdX will be its own appchain, we should strongly consider funding and building on-chain DAO tooling to host committees and subdaos like this. This is something Id like to see DGP take up if possible!

Having these organizations be on chain as much as possible is a way to help ensure they remain accountable to dYdX governance (which in turn might allow for a loosening of strict requirements on things like impartiality which we might otherwise need).

Probably out of scope for this committee in particular but still something cool to think about as the v4 chain grows and develops.


It’s becoming increasingly clear that a well-thought-out platform designed specifically for hosting councils is not just a want, but a necessity. This situation with dYdX v4 is just another testament to the myriad of challenges the decentralized community faces. Electing members every six months, running everything via a transparent voting system, and ensuring autonomy and efficiency is essential to maintain trust and effectiveness in the system.

I’ve been vocal about the need for such a platform and will continue to emphasize its significance. From managing grants programs and ambassadors to handling marketing, governance, risk, and even specialized councils like the validator one mentioned, having a dedicated platform can streamline and optimize these processes.

I feel like the future of decentralized ecosystems lies in building structures like this that ensure accountability, efficiency, and transparency. In my opinion, we should prioritize researching, designing, and developing such a platform as soon as possible.

1 Like

Absolutely, it’s incredibly heartening to see others recognize the value and importance of on-chain DAO tooling, especially as dYdX evolves into its own appchain. I wholeheartedly agree and, honestly, wish this was an initiative we embarked upon months ago.

We’ve been championing this idea and discussing its implications for a while now, and it’s essential to align our visions and harness our collective strength. Our team is eager and prepared to contribute significantly to the design and development of such a platform. We have a wealth of ideas that, when executed right, can ensure the system stands as a paragon in the industry.


Thanks for kicking off this discussion. Disclaimer: my previous full-time employer and dYdX testnet validator Chorus One contributed to the research informing this post and potential mitigation strategies.

To me, it currently seems that a governance-based approach to deter validators engaging in MEV is a realistic/implementable direction to mitigate negative externalities arising from MEV which would be hurtful to the protocol and its success at large. By approving such a committee and process, the dYdX community can signal to its validators that engaging in MEV is not desired and issue a credible threat in the form of slashing.

Additionally, imo further investment into automated MEV mitigation methods are desirable, as outlined in the post to ultimately create a fully permission-less and credibly neutral trading platform. Furthermore, other measures could be instituted to socially deter validators from engaging in undesired MEV practices, such as e.g. validator onboarding/foundation delegation subject to agreeing to not engage in MEV.

In practice, I assume there will need to be significant effort expanded to provide evidence/analysis to accurately judge whether undesired manipulation has taken place. Skip’s dashboard is a great tool helping with that. But e.g. looking at it right now, we can see that other validators - aside from the dYdX Trading validator that is actively manipulating orders in order to test - are showing higher divergences of order books which are (I’m assuming) attributable to latency/other issues rather than them engaging in MEV on testnet.

Given that, it seems that it would require members of the committee themselves, or a designated, neutral third-party that has the technical expertise to provide such analysis and evidence.

That all being said, I do think this is the right path forward as proper mitigation of MEV is going to be crucial for a successful dYdX v4 protocol. I’m also in favor of funding/expanding Cosmos DAO governance tooling and using it to implement such a process on-chain on the dYdX appchain.


Thanks for initiating the discussion Carl!

Could someone familiar with the TestNet data comment on what happened in the 200-300 Past Proposed Blocks range that led all validator discrepancy scores to spike (except for dydx-research)?

Would be good to clarify that, outside from this sudden/massive spike, the dashboard seems to accurately identify the malicious validator.


Thanks, @tncintra i also observed same. If you check current Dashboard Klub staking is at 880 BPS whereas someone on lower side is at 300 bps divergence, this is around 3times just based on network latency. It would be great if skip can open source the code which checks for discrepancy? Community members can give them feedback on same.


So this is a very interesting topic, I think that it’s possible that they’re higher than average discrepancy could indicate that their latency on the network is higher than it should be. Which means that I’m going to need to discuss another factor.

The producer of a block is known before that block is produced and if I were a really really crazy attacker and I really really hate it just one validator I might try to introduce transactions that slow the chain just for that validators blocks. Now I’m not 100% sure that that would set off this dashboard but as soon as the new test network is up, or maybe it already is up, I’m not 100% sure, then I will very gladly run tests for this and see if it affects the dashboard.

I’m aligned with @RoboMcGobo here though:

MEV is bad. It’s kinda… Fundamentally dishonest and validators who do MEV are not valid. They are bad validators. At least according to the rules of cosmos. The rules of Ethereum are very different and in cosmos we choose rules that are specific to each network.

I might try to do stuff like artificially increase the latency to notional validator or maybe to some other validator that I set up on the testnet, just to avoid tainting our scores, to try to figure out ways to trigger this dashboard without actually performing MEV. Another thing that it probably makes sense to do is trying to independently reproduce stuff that does trigger the dashboard. This would involve a journey through the stack with skip, but I really like taking journeys through the stack with Skip. They’re a great team to go on journeys with.

This issue:

…which never, ever should have been released and calls the ICFormal security apparatus into play, was reported as a result of a journey with Skip as well.

Anyhow, I think this is a really good proposal and that we should do it and probably the biggest thing that we should be afraid of is false positives.

Actually just one other thing that we should be concerned with is not only false positives but also centralization risk. What is being described as jitter, is produced by having validator nodes at the edge of the network. So this dashboard may very well encourage centralization of the network. I’m definitely happy to work alongside Skip to try to make sure then validators at the edge of the network are not harmed by this design. I have a lot of experience with validation from the edge of the network, because notional runs the vast majority of our validators at our office in Hanoi, Vietnam.

Anyhow, I hope that these are helpful comments and look forward to checking this out live!


First and foremost, thank you for initiating this discussion and proposing a potential solution for MEV protection for dYdX v4!

We at Everstake do acknowledge the importance of taking measures to mitigate any form of MEV to safeguard dYdX users and ensure a smooth trading experience. While the social slashing mechanism offers an effective approach to mitigate MEV risks and penalize malicious actors, we believe that careful consideration of its components and execution process is crucial to avoid unjustly penalizing honest participants.
Several aspects to be further discussed:

  • Which community members will form the slashing review committee? The inclusion of highly qualified and unbiased individuals is of utmost importance.
  • Will all committee recommendations for action be subject to community governance, or does the committee reserve the right to make decisions independently?
  • It was mentioned that some ongoing dashboard improvements are expected to reduce instances of honest validators being mistakenly punished for false positives that might occur due to validator latency or other networking issues. Have any suggestions been made for dashboard improvements?
  • Who will have voting rights to participate in governance (validators, validators & tokenholders, all dYdX stakeholders)?
  • What is the proposed time frame for the discrepancy review process and community governance decisions?