dYdX v4 Social Mitigation Strategy for MEV

Proposals
1

Summary

  • 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.
  • With no in-protocol solution available, we propose adopting a social slashing strategy to mitigate MEV. The strategy will leverage Skip’s dashboard to monitor on-chain behavior and catch bad actors.
  • The proposal includes appointing a committee to proactively review data and put forward recommendations. The committee will act on behalf of the community to pose a credible threat, but final decisions are still presented through governance.
  • By end of term, the committee will present a framework for standardizing retroactive action based on data gathered.

Background

dYdX v4 is set to launch with no in-protocol solution for mitigating MEV. The protocol may be at risk of validators deploying MEV strategies that can pose a significant threat to the trading experience of dYdX users.

Through the in-memory orderbook design, validators will 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

As an appchain, dYdX does have the ability to take a more proactive out-of-protocol stance toward mitigating MEV. The community can be opinionated on which behaviors to incentivize (and disincentivize), all enforced through on-chain governance.

Description

We propose that the community adopt a governance-enforced social slashing model to disincentivize MEV activity. In this model, the community can take retroactive action against validators engaged in malicious MEV. This presents a credible threat to validators and their delegators. Profit earned from MEV is now clouded by potential losses from slashing and reputational damage. The validator has to think twice before engaging in MEV, and delegators have to think carefully about where they delegate their tokens.

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. These nodes ‘determine whether the block proposer has extracted MEV by comparing the observed value to the expected level’. It does so while correcting for networking and latency issues, or noise, improving the likelihood that any discrepancy measured is the result of dishonest behavior.

The dollar value of discrepancy found is measured and assigned to the proposing validator on the dashboard. As these accumulate over the time, the community can identify offenders with above average discrepancy. Similarly, spikes in discrepancy may indicate valuable one-off MEV opportunities being captured by validators. A completely honest validator set should display little to no divergence on the dashboard.

The community as a whole may not be able to catch malicious actors efficiently given coordination constraints. Instead, we propose assigning that responsibility to a committee made up of qualified community members. This committee will be responsible for proactively investigating and reviewing the discrepancy data and recommending actions 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

An active committee introduces a credible threat of swift retroactive action to malicious actors. It also allows for honest validators with potentially false positive data to avoid undeserving punishment. The committee will conduct in-depth assessments, both on-chain and off-chain, to determine the nature and severity of a discrepancy. Based on these findings, it will put forward a recommendation for action (or no action), with the final decision ultimately up to governance through a proposal.

Implementing a framework for action today is tricky given the lack of genuine network activity and trading on dYdX v4. There is no incentive for testnet validators to test out malicious behavior. As mainnet activity becomes better understood, and data is gathered, the committee can leverage their analysis to present a more formal framework for responding to discrepancies. The goal is to gradually minimize the dependency on one-off recommendations by adopting a standard for retroactive action. The committee can learn from the initial launch data and develop a framework that makes sense, which would be adopted through a separate governance vote. Instead of proactively reviewing, the committee can then shift to veto governance – vetoing actions on false positives or questionable discrepancies to protect honest actors.

Ultimately, it’s important to remember that the community will have full control over any retroactive action taken against its validator set. The committee is assigned to improve the effectiveness of data analysis and monitoring. It will act as a relay for recommended action, which may or may not be implemented by the community based governance.

Specification

The MEV Slashing Committee

Members: 7 individuals

Term: 6 months

Budget: $84,000 ($2,000 / month Member)

Responsibilities:

  • Recurring review meetings to discuss MEV activity (starting with weekly)
  • Proactively reviewing discrepancy data for outliers and possible MEV activity
  • Making periodic recommendations for community action based on findings
  • Publishing reports on findings and overall network observations
  • By the end of term, the committee should bring forward a framework for standardizing certain actions based on discrepancy data. This framework will be voted on by the community through governance.

This project will launch with the understanding that the committee’s exact scope of work will depend on mainnet activity. The exact workload could range from weekly meetings with no further requirements (e.g. there is no MEV activity observed), to a large amount of research, investigations, and governance activity (e.g. MEV is actively observed on mainnet). This uncertainty should not prevent us from moving forward – the downside risk of MEV activity is too large to leave unchecked. A lack of MEV activity found could also be the result of a successful strategy mitigating malicious actors from engaging in the first place.

Members

The committee members will play a big role in the credibility of this strategy. It’s important that all stakeholders feel comfortable with its members, including our validators. Validators will be subject to action recommended by this committee with potentially long lasting consequences. We must guarantee that only in the event of malicious activity should validators feel threatened by the presence of this committee.

We believe the following qualifications present an ideal member:

1. Reputation
Members should have some existing reputation at stake, similar to that of our validators. Reputable members are more likely to act honestly and thoughtfully in their decisions. Assuming at least one member is honest with a reputation at risk, the committee’s integrity should be upheld. Bribes from malicious validators, or other dishonest behavior, would be mitigated.

