Background
The MEV Committee is a grants-funded initiative to help the community enforce a social mitigation strategy against malicious block proposers. The committee was assigned to actively monitor, analyze, and report any potential MEV activity, so that the community may respond appropriately to bad actors.
Monthly reports are shared with the community, offering insights into our on-chain findings, actions taken to address any issues, and improvements to our workflows. In case of malicious activity, these reports also detail the incident, the parties involved, and provide recommendations for any retroactive measures the community should consider. We welcome any feedback or questions on the report!
January Activity
In January, we found a decrease in orderbook discrepancies compared to previous months. The trends we previously identified in late 2024 did not appear throughout January, including concerns with empty blocks. While some validators continue to show above-average empty block percentages, our analysis does not indicate any alarming trends. Similarly, our examination of per-block orderbook discrepancies over an extended timeframe reveals no significant trends.
As always, the committee has been in touch with validators, digging through configurations and setups to better understand the problems identified.
Empty Blocks
The issue of empty blocks, which involves validators proposing blocks with no matched orders, has mostly normalized compared to what was identified in previous months. While some validators do occasionally propose higher rates, we find that over time validators now all behave in similar manners with regards to empty blocks. This suggests the issue may relate to the network, not the performance of any individual validators. Our data can be found through our dashboard here: https://dydxdashboard.streamlit.app/
High Discrepancy Blocks
In January, we identified one block with noticeably above-average orderbook discrepancy that warrants further analysis. Block 35250829, proposed by Nodeplus on January 18th, showed orderbook discrepancies exceeding $100k in value. Below, we share a summary of the cause and effect this discrepancy had for users.
This block was proposed on a day with exceedingly high market volatility, specifically with regards to Solana and Solana-based markets. Two resting stop loss orders were triggered with the block, both with limit buy prices of $256.20 and a trigger price of $244. One order was a buy of 12,136 SOL and the other for 3,802 SOL, amounting to over $4M in notional value. For starters, the notional amounts are quite high for individual orders, which can cause slippage and discrepancies as validators try their best to match against all orders available. We see that the first order was executed at a worse price than the second. That order was matched at an average of $253, while the oracle and offer stood near $244.
The discrepancy patterns observed between our node and Observatory’s dashboard suggest significant last-minute order activity. Several orders appear in the Numia mempool table with post-block proposal timestamps, indicating potential latency issues in order propagation across nodes. Additional data and a more comprehensive review of the block can be found here: (35250829-nodeplus - Google Sheets)
Given the circumstances involving market activity and order sizes, we think it reasonable to assume the discrepancies originate from poor order propagation across the network. It’s possible Nodeplus had a clogged mempool, or was not peered well enough to receive new orders in time.
When examining trending averages for orderbook discrepancies across validators, we observed a notable spike in Nodeplus’s metrics over several days. Given their position as 52nd in voting power, their lower block proposal frequency results in greater sensitivity to significant discrepancy events, as evidenced by this particular block. Beyond this individual event, we find no other concerning trends.
Future outlook
Following successful script testing, the committee has implemented automated processes for detecting orderbook discrepancies at the subaccount level, limiting the need for individual block analysis to particularly high discrepancy blocks as the one mentioned in this dashboard. We plan to conduct statistical analysis of these findings and will share any significant patterns with the community.
Finally, the committee will continue refining its ability to detect discrepancies, engage with validators, and develop new metrics to uncover underlying issues. Feedback and collaboration from the community are very welcome as we continue improving our research and analysis of on-chain activity.