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.

‍