An update on MEV - Catching a Bad Validator

tldr;

In order to discourage MEV extraction, Skip Protocol developed a dashboard that highlights the amount of MEV each validator potentially has extracted. Make sure to check it out before delegating!
The research team at dYdX Trading Inc. (”dYdX Trading”) deployed a “bad validator” on the public testnet that sandwiched all eligible orders when acting as a block proposer.
The dashboard reveals the dishonest behavior of the “bad validator”, represented by the green line in the screenshots below.
dYdX Trading is dedicated to building open-source mechanisms and protocol level designs to deter MEV extraction.

How to discourage MEV which harms users: Skip Protocol’s dashboard

MEV extraction is unacceptable because it undermines a fair and transparent trading environment. In our previous blog post, we discussed how validators can extract Maximal Extractable Value (MEV) on the dYdX Chain because orders are stored in an in-memory orderbook before being executed. MEV refers to the profit a dishonest validator can gain by censoring and/or re-ordering orders and cancellations to their advantage. Validators reordering and censoring transactions for profit adversely impact traders: orders could be executed at worse prices relative to the best price possible, and cancellations may be ignored.

To discourage harmful validator behavior, dYdX Trading has collaborated with Skip Protocol to develop a public dashboard that shows how much MEV each validator may be extracting. The amount of MEV extracted is estimated by comparing the orderbooks of the block proposing validator and honest nodes. Using this data, the applicable community can take actions to discourage and penalize bad actors if necessary. Furthermore, delegators may use the dashboard when making delegation decisions to understand which validators are matching orders honestly and providing a fair trading experience for end users of the open-source software.

Spot the bad validator

During the public testnet, the dYdX Trading research team deployed a “bad validator” that ran a simple sandwiching strategy: whenever this validator had the chance to propose a block, it manipulated the orders to take maximum advantage of the limit price for its profit. With the green line representing the bad validator’s cumulative orderbook discrepancy, the dashboard exposed the dishonest behavior. These values are an order of magnitude higher than those of other validators, who are likely to be honest.

However, it's important to note that a non-zero orderbook discrepancy would not always indicate dishonest behavior. Depending on how validators are connected to other validators, factors such as network latency could cause minor discrepancies in the different validators’ orderbooks. To balance this out, we normalize the discrepancy metric by the trading volume.

Since honest validators will likely have non-zero orderbook discrepancy, determining whether a validator is extracting MEV is an art rather than science. Instead of focusing on rare, isolated incidents, we encourage the applicable community to observe validators' behavior over time and in comparison to others. This will help distinguish between intentional manipulation and expected discrepancies caused by network fluctuations.

What’s next?

In our next dashboard update, we're taking a significant step forward in addressing the effects of network noise. By utilizing nodes that measure orderbook discrepancy among each other, the tools should detect and reflect MEV more robustly. We'll delve deeper into this methodology in a future post. In addition to fostering transparency and trust in the product, we will continue exploring protocol-level designs to deter MEV. In particular, we are excited about leveraging ideas like Vote Extensions and Trusted Execution Environment to eliminate possibilities of MEV extraction at the protocol level.

Stay tuned for more updates on our progress and continued initiatives against MEV extraction.

Appendix

In order to highlight malicious practices, we designed the “orderbook discrepancy metric” to estimate the amount of extracted MEV. This metric captures the idea that dishonest validators manipulate the matches to profit certain accounts at the expense of others. Consequently, this behavior creates differences in the profit-and-loss (”PNL”) figures across accounts, which are not observed by honest validators. Let's explore this concept with an example.

Imagine there are two resting orders:

A: Sell 100 at $101

B: Buy 100 at $99

During the block,

C submits buy 100 at $102.

An honest validator would match A's sell order with C's buy order, with the final price being $101. Only A and C's accounts would be affected. However, a dishonest validator might insert their own orders to sell to C at $102 and buy from A at $101. This would unfairly give them a profit of $100, while C ends up paying a higher price than they should have.

For every block, nodes and other validators can track how different the block proposer's matched trades are from what the rest of the network observed. Skip Protocol nodes gather data for the dashboard and our open-source software includes tools enabling anyone to calculate the metric and check the figures themselves. More information on the formal definition of the orderbook discrepancy metric and technical details of the approach will be covered in an upcoming whitepaper.

Calculation of the metric

The MEV metric for a given block for a market is defined as the following:

You can find more about this metric and calculations here.

Disclaimer and Terms

Although dYdX Trading Inc. has collaborated with Skip Protocol on certain solutions, the two companies are not affiliated in any way. dYdX Trading is not responsible for any action taken by third parties, or content set forth on any third-party websites, including any links posted for informational purposes that are linked in this blog post.

This post is subject to the dYdX Trading Terms of Use. The dYdX Trading interface and products are not available to persons or entities who reside in, are located in, are incorporated in, or have registered offices in the United States or Canada ("Blocked Persons"), or other Restricted Persons (as defined in the dYdX Trading Terms of Use). dYdX Trading products and services are not intended for, and should not be used by, Blocked Persons or Restricted Persons. Terms of Use specific to v4 software can be found here.

‍

Legitimacy and Disclaimer

Crypto-assets can be highly volatile and trading crypto-assets involves risk of loss, particularly when using leverage. Investment into crypto-assets may not be regulated and may not be adequate for retail investors. Do your own research and due diligence before engaging in any activity involving crypto-assets.

dYdX is a decentralised, disintermediated and permissionless protocol, and is not available in the U.S. or to U.S. persons as well as in other restricted jurisdictions. The dYdX Foundation does not operate or participate in the operation of any component of the dYdX Chain’s infrastructure.

The dYdX Foundation’s purpose is to support the current implementation and any future implementations of the dYdX protocol and to foster community-driven growth in the dYdX ecosystem.

The dYdX Chain software is open-source software to be used or implemented by any party in accordance with the applicable license. At no time should the dYdX Chain and/or its software or related components be deemed to be a product or service provided or made available in any way by the dYdX Foundation. Interactions with the dYdX Chain software or any implementation thereof are permissionless and disintermediated, subject to the terms of the applicable licenses and code. Users who interact with the dYdX Chain software (or any implementations thereof) will not be interacting with the dYdX Foundation in any way whatsoever. The dYdX Foundation does not make any representations, warranties or covenants in connection with the dYdX Chain software (or any implementations and/or components thereof), including (without limitation) with regard to their technical properties or performance, as well as their actual or potential usefulness or suitability for any particular purpose, and users agree to rely on the dYdX Chain software (or any implementations and/or components thereof) “AS IS, WHERE IS”.

Nothing in this post should be used or considered as legal, financial, tax, or any other advice, nor as an instruction or invitation to act by anyone. Users should conduct their own research and due diligence before making any decisions. The dYdX Foundation may alter or update any information in this post in the future at its sole discretion and assumes no obligation to publicly disclose any such change. This post is solely based on the information available to the dYdX Foundation at the time it was published and should only be read and taken into consideration at the time it was published and on the basis of the circumstances that surrounded it. The dYdX Foundation makes no guarantees of future performance and is under no obligation to undertake any of the activities contemplated herein.