# MEV Committee - Validator Guidelines **URL:** \ **Category:** dYdX Chain\ **Created:** [March 19, 2024, 5:23pm UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481 "2024-03-19T17:23:52Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![mev\_council](https://dub1.discourse-cdn.com/flex013/user_avatar/dydx.forum/mev_council/32/1225_2.png) [@mev\_council](https://dydx.forum/u/mev_council)\ **Post date:** [March 19, 2024, 5:23pm UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/1 "2024-03-19T17:23:52Z")
## Background The MEV committee is a grants-funded initiative to help the community enforce a social mitigation [strategy](https://dydx.forum/t/dydx-v4-social-mitigation-strategy-for-mev/1377) against malicious block proposers. The committee proactively monitors, analyzes, and reports on MEV activity on dYdX v4, so that the community can respond appropriately to malicious actors. In the previous [report](https://dydx.forum/t/mev-committee-january-report/2276), we described our process for investigating positive MEV events and highlighted issues with a specific validator. In our investigation, we found the issues to be a result of the validator configuration. To help mitigate similar issues with other validators, the committee has put together a guideline for improving non-malicious performance issues, which could help with discrepancies. In this report, we’ll walk through the guideline and share a quick update on the past month. ## Guidelines For Improving Validator Performance The full configuration guideline has been published [here](https://docs.google.com/document/d/e/2PACX-1vRgwm-fA9bFzxXNJrVUBP22siSvIrD1_e9hZOmFZepA-kN7CkeD3FweKB1SRFm8hu2sD77nDX2T7Xy5/pub). We hope to find a more permanent home for this reference among the formal validator documentation in the near future. For now, we’ll share a summarized version below with the goal of highlighting our key areas of improvement. ### Purpose This guideline is intended to help validators review their configurations so as to improve their overall performance. Validators experiencing issues with high discrepancies as reported by Skip’s [dashboard](https://dydx.skip.money/) should use the below as a reference for areas of potential improvement. If all else fails, validators can contact the council directly for help and discuss next steps. For reference, [here](https://dydx.forum/t/mev-committee-january-report/2276) is an example of what can go wrong for validators when deviating from standard configurations. The validator followed the guidelines below to improve their overall performance and reduce discrepancies. ### Summary Here’s a summary of our recommendations in a digestible set of steps that a validator may refer back to should they experience any issues. | Category | Parameter | Configuration | | --- | --- | --- | | Hardware | CPUs | \>= 8-core | | | Memory | \>= 128 GB RAM | | | Storage | \>= 1 TB NVMe SSD | | | Location | Tokyo, Japan | | Node (config.toml) | Version | version = “v1” | | | Transaction Timeout | ttl\_num\_blocks = 20 | | | Mempool Size | size = 50000 | | | Cache Size | cache\_size = 20000 | | Signing and Architecture | Signing | Local (not Remote or Threshold) | | | Architecture | Standard (not Sentry) | | Monitoring | MEV Telemetry | –mev-telemetry-enabled=true | | | Contact the MEV Council | [https://twitter.com/say\_no\_to\_mev](https://twitter.com/say_no_to_mev) | ### Configurations The guideline highlights a few important areas of consideration for a validator wanting to improve their setup and/or mitigate high discrepancy data. Below, we share quick summaries of each area. **1. Hardware** For any validator experiencing issues with latency and/or discrepancies, we recommend increasing to at least the following: - 16-core - 128 GB RAM - 1 to 2 TB NVMe SSD **2. Location** A validator not already in Japan experiencing issues should migrate their node to a server in Tokyo. If a validator doesn’t want to migrate their node to Japan, they could consider adding a, or multiple, Japan based peer(s) to their persistent\_peers configuration, allowing for more consistent access to the regional gossip network. However, this may not be enough to resolve latency issues, and could lead to other issues commonly encountered with persistent peers (e.g. downtime from lost connections). **3. Node Configuration** Overall, we recommend using all the default configurations for dYdX found [here](https://github.com/dydxprotocol/v4-chain/blob/v0.2.0-rc1/protocol/cmd/dydxprotocold/cmd/config.go). The important parameters to keep in mind include: - Version = “v1” - Ttl-num-blocks = 20 - Size (mempool) = 50000 - Cache\_size = 20000 **4. Signing and Architecture** A validator running their node through sentry or threshold/remote signing methods that is also experiencing latency should redeploy to a standard validator node. Sentries in particular are known to add latency. Given block times are under a second on dYdX Chain, we expect validators with complex signing and architecture to fall behind. **5. Monitoring and Outreach** - The dYdX Chain [includes](https://github.com/dydxprotocol/v4-chain/blob/v0.2.0-rc1/protocol/x/clob/keeper/mev.go) logs and telemetry services that track MEV activity and orderbook discrepancies per block. Validators experiencing issues may want to consider enabling these additional logs by including the flag ‘–mev-telemetry-enabled=true’ to review their block activity and identify issues with their order matching execution. The logs provide additional color on the discrepancies, which may help identify issues with their configuration. - The MEV Council, appointed by the community to help monitor and analyze discrepancies among active validators, is also here to help validators struggling with high discrepancies. We encourage all validators to reach out if they would like to discuss their setups and explore methods of resolving performance related issues. You can reach out to us through our Twitter profile here: [https://twitter.com/say\_no\_to\_mev](https://twitter.com/say_no_to_mev) ## What’s happened on-chain? In the past month, we haven’t found any significant events of MEV activity or trends among the active validator set. The validator previously experiencing issues, P2P, improved drastically following adjustments to their configuration. Volatility in the market and high trading volumes have led to occasional spikes in discrepancy data. This can be expected however, and is mostly attributed to deleveraging and liquidation events triggered locally when a validator proposes a new block during large price swings. We hope to find new methods of isolating these events to identify any malicious activity potentially hiding within volatile periods, but for now find no reason to be concerned with the activity seen. ## What’s next? We are working on ways to improve our analysis in a more automated manner through open source libraries, such that any community member could perform their own investigation. In the meantime, we’ll continue monitoring on-chain activity and investigate findings as needed. ---
**Author:** ![LeonoorsCryptoman](https://dub1.discourse-cdn.com/flex013/user_avatar/dydx.forum/leonoorscryptoman/32/806_2.png) [@LeonoorsCryptoman](https://dydx.forum/u/LeonoorsCryptoman)\ **Post date:** [March 20, 2024, 3:30pm UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/2 "2024-03-20T15:30:40Z")
> [@mev\_council](#): > > A validator not already in Japan experiencing issues should migrate their node to a server in Tokyo. Although I can understand that latency is greatly reduced when validators are close together geographically, is that not also immediately introducing a risk with respect to potential outages? In my opinion decentralisation needs to happen with respect to voting power (spreading out over the validator set), validators (various validators with proper income over the ecosystem), service providers (hosted/bare metal, where hosted needs to be with various providers) and geographical (all continents preferably). ---
**Author:** ![derfk](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@derfk](https://dydx.forum/u/derfk)\ **Post date:** [April 22, 2024, 11:46am UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/3 "2024-04-22T11:46:24Z")
Hi, MEV dashboard is looking pretty spicy recently. @mev_council what is happening? [https://dydx.skip.money/](https://dydx.skip.money/) ---
**Author:** ![Nascor](https://avatars.discourse-cdn.com/v4/letter/n/ba9def/32.png) [@Nascor](https://dydx.forum/u/Nascor)\ **Post date:** [April 23, 2024, 6:49am UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/4 "2024-04-23T06:49:32Z")
it does look horrible. I think this should be proactively addressed by the MEV council, and not wait until the community brings up such discrepancies ---
**Author:** ![CroationCryptoCraze](https://avatars.discourse-cdn.com/v4/letter/c/d07c76/32.png) [@CroationCryptoCraze](https://dydx.forum/u/CroationCryptoCraze)\ **Post date:** [May 1, 2024, 1:07pm UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/5 "2024-05-01T13:07:55Z")
Currently, the MEV dashboard does not load for me, but from what I see in the table, it looks even worse than it did one week ago. Where is the MEV committee? How long can validators engage in MEV before they get slashed? Maybe we should reconsider the committee’s budget. ---
**Author:** ![RealVovochka](https://dub1.discourse-cdn.com/flex013/user_avatar/dydx.forum/realvovochka/32/2646_2.png) [@RealVovochka](https://dydx.forum/u/RealVovochka)\ **Post date:** [June 28, 2024, 8:48pm UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/6 "2024-06-28T20:48:22Z")
How is it going MEV committee? Can we see a final report after 6 month of activity? ---
**Author:** ![RealVovochka](https://dub1.discourse-cdn.com/flex013/user_avatar/dydx.forum/realvovochka/32/2646_2.png) [@RealVovochka](https://dydx.forum/u/RealVovochka)\ **Post date:** [July 6, 2024, 11:36am UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/7 "2024-07-06T11:36:50Z")
![CleanShot 2024-07-06 at 13.35.31@2x](https://europe1.discourse-cdn.com/flex013/uploads/dydx/original/2X/c/c18b7fe4407920a9ef3de98d29a726477f60a5ad.png) @mev_council what going on? is it hard to reply in one week? ---
**Author:** ![carlbergman](https://dub1.discourse-cdn.com/flex013/user_avatar/dydx.forum/carlbergman/32/43_2.png) [@carlbergman](https://dydx.forum/u/carlbergman)\ **Post date:** [July 8, 2024, 3:26am UTC](https://dydx.forum/t/mev-committee-validator-guidelines/2481/8 "2024-07-08T03:26:53Z")
Hey @RealVovochka, we’re in the process of restructuring the committee and migrating the dashboard for better accessibility. We’ll be sharing a larger update on work completed and future plans soon.