2. Knowledge of MEV
Members should have a good understanding of MEV and its role in the ecosystem. By understanding MEV and the strategies employed by actors, members will be better prepared to accurately assess the data. We can expect better recommendations from a knowledgeable committee.

3. Conflict-free
No member should have a pre-existing conflict with a validator or other relevant stakeholder. A member should not have any reason to provide favorable treatment to an active validator. Similarly, there should be no incentive to take action against a validator. We must guarantee a credibly neutral committee that has nothing to gain beyond benefiting the dYdX protocol with honest behavior.

With that in mind, we propose assigning the following members for this initial term:

  • Thomas Cintra (Xenophon Labs)
    Thomas has been publishing quantitative research for dYdX since early 2022 while working at Xenophon Labs. In this time, Xenophon’s research on dYdX v3’s Trading Rewards, LP Rewards, and Safety Staking modules have all led to successful governance proposals. On dYdX v4, we’ve been diving into solutions to mitigate MEV via TEEs and tuning rewards parameters to minimize the profitability of wash trading.

  • Udit Vera (Timewave Labs)
    Udit Vira is a co-founder at Timewave, a team specializing in developing tools for DAO cooperation, resource allocation, and MEV and governance supply chains. He is also a member of Hypha Coop, focusing on testing, go-to-market strategies, and operational aspects for Replicated Security within the Cosmos Hub.

  • Apriori (Heliax / Anoma)
    Apriori works with Heliax on Anoma. You can find some of their contributions here. They have written extensively on MEV and related topics.

  • Nitesh Nath (DFlow Protocol)
    Nitesh is the founder of DFlow, a decentralized protocol built with the Cosmos SDK that helps wallets maximize revenue, deliver better prices, drive user growth with order flow auctions, and reabsorb the leakage of MEV for their users. Nitesh was previously a quantitative researcher working in high-frequency trading.

  • Michael Neuder (Ethereum Foundation)
    Mike joined the Ethereum Foundation research team in March to work on Proposer-Builder Separation. He has spent time understanding out-of-protocol solutions (mev-boost and its extensions) and has contributed to the in-protocol design space.

  • Craig Le Riche / “0xCLR” (Considered Finance)
    Craig has published multiple data driven research frameworks for dYdX, including increasing the maximum funding rate bound research which led to a successful governance proposal and a dashboard built using the risk parameter framework developed. Craig previously managed an OTC market making desk.

  • Reverie Reserves, LLC
    Reverie is an investment and advisory crypto firm, and active contributor to the dYdX protocol. Reverie has played a role in two dYdX subDAOs – Grants and Ops – and now serves as a Grantor for the Grants program. They have previously funded research and solutions for MEV on v4, helping pave the way for this social mitigation strategy.

Operational structure

We suggest leveraging the dYdX Grants program to issue compensation and monitor deliverables. Using grants to distribute funding lessens the operational overhead associated with additional multi-sigs, payment streams, and governance proposals. The program is equipped to distribute monthly payment based on milestones, and to hold the committee accountable for deliverables.

The Trustees can issue a grant for the full term and distribute monthly compensation to each Member appointed. Given Reverie’s involvement with the Grants program, we propose structuring Reverie’s compensation as a lump sum retroactive grant to be paid at term end. This allows Reverie to participate in the committee while avoiding a conflict of requesting periodic payments. Instead, the Trustees can decide independently at the end of term if Reverie has fulfilled its responsibility in the committee, separate from its work with grants.

Slashing Proposals

The Cosmos SDK does not inherently support governance proposals to slash validators. Through this proposal, the community is also signaling support for slashing proposals to be added to dYdX. The grants team could explore opportunities to add this functionality through a separate grant.

This change would be submitted through a pull request to the dYdX Chain codebase. Ultimately, adding support for slashing proposals would need to be approved through a separate dYdX Chain proposal to upgrade the protocol to a release that includes these changes.

The MEV Slashing Framework

Ideally, social slashing is implemented through a set of criteria defined using data from Skip’s dashboard. We could eliminate most of today’s subjective decision-making in retroactive actions by adopting rules that lay out the steps for community action – for example:

  • Public notice on a validator if a one-off MEV spike is identified
  • Undelegate from a validator if their average orderbook discrepancy is $X or more
  • Slash stake from a validator if their average orderbook discrepancy is $Y or more
  • Tombstone a validator if their average orderbook discrepancy is $Z or more

However, we first need to collect mainnet data to get a better understanding of the average metrics and MEV events on dYdX v4. The testnet data seen so far could be misleading, especially since we don’t expect any testnet validators to be malicious (no incentive to do so). Instead, we propose that the committee members develop a framework based on their findings throughout this first term. The framework would include guidelines for how the community should respond to given data, reducing the dependency on a committee for efficient action.

By the end of this term, the committee will share their findings for standardizing MEV data interpretation. Based on the findings, the committee may submit a formal framework, which the community can vote on to decide whether or not it should be used for future MEV slashing conditions.

Proposal

We propose that the dYdX community signal intent to socially govern malicious validators on dYdX v4. The community will elect a slashing committee to proactively review data and recommend community action, which is to be funded through the Grants program. By approving this proposal, the community would signal a willingness to vote on, and carry out, proposals for retroactive action recommended by the committee. The approval would also serve as community endorsement for the committee members outlined in this proposal. By the end of this initial committee term, we expect the community to vote on a more formal framework for standardizing retroactive actions against malicious validators.

With v4 approaching and recent upgrades to the dashboard completed, we think now is the right time to implement social slashing as an MEV mitigation strategy.

Frequently Asked Questions

1. Why can we not solve MEV directly within the protocol? Why do we need this socially-driven approach?
A formal, in-protocol solution will most likely require some changes to the consensus mechanism of the dYdX Chain. Both leading candidates for in-protocol solutions, Vote Extensions and Trusted Execution Environments, require changes to the way validators process orders and new blocks. As of today, the impact to the chain’s performance and trading experience from those changes outweigh the benefits of solving for MEV. We are actively working on improving these solutions through research and grants. Until then, a socially-driven approach can protect the protocol while maintaining the chain’s performance.

2. Why is a committee needed? Why can’t the community manage this process?
The approach is successful if a credible and efficient threat of punishment is present to deter malicious actors. The committee will actively review activity such that the community has enough time to respond with action before validators and stakers can unbond their tokens. Similarly, the committee’s collective reputation adds credibility to recommendations put forth. We can trust them to make careful decisions, knowing their reputations are at stake.

The community will have final say over recommendations through forum discussions and on-chain proposals.

3. What are the risks involved with this approach?
The are two main risks to a social mitigation strategy:

  • The solution doesn’t work (e.g. it’s too hard to manually catch MEV) and MEV happens on the dYdX Chain.
  • An honest validator is punished as a result of false positives.

Based on testnet, we expect this solution to work, but things may change on mainnet. We’ll need to collectively review the solution on an ongoing basis to determine its success in catching and punishing malicious actors.

Incorrectly punishing honest actors is by far the biggest risk. We must at all costs avoid damaging the reputation of a non-malicious validator, and prevent honest or unknowing stakers from being slashed for no reason. The committee’s role will be to carefully review the data, and only make recommendations when it’s absolutely clear that MEV activity is present.

4. Why is Skip not directly involved with the committee?
Skip will work closely with the committee to provide data and context on the findings, but remain a neutral service provider throughout the process. The committee will be equipped to make accurate recommendations, but also have the independence to cross-reference data through other means. The integrity of the committee is upheld by serving only to solve this problem for the community.

10 Likes
2

Is this the only data that Skip is providing? https://dydx.skip.money/

I think it is fine if we will proceed with a social slashing approach. Personally think that the validator set is actually incentivized to review the MEV data by itself, unless the complete validator set was compromised, in which case MEV would be the least of the issues.

Also assume Reverie has already approached all this people and assembled it beforehand, as is its way, but would counter that:

  1. There is no need for a 7-member committee.
  2. “Reverie” as an entity shouldn’t be part of it, I don’t recall they have any MEV experts, and it seems there hasn’t been anyone from the team assigned to this committee seat.
  3. If we go with the committee route, I believe a 3-person team is more than enough considering the amount of work that is needed. The MEV dashboard is a one-page site that can be analyzed in a minute.
  4. If there is a need to develop a framework, it would be better to have either an RFP or a grant given to a team to develop it, seems responsibilities aren’t clear in this proposal. A $12k payment per committee member might be more than its needed. Again, no clear responsibilities.
  5. You mention that Skip won’t be involved but Udit Vera as part of timeweave with Sam Hart (Skip head of product) who is co-founder of Timeweave.

My proposal would be:

Allow validators, analysts and the community to analyze the MEV data and make a proposal on a framework to counter MEV activity, if any. All of the proposed members here seemed extremely experienced and any one of them could propose a framework to solve this in 6 months after reviewing the data, if this is indeed something that needs to be solved. I’m against giving a 7-person team power to decide over what to share with the community and direct how governance should act.

I think Skip’s dashboard should be used by everyone to really maximize its value and it is extremely simple to review MEV and see if actions are needed (if any).

2 Likes
3

Since when Reverie became an expert in MEV? You have a clear conflict of interest doesn’t matter if it’s retroactive or not. Please, focus your efforts on the grantor’s work

Is this proposal that the community should vote on as off chain vote?
Or it’s a social temperature check on the forum?

@luisqa Skip is in Reverie’s portfolio on their website so they might be involved this way.

I absolutely agree that such a budget is overkill for the thing that might not be needed at all. I assume that validators are more than interested in reviewing MEV themselves. Risk/reward doing MEV is terrible for the validator

Have no idea why we need 7 people for that job

1 Like
4

Disagree here. Social consensus on a complex topic like MEV is simplified immensely with a dedicated committee that can make recommendations and provide supporting evidence for those recommendations. There are tons of instances in Cosmos history where we’ve relegated certain responsibilities to validators by default and they haven’t risen to the occasion. A few examples:

  • Auditing of code releases for upgrades (or in the case of Osmosis, Stargaze, and Kujira, permissioned cosmwasm application launches), which resulted in many bugs getting through on various chains and apps.
  • Failure by the Cosmos Hub to execute a social slash on two validators who equivocated on a consumer chain
  • Governance participation in general

I don’t think it’s fair or desirable to assign this responsibility to the validator set. I’d also be willing to bet that most validators don’t actually want this responsibility. That aside, and as I mentioned in another post, it’s important to execute on social slashing consequences quickly, or you risk punishing delegators that weren’t delegated to that validator at the time of the malicious event (in this case, the MEV event). The odds of this happening go way down without a dedicated committee in charge of making these recommendations.

It looks to me like the committee is as large as it is to address this concern. You want to have a larger number of people to keep each other accountable and ensure honesty and transparency in the process.

I’m wary of social slashing as a concept in general, but this issue is so important that I feel it’s worth it in this case. MEV has the potential to substantially impact trading volume and protocol revenue for the v4 chain. We shouldn’t leave enforcing rules aimed at preventing it to an uncoordinated valset with no specific mandate.

4 Likes
5

How is it so important? How many times has the issue surfaced? What data do you have to back up any of the claims?

I’m trying to understand how this specific team will operate with no structure, no real data so far and no actual evidence to back up the need for it right now.

2 Likes
6

Hi @RealVovochka, sharing some thoughts on your questions:

For context, we’ve spent quite a bit of time digging into MEV in a v4 context. dYdX Trading’s blog post on v4 MEV cited our research piece, and it’s a topic we’ve actively brainstormed with many stakeholders in dYdX, from validators to community members to core developers. We’ve funded numerous MEV focused grants, working closely with those recipients, and feel this proposal is the best option the protocol currently has to mitigate harmful MEV, at launch.

In terms of budget, we actually feel $84,000 is a reasonable price for the protocol to pay for MEV protection. MEV in v4 is something that can really damage the end user experience, and in a worst case, it’s something existential to the protocol’s ability to compete with alternatives like Binance or Coinbase. Addressing that risk should really be a top priority for dYdX governance, and we see $84,000 is a worthwhile investment.

So why does this committee need 7 people? Why can’t it just be 3 people or, even 1 person? The short answer is - resiliency. We want to minimize the risk of validator coercion and bribery, and having a larger number of qualified folks actively focused on this lessens it.

Finally, in terms of conflict - it is ultimately up to governance to approve the creation of this committee, and if it passes, it is ultimately up to Trustees whether Reverie is paid.

2 Likes
7

Appreciate the thoughts @luisqa – I’ll share some more color below.

Yep, orderbook discrepancy through Skip’s dashboard will be the primary source of data for this strategy

Why do we need a committee? Why can’t validators review themselves? And why can’t the community handle it as a group?

This strategy is only effective if an efficient threat is present to malicious validators. A validator can deploy their MEV strategy during a volatile trading period for high profitability and quickly unbond their tokens. There’s no guarantee the community will respond in time within the unbonding period, or that they’ll agree on the best course of action. The same applies for validators. A committee solves this problem by making it their job to actively review and catch MEV. Malicious validators, aware of the committee’s presence, may not even bother running their MEV strategy out of fear of being slashed.

Similarly, the strategy must present an unbiased case for action against bad actors. We can’t depend on competitive validators and anonymous commenters to always act in good faith. The committee adds unbiased credibility to recommended actions. By putting their reputations at stake, committee members will be more thoughtful in their recommendations, especially with regards to possible false positives.

Why do we need seven committee members?

The number of trusted members involved is important to protect the integrity of the committee and its actions. We felt a committee of three, for example, is more susceptible to bribery by malicious validators profiting from MEV. Seven members significantly reduces the opportunity to corrupt the committee, while still maintaining efficiency and affordability.

Why is Reverie involved? What about Udit/Skip?

Reverie has actively played a role in understanding MEV on v4, including funding the initial dashboard and research grants earlier this year. We’ve worked closely with those teams and stakeholders to shape this strategy. Our knowledge and contextual understanding of the problem makes us a good candidate here.

With regards to Timewave, yes, Udit and Sam work together, and Sam also works with Skip. We think this is great - Skip has been an essential contributor to dYdX’s MEV strategy overall, and Udit has a deep understanding of both MEV and Cosmos governance.

Why should this committee propose a framework?

The committee will be best positioned to suggest improvements for standardizing the policing of MEV activity. Having studied the data and activity throughout the term, we can safely assume the committee will have a good grasp on how to best manage malicious activity.

I did want to clarify that the framework is a by-product of the committee’s appointment. The primary goal for this proposal is not to eventually propose a framework. The goal is to stop malicious validators from engaging in MEV activity while we collectively learn from mainnet and figure out ways to standardize actions. It’s also worth noting that this committee’s existence does not preclude other contributions and initiatives around MEV. This is one attempt to solve the immediate issue of launching dYdX v4 with MEV protection.

3 Likes
8

In a previous post, @carlbergman mentioned dYdX trading tried running a malicious validator on testnet to test whether MEV could occur on the chain and whether the dashboard could catch it. Based on these tests, we know that MEV is certainly possible on dYdX.

Obviously, as the chain is not yet live there’s been no data on MEV on mainnet, but it would be naive to assume that MEV is possible and yet won’t be exploited. In the event that MEV is exploited by one or more malicious validators, due to the volume that flows through dYdX every day, it’s likely that far more value than the ask of this proposal will be extracted by searchers in a single day.

This group is not only there to catch these malicious actions and make recommendations on them, but also to act as a deterrent for potentially malicious validators. If people know that this process exists, they will be far less likely to engage in bad MEV practices. The value being asked for that peace of mind seems well worth it, imo.

4 Likes
9

Cipher Labs wishes to express its support for introducing an MEV committee as a proactive step to safeguard the integrity and user experience on dYdX v4. A dedicated body to monitor and address potential MEV exploitation will be instrumental in maintaining the platform’s reputation and trust.

However, we’d like to suggest a modification:

Committee Size and Composition:

While we recognize the rationale behind a seven-member committee for diversity and safeguarding against potential biases, starting with five dedicated and qualified members should be sufficient. A leaner committee can lead to more efficient decision-making and coordination.

Recommendations:

  • Focus on selecting suitable candidates with proven expertise and integrity, minimising the risk of collusion or corruption.

  • Ensure a geographical distribution of members across major trading time zones - Asian, European, and American. This would enable continuous monitoring and quicker response times, ensuring that potential MEV exploitation is addressed promptly regardless of when it occurs.

In conclusion, we’re optimistic about the potential benefits of an MEV committee and believe that it can effectively mitigate the risks associated with MEV on dYdX v4 with the right members and structure. We look forward to the eventual implementation of this strategy.

3 Likes
10

Hey @Derek and @carlbergman thank you for your replies.

I have the following question:

How much did that validator (dydx-research) earn from their shady MEV activity compared to the overall trading volume on the testnet? Just trying to understand how serious this MEV problem is and whether there’s any economic motivation for validators to engage in it, considering the risks to their reputation and potential slashing penalties.

2 Likes
11

We are going West, as the Bankless guys like to say.

Going from the nice safe v3 with the centralized matching engine like every other major exchange has, to this new decentralized paradigm, is putting us squarely in the middle of the Dark Forest now.

Selini has had concerns over MEV for over a year when this v4 was announced, and we have been working with the stakeholders to try to find solutions.

Unfortunately, while we have explored different paths, there has been no silver bullet, so to speak. So here we are now at the eve of launch, and we are facing an unknown strength villain. Rest assured the threat is large- if it is anything like trading on Mainnet Ethereum, both normal users as well as market makers that are acting vanilla will suffer greatly, as in a closed system all profits will be extracted away by MEV players and make the ecosystem drip out value too fast.

Given the size of the threat, we applaud the use of a large and well diversified committee that has been proposed and the budget is small compared to the threat we face here.

The reality is social slashing is not a true and tested method for avoiding MEV, but if the committee can establish credibility for punishment then maybe this experiment of v4 can proceed without too much disruption. We worry what will actually happen when someone pushes the boundaries too far and gets slashed, its not a light thing to consider- so good to have a large committee to deal with the pushback.

In general we at Selini are supportive of trying this Social Mitigation strategy- while we are definitely not sure it will work (depends on how well people are at hiding MEV from Skip, etc), we think its worth trying and we will learn and adapt hopefully from the results.

10 Likes
12

MEV can indeed be a problem, and it is possible that such a committee will help address this issue. However, this committee will only work with the data provided by skip. Correct me if I’m wrong, but there won’t be any other sources of data or methods for assessing MEV. If the committee were to use any other data sources, it would be helpful to hear about it, as it would resolve any budgetary concerns.

2 Likes
13

First some notes on the proposal in general before I get to some numbers on the potential impact of MEV (which I do agree is one of the most important metrics to look at here, as especially bad MEV (i.e. frontrunning/sandwiching) impact users directly).

I do think a social slashing approach through a committee with non-validator 3rd party experts is a sensible initial direction in the short to mid-term. This is not something that should be done by validators solely because of their underlying incentives. Validators stand to profit from participating in MEV themselves and might also profit from trying to impose slashing on their competitors. Without anyone explicitly being tasked to look at this data, things might fall through the cracks (undesirable outcome vs the cost implied) and it’s certainly unlikely that a framework for standardising would emerge. This is an important mid-term outcome that can lower the need for such a committee before ultimately long-term in-protocol solutions to MEV can be implemented. The individuals and teams suggested here all have relevant contributions to the MEV space (in the case of Reverie, the orchestrating of research and championing the entire effort in dYdX and also similar work on Osmosis).

Finally, regarding the amount of members between 5-7 seem adequate to have checks and balances in place and increase the cost of corruption, as well as to provide broad coverage.

Re: data on impact of MEV. This is a bunch of napkin math so probably somewhat off, but using it to illustrate the importance of this anyway:

The amount of “bad” MEV on Ethereum (i.e. frontrunning and sandwiching on DEXes) has been estimated to range between $500m-1bn a year (it’s hard to estimate the full impact purely from on-chain data, see e.g. Distribution of MEV Surplus | Galaxy). With dYdX being one of the highest volume decentralized exchanges, it’s likely that the impact of “bad” MEV could well be in the high millions a year if left unchecked, which imo definitely justify the the cost of this committee and other associated research efforts.

3 Likes
14

Thank you for this proposal and suggesting a dedicated committee to handle the proposal for social slashing events.

A first feedback on the proposal itself is that we would favour seeing the two statements in this proposal be voted on separately.

  1. Would the community be willing to engage in social slashing following a specific set of guidelines?
  2. Does the community want to engage a specific sub-set of community members for a specific compensation to lead the process of selecting misbehaving validators and proposing on-chain slashing votes.

The rest of this comment is specifically geared towards point 1 as the choosing of the specific committee structure and compensation to us is both less time sensitive and less controversial.

We are heavily in favour of upholding an anti-MEV social slashing ruleset and agree that it requires clearly defined punishment barriers and mainnet data to be acted upon. We also agree that it is helpful for there to be a leading committee/organization which can propose the slashing votes in due time and help with assessments of the on-chain data. This is specifically backed up by the turmoil around the most recent Cosmos-hub ICS slashing event which was not enacted due to incorrect proposal submission, timing issues, a lack of clarity around social consensus of the specific errors made by validators and the conflict of interest that followed with validators using their voting power for such a decision.

I also see some comments here comparing dYdX v4 to Ethereum mainnet already and id like to make a quick step in noting some differences with the consensus design of both that should highlight how even if nothing is done against MEV the impact should be lower on V4 than Ethereum mainnet.

  • Blocks are sub 2s on v4 instead of 12s significantly limiting the potential time blockbuilders have to calculate and execute MEV.
  • Tendermint works in a round-robin consensus and has no central block-building capabilities/companies. This means validators are only able to perform MEV on transactions they process in blocks they propose themselves. This also means unstaking/slashing has a direct effect on the total blocks a potential malicious validators can impact.
  • Cosmos has less central RPC traffic meaning validators will need to accrue transaction info first from peering and alter their client to start calculate optimal ordering immediately. If blocks have a smaller amount of TXs - as is likely with faster blocks - the total MEV in a single block will also decrease.

Nonetheless - Validators should be disincentivized to perform MEV until solutions like TEE forced execution (Secret Network) or pre-execution privacy (Fairblock) become more scalable. Social slashing is the way to go for punishing MEV, if alternatively the community is more in favour of commoditizing MEV and paying it out to stakers then dedicated Skip (https://skip.money/validators) clients are also an option.

Best,
Ertemann
Lavender.Five Nodes

5 Likes
15

Hey

I’ll share my thoughts on why this is important and the best path forward from here.

Firstly, is there a risk that this could happen?
There are currently no repercussions to validators performing MEV and therefore no risks to doing so. Nothing in the consensus protocol is violated.

There is a monetary reward for this behavior however and these factors combined make the risk of someone trying to tamper with transaction ordering/insertion/censorship highly relevant. If left unchecked, human nature (and game theory if profit is the utility function) usually results in someone exploiting the opportunity.

Lastly, dYdX Trading ran a validator on the testnet performing MEV so this is technically possible. I don’t think anyone would have known this had it not been brought up.

Is it a problem if MEV happens? How critical is this problem?

MEV breaks the product
Traders get worse fills and liquidity providers run the risk of market-making without the benefits if their orders are censored or front-run. Users will notice and trade elsewhere. This problem is critical.

MEV as a centralization vector
Validators profiting from reordering or censoring blocks will have a higher staking APR than honest validators and could accumulate significant delegated tokens. This is both a centralization risk and perpetuates the risk above. This could be made worse as large traders and market makers would benefit from partnering with such a dishonest validator by having their trades prioritized.

These two factors make MEV mitigation a crucial factor in dYdX v4 success. MEV degrades the product.

How big is this problem?
dYdX v3 settles many billions of Dollars of volume every month. It is safe to say the opportunity to profit from reordering/inserting transactions/censoring is significant. As mentioned above it also increases due to its potential for centralization over time.

Anyone who underestimates the size of the threat should look into DEX trades on Ethereum. At one point the MEV bot jaredfromsubway.eth was paying as much gas as Arbitrum. That money was being extracted from traders.

Why Social Slashing? Would Social Slashing Function as a Mitigant?
Because the dYdX chain is app-specific, community stakeholders can be opinionated on acceptable behavior and what is not. There is currently nothing in the protocol to mitigate MEV. This leaves the social layer as the only way to impose a potential cost onto bad actors.

Social slashing imposes a cost onto validators not following community-agreed behavioral standards. This both disincentivizes this behavior and mitigates the centralization risk mentioned above.

For me this is the logical, first proactive step to mitigate MEV. MEV will be a moving target though and this will need to evolve.

Why is a Committee Necessary?
Unless someone is tasked with, and incentivized to observe this risk there is a chance that it is not effectively monitored. The reason a committee is necessary is to make sure this crucial task gets the attention and resources it needs. Having a committee structure with appropriate communication channels, etc. also eases coordination constraints in a challenging coordination function.

The committee is also tasked with creating and presenting a standardized framework for retroactive action. The group working most closely with the data and tasked with following up on all related matters is best positioned to propose this framework. The final product still needs governance approval so this is not a unilateral decision.

This does not gatekeep social slashing and anyone is free to monitor Skip’s dashboard and act on it if they choose. Any actions taken or not against validators will also require a community vote so here too the committee itself does not act unilaterally and has no special privileges.

The committee is tasked with information gathering in the case of potential violations. This should help protect honest validators from false positives by providing greater context to the community.

Some thoughts on MEV mitigation as a competitive advantage.
The problem with trade reordering/insertion/censorship is a problem facing all exchanges, on or off-chain. Where matching engines exist off-chain, traders trust the exchange to be completely unbiased. This is not always the case. If dYdX can be demonstrably MEV-free (or close to) then this is a positive differentiator against centralized competitors where users know they are being treated fairly.

Disclaimer
I am a proposed member of this committee.

5 Likes
16

Hi all,

First, I’d like to recognize Reverie for coordinating this effort and submitting this proposal. MEV poses a real risk to the adoption of dYdX v4 (as clarified by @0xCLR, @FelixLts, and @Jordi), and a social slashing committee is the most reasonable solution we have seen (so far) for defending against MEV in the short-term. While more robust solutions are built to prevent MEV, creating a credible threat that we can detect MEV is a great step in the right direction.

I’d like to focus my comment on why a review committee is a good idea given the dashboard built by Skip. One might ask, if we have the dashboard, why do we even need a review committee?

Interpreting Data

MEV detection is probabilistic in nature: discrepancies (as defined here) may arise for several reasons outside of intentional MEV. One reason these discrepancies may (and will) arise is merely due to the geographical location of each validator (what dYdX Trading has referred to as “network jitter”). Although great progress has been made to enhance Skip’s dashboard to distinguish MEV from expected noise, it is still clear that deciding what is “actually MEV” or not will be difficult.

In order for the dashboard to pose a credible threat to misbehaving validators, the proposals to slash a misbehaving validator must themselves pose a credible threat. This means the way we interpret the probabilistic nature of the discrepancy data must be reasonable to dYdX’s voters. Otherwise, voters would, rightly, be hesitant to slash a validator and accept the ensuing consequences to the community if that decision was made unfairly.

One possible path is to fit statistical distributions to the discrepancy data from Skip’s dashboard once mainnet launches. This allows the community to form an expectation on what is “expected” MEV, and have statistical confidence on when a validator’s discrepancy is clearly out-of-distribution. This would make the decision to slash a validator less arbitrary, and establish clear guidelines for validators so they aren’t slashed unfairly.

Absent a clear and statistically-sound framework for interpreting this discrepancy data, coupled with a dedicated team to submit compelling proposals, making the decision to slash a validator will be murky and hard to justify. This can be interpreted in two ways:

  1. By dishonest validators: as an argument in favor of performing MEV if they don’t believe a slashing proposal could reasonably be submitted or pass a governance vote in a timely fashion.
  2. By honest validators: as an argument against participating in dYdX Chain due to fears of arbitrary slashing proposals tarnishing their reputation and causing financial harm.

I expect that having a team dedicated to producing this framework will significantly improve the effectiveness of Skip’s dashboard in mitigating MEV on dYdX Chain.

Still, the decision to slash a validator should not be taken lightly; it can cause material financial damage to lots of people, and doing so for unjustified reasons could tarnish dYdX’s brand and scare away honest validators. Performing this analysis and making this decision is a lot of responsibility, and I expect that no one on the committee will take that responsibility lightly, and neither would dYdX’s voters.

This is my personal opinion on why having a dedicated team to interpret the discrepancy data is important. Data in and of itself is not sufficient, the way we interpret and act on that data is what matters.

Disclaimer

I am a proposed member of this committee.

4 Likes
17

Really appreciate the care Reverie put into crafting this proposal. I’m also glad @luisqa brought up my connection as a member of Skip and Timewave. While I’m not on the committee it’s important to state that there is potential for some indirect conflict. One of the reasons Udit was chosen is because he has sufficient context to make an informed evaluation, in part because of our affiliation. Moreover, Udit’s ability to easily ask me a technical question may also be of value to the committee. I believe our relationship should be declared and appropriately scrutinized by the community. Meanwhile Udit should aim to interact as professionally and impartially as possible.

4 Likes
18

Appreciate all the responses! This is truly an important topic that Im glad we are discussing openly. I’m not sold on the immediate impact of MEV on v4 but agree having a team that directly oversees it can’t hurt. To be clear, glad to have skip on board, I’ve said dozens of times they are one of the best teams in the ecosystem, but wanted to add clarity that there was a relation unlike what was initially stated.

I’m still against Reverie being a part of this team and would strongly support that they are removed, simply by the fact that their expertise is greatly outweighed by the other committee members and honestly see no need for them to participate. They are already being greatly compensated from the grants program. If they still want to participate, I’m sure they can do so voluntarily.

4 Likes
19

Hi all,

In our understanding, as long as this program with a committee is sorely funded by the current GDP Strategic Initiative, it’s up to the decisions of @Reverie ‘s and the Grants’ Trustees as other grants programs are treated (If not, please explain why this is not the case.) Therefore, we appreciate @Reverie 's approach to make the details of the program available to the community in a transparent manner. We interpret this topic as a discussion thread rather than a proposal since it’s one of the most critical areas when dealing with the public blockchains, MEV protection.

Now, while we consider this program would proceed as it is, we are skeptical of the outcome we would have at the end of the term. We would suggest some changes to be made for the committee to commit to.

We would like the framework to be the deliverable that the committee should provide at the end of the term, not as a by-product. Otherwise, there would be a case that the committee just take a look at the dashboard, no major discrepancy happens and take no actions but get monthly compensations. If this is not possible as they have at least commit to their time to review the dashboard and data, we would suggest to lower the monthly compensation and propose retrospective compensations to the framework.

We would also challenge the committee to propose a more long-term solution to be implemented in the protocol to prevent the “bad” MEV from happening as Skip provides its solutions to other Cosmos SDK-based chains. We understand the current solution can’t be simply applied to dYdX Chain but the improved version of the solution can be at least considered and planned. We would simply like to avoid the situation where we don’t have a trustless solution on our plate after having a not-ideal solution like having a committee. This doesn’t have to be done in the coming program but as we would have a group of prominent and experienced members proposed for a committee, we don’t think it’s far off a request that the community can make.

We completely understand the importance of measures to be taken for the protection for bad MEV extractions especially in the Cosmos world as many pointed out already in the topic. However, as @Ertemann mentioned, there are quite a bit of differences in the architectures that Ethereum and CometBFT based chains apply. Yes, the dYdX Chain hasn’t launched its mainnet, thus we don’t know the exact scale of the bad MEV opportunity but we should also actively seek for the appropriate estimate of the impact that will be made by the bad actors after the release of the mainnet. It would be another research we would expect from the committee as well.

Other issues on potential conflict of interests

We would rather welcome indirect relationship between some proposed committee members and Skip because it’s critical to consider and propose improvements to be made on the Skip dashboard.

Regrading the inclusion of Reverie in the committee, we don’t welcome the idea as it’s clearly the abuse of the position as a lead grantor. We would like to request Reverie to get involved as a coordinator of the program while receiving the compensations set for the GDP 1.5 extension.

Concerns on the community vote on slashing validators

We simply use “community” as a collective entity to vote on the final proposal recommended by the committee, but in reality, with the dYdX Chain setup, the voters are likely the validators, and there is clearly a conflict of interests for other validators to vote on slashing a proposed validator. We are concerned about how the dynamics of the voting will look like without separation of power considered. This is something we should discuss going forward as well.

9 Likes
20

Totally agree. Lets substitute Reverie with someone from the dYdX trading. Nathan on today’s Town Hall told that dydx team has a good expertise in MEV, so this person will be super valuable addition to the committee. While Reverie will focus on its core mission being a strategic grantor.

I also support the idea to lower monthly payments and propose retro compensation based on deliverables.

2 Likes