Hey guys! This is great! I’m thrilled to see a discussion going up about taking proactive action to combat MEV.
MEV harms traders by giving them suboptimal execution pricing. Many holders of the dYdX token are no doubt traders themselves, so this is something that should be a primary concern. However, even if you’re a dYdX tokenholder that doesn’t also participate in trading (maybe you’re an LP or a MM or just a passive investor), this should still be a concern. Suboptimal execution pricing drives away traders, especially advanced traders or trading bots that drive a lot of volume to dYdX. This harms the protocol overall. MEV is something we should be actively seeking to fight against.
Currently, this social slashing mechanism seems to be the best option to ensure validators aren’t incentivized to misbehave, but we should be careful to place significant limitations on this power. For example:
Enshrined Governance Agreements
Assuming governance’s power to slash validators is parameterized in a proposal, there’s no real way to stop someone from putting up a proposal to slash a validator that they don’t like, or even for bad behavior that isn’t related to MEV. It’s a slippery slope because if the power is there, people will be encouraged to use it.
An example of this might be if a validator sets a low commission to draw in delegations, and then hikes the commission to 100%. Another example might be a validator that falsely promises an airdrop to get delegations. Or maybe a validator issues a token for an unrelated project and rugs the project. All of these things are clearly reprehensible behavior, and we’d probably be tempted to socially slash validators for them. But overuse of this power is dangerous and harms delegators to that validator.
Given that, I think it makes sense to have governance ratify a proposal that sets forth the conditions under which social slashing is acceptable (and ideally that would be only for this explicit MEV-related purpose). That could be done as part of this proposal or as an independent proposal.
Strict Procedural Rules for the Committee
This is important in light of the rules re: slashing and undelegation / redelegation times for Cosmos chains, as well as for the time it takes for proposals to go through governance. I’ll give a brief background on these:
Cosmos chains have governance-adjustable parameters governing how long it takes to undelegate your tokens, or redelegate them to another validator. For example, for Osmosis this parameter is currently set to 14 days. During this time period, your tokens are still subject to slashing, but after these periods have concluded, your tokens will no longer be at risk of a slash on that validator.
Similarly, Cosmos chains have a governance-adjustable proposal voting time.
So the issue that arises here is what happens when a validator engages in MEV and too much time elapses between the MEV event and the slash event. If we wait too long, this gives sophisticated delegators (or even the validator’s own self-bonded stake) the opportunity to remove their at risk stake from the validator, whereas more passive delegators would be subject to the slash. This also gives sufficient time for much more stake to be delegated to the misbehaving validator. It doesn’t make a ton of sense to me to slash delegators that weren’t even delegated to the misbehaving validator at the time of the MEV event.
So imo we should ensure that the process by which MEV is caught, verified, proposed to governance, and executed is, in all cases, less than the applicable redelegation period. If that redelegation period is 14 days, for example, and the voting period is 7 days, the review/ratification period should be no more than 7 days (and that would be cutting it pretty close).
It would be helpful here to know what these proposed initial parameters are, but that’s probably worthy of a separate forum discussion 