[DRC] Update Slashing Parameters

Proposals
1

Simple Summary

This proposal seeks to update the Slashing parameters on the dYdX Chain to increase validator accountability and consequently network performance. The current parameters are overly permissive, leading to slower protocol responsiveness and insufficient incentives for validators to maintain high uptime. By reducing the SignedBlocksWindow and increasing the MinSignedBlocksPerWindow, the protocol can hopefully incentivize lagging validators to improve performance.

Abstract

The Slashing module is a mechanism to penalize validators for a violation of protocol rules by slashing their bonded tokens. Penalties under the slashing module include burning a portion of a validator’s bonded tokens and/or temporarily removing their ability to vote on future blocks.

The relevant Slashing module parameters on the dYdX Chain are:

  • SignedBlocksWindow: 8192 (approximately 2.5 hours based on 1.11s block time)
  • MinSignedBlocksPerWindow: 20%.
    We think these thresholds are too lenient, allowing validators to underperform without significant risk of penalties.

We propose reducing the SignedBlocksWindow from 8192 to 2048 to enhance the protocol’s responsiveness to lagging validators and increasing the MinSignedBlocksPerWindow from 0.2 to 0.8 to promote better uptime. These changes aim to improve network stability and overall protocol health by holding validators to a higher standard of performance.

Motivation & Rationale

Validator performance is critical to the reliability of the dYdX Chain and affects user experience. The current Slashing parameters provide insufficient incentives for validators to maintain consistent uptime and performance, potentially compromising network reliability. The existing SignedBlocksWindow of ~2.5 hours allows lagging validators to avoid penalties for extended periods, while the MinSignedBlocksPerWindow threshold of 20% sets a low bar for acceptable performance.

The proposed adjustments will create a stronger incentive for validators to actively optimize their performance and protect the chain from potential disruptions. By enforcing stricter validator performance requirements, the dYdX Chain can improve users’ trading experiences.

Specifications

To ensure a smooth transition and avoid transiently jailing validators during the parameter update, the changes should be implemented in a staged rollout. Validators maintain a running MissedBlocksCounter, which only increments or decrements by 1 on each block. Therefore, when slashing parameters are updated, it takes time for the MissedBlocksCounter to re-converge to an accurate value based on the new evaluation window.

Proposed Parameter Changes:

● SignedBlocksWindow: Reduce from 8192 to 2048 (approximately 38 minutes based on 1.11s block time).
● MinSignedBlocksPerWindow: Increase from 0.2 to 0.8.
Staged Rollout Plan:

1. Proposal to Reduce SignedBlocksWindow:
● We will submit a parameter change proposal to reduce the window to 2048 blocks.
● After the proposal passes, we will monitor for 1-2 days to ensure no adverse impact and observe how validators’ MissedBlocksCounters converge to the new window.

2. Proposal to Increase MinSignedBlocksPerWindow:
● After 2 days have elapsed and there is no adverse impact reported by any validator on dYdX Chain, we will submit a parameter change proposal to increase the MinSignedBlocksPerWindow to 0.8.

It is important to note that reducing the SignedBlocksWindow by 75% immediately increases the effective uptime requirement proportionally by 4x, even before adjusting MinSignedBlocksPerWindow.

Next Steps

We welcome community feedback regarding the proposed changes to the Slashing parameters. If there is no strong dissent from the community, we plan to start submitting the testnet parameter change proposals on January 13, 2025, followed by the staged mainnet proposals.

4 Likes
2

Dydx already has one of if not the shortest downtimes before jailing out of all cosmos based chains already.
This gives validators absolutely no time to perform maintenance, 2.5 hours is already too low we should be looking to increase rather than degrease these windows.

Validators should be able to perform simple maintenance on infrastructure without facing downtime jailing after 30 minutes. We the chain being so fast resyncing a node from a not too old snapshot can take a couple of hours for instance.

If you want to increase validator accountability and consequently network performance. Then add downtime slashing but increase the downtime. If you want to get the message across this is the way right now some validators who don’t care how many times they get jailed have no incentive to make sure their nodes are online as they won’t incur any losses. Add slashing and they will be less likely to be down. Don’t go after the rest of us who like to maintain reputations by not getting jailed but perform routine maintenance from time to time.

Most CosmosSDK chains have this set to around 12 hours of downtime before slashing, 30 minutes is just ridiculous.

4 Likes
3

Thank you for initiating this important discussion on validator accountability and network performance. At Govmos, we recognize the value of raising standards but also acknowledge the valid concerns raised regarding the operational challenges of stricter parameters.

To strike a better balance, we propose a more gradual approach:

  1. Instead of a 4x reduction in the SignedBlocksWindow (from 8192 to 2048), we suggest halving it to 4096 first. This smoother adjustment would allow time to assess its impact while ensuring it doesn’t disproportionately penalize legitimate infrastructure maintenance.
  2. Following this, a performance evaluation should take place to ensure only underperforming actors are affected, not validators performing routine maintenance responsibly.
  3. Upon confirming that the changes effectively address poor-performing validators, we propose introducing a minimal slashing penalty to add a financial disincentive for repeated downtime. This step would further encourage accountability without prematurely affecting compliant operators.

We believe this moderate, step-by-step approach is both pragmatic and fair, allowing the community to achieve better performance standards while safeguarding validators’ operational needs.

Thank you for reading,
The Govmos Team
pro-delegators-sign

1 Like
4

With a block rate of 1.1 second and the current params, DYDX already has the most demanding slashing parameters compared to all networks supported by smart stake (Smart Stake Analytics). This is without considering the 3rd party dependencies that dYdX has that make it even more aggressive (ETH RPC / Slinky). It is absurd to assume that validators will not even have 10 minutes outage.

Validator accountability is already very high in dYdX for the current cost/benefits involved. Don’t see any reason to increase that further. A clear no vote here.

4 Likes
5

In addition to the esteemed feedback by @SilkNodes and @smartstake, I will like to add a few observations.

The current nakamoto index for dydx chain is 4.

Yes. 4. It takes just the top 4 validators to be down and the network is halted.

And according to https://analytics.smartstake.io/dydx/stats#vp, the top 17 validators command >66% of voting power.

This means the performance of the top 4-17 validators is all that matters for consensus to occur, and for consensus to occur fast.

And the reason why I suspect there is so much instability at the moment is, if the VP crosses 66% signatures on a block and, if the remaining minority nodes that have yet to sign are not part of the direct p2p node network graph of the proposer, then there is insufficient waiting time for the minority of the VP validators to sign and the proposer will just finalize the block without their signatures. This reason is why I suspect most of the underperforming nodes are the lower VP validators.

Yet if the objective is to improve network stability and performance, then why on earth has everything that has been done so far led to an increase in centralization of stake???

The floating of the idea to cut the valset by half, the subsequent withdrawal of delegation to the bottom 30 validators by Stride/Karpat and etc are all factors that are directly increasing network instability imo.

This proposal solves nothing at all.

4 Likes
6

Just been going over this madness again and noticed that not only is this proposal insane given validators not only need to run a validator node, a full Ethereum node and an instance of slinky all to maintain signing blocks but also your maths is wrong.

You point out the block signing window is 8192 which is roughly 2.5 hours and suggest reducing that down to 2048 which is roughly 38 minutes you fail to point out how long a validator needs to be down in order to get jailed currently and with the proposed changes.

Currently with a MinSignedBlocksPerWindow at 20% that means a validator must sign at least 20% of blocks within the current 8192 which is 1,638 blocks meaning if a validator is down for a period long enough to miss 6,554 blocks they will be jailed. This equates to 109 minutes of downtime leading to jailing currently. Again this is already far too low giving the requirements to run on Dydx as is.

The suggested changes would look like this with a MinSignedBlocksPerWindow at 80% per 2048 SignedBlocksWindow validators would need to sign a minimum of 1,638 blocks meaning if a validator is down for a period long enough to miss only 409 blocks they will be jailed.
This equates to 7 minutes of downtime leading to jailing!!

I feel like the parameters need increasing not degreasing and completely agree with the sentiments of both @smartstake and @samwise. Some validator will always blindly agree with whatever proposals as we have seen in the past but we had to make our opinion heard on this one.

5 Likes
7

Thank you to everyone who provided thoughtful and detailed feedback on this proposal. We appreciate the active engagement, constructive criticism, and concerns shared by the community. Based on the feedback, we’d like to revise the proposal to address these concerns while maintaining our original goal of improving network performance and validator accountability.

Revised Proposal Adjustments

1. SignedBlocksWindow:
Reduce from 8192 to 3072 (~57 minutes at a 1.11-second block time).

  • This strikes a balance between improving protocol responsiveness and allowing sufficient time for validators to manage routine maintenance.

2. DowntimeJailDuration:
Decrease from 7200 seconds (2 hours) to 3600 seconds (1 hour).

  • This adjustment ensures that validators can rejoin the active set more quickly after resolving downtime issues.

3. MinSignedBlocksPerWindow:
No changes at this time (remaining at 0.2). We will revisit this parameter and the potential increase to 0.8 in a separate proposal after observing the impact of reducing the SignedBlocksWindow.

Clarifications and Rationale:

1. No Parameterized Slashing on dYdX Chain
We want to emphasize that while this proposal references the “slashing module,” there is currently no parameterized slashing penalty on the dYdX Chain. The parameter slash_fraction_downtime is set to 0.

  • Validators who are jailed for downtime can simply rejoin the active set after the DowntimeJailDuration without incurring a financial penalty.

  • If validators need to perform maintenance that will result in jailing, they can simply rejoin the active set after the downtime_jail_duration.

  • We understand that validators may have concerns about the reputational impact of being jailed. However, it may be helpful to consider that certain practices and norms in other ecosystems don’t necessarily apply to dYdX, given its unique design as an independent app-chain focused on perpetuals trading.

  • Validator performance is fundamental to ensuring a good trading experience for users. The community should consider the trading experience above all else to maintain a competitive edge in the market.

2. dYdX Chain Validator’s missed_block_counter
Based on the current performance of dYdX Chain validators, reducing the SignedBlocksWindow from 8192 to 3072 is unlikely to impact most validators (1-3 validators affected). As such, we don’t think this proposal will have much impact on the current state of things, but will instead increase the bar for future performance expectations.

Closing Thoughts

We believe these adjustments strike a fair balance between enhancing validator accountability and accommodating operational needs. We will give a few days for feedback before moving forward with an on-chain vote.

1 Like
8

We echo the sentiments of other validators here. Having a slash on our record is not something we want, regardless of there being no financial penalty. There are very few metrics to judge a validator on, and slashes will always be a large factor, especially for smaller validators.

If the intention is to encourage validators not to have extended downtime then implement a penalty. Otherwise the validators who have already been slashed multiple times will continue to do so and nothing will change, other than taking them out of the set slightly faster (and allowing them to rejoin faster) which doesn’t really solve anything in the long run.

The proposed changes here just throw ‘good’ validators in with the bad by penalising reasonable maintenance and encouraging everyone not to care about slashes. In which case what’s the point of the whole system?

2 Likes
9

Whilst I agree dYdX is different, the problem is the slash counter increases still, dYdX needs to remove this and also wallets like Keplr will alert delegators when a validator is jailed, both these need to be resolved in order to make validator not worry about being jailed

1 Like
10

I don’t understand this at all.

If this is unlikely to have much impact on the current state of things, why even bother putting this up for a vote?

Validators are restricted by stake amount to enter the active set and the ability to deploy nodes in tokyo at the moment, along with the capabilities to have 24/7 maintenance coverage.

“The bar for future performance” what does this even mean?

There is absolutely no good reason to tweak these parameters unless it’s to make ourselves feel better.

The extremely weak network stability from the high concentration of stake is totally unaddressed and you are here trying to aim for a higher bar for future performance?

Are you serious?

3 Likes
11

Hey,

First of all, I will look at this proposal from the original dYdX slashing rationale which is:

  • Not earning rewards during jailtime is a penalty in and of itself
  • An additional slashing penalty is not needed - it impacts stakers > validators

Because of this I understand why the slashing on dYdX is different than other CometBFT chains, they are stringent but its do-able.

However, I don’t understand this search for perfect uptime as I don’t see/understand the same impact that the proposer is mentioning.

  • Uptime on CometBFT chains doesn’t impact the ability for a TX to land on-chain or be verified and finalized.
  • There is no exact mention of how the p2p-layer/Orderbook is impacted by validators missing blocks

Therefore i don’t understand the above quote. As long as validator performance is not below standard (67% VP needs to be signing) there shouldn’t be any impact for users.

Clarification here would be helpful in understanding exactly why the MEV-council deems uptime so important.

Additionally I think it is valid to say that we are using the wrong method to chase this goal.

Examples:

  • if basic uptime is deemed important than the network should implement soft-slashing, aka: you only get rewards for a block/proposal if you are signing. - See Berachain, Hyperliquid and more who have this.
  • If escalating uptime is deemed important (aka not halting) than the network should implement something like quadratic slashing (namada).

Lastly, the current proposed times are still crazy. Although dydx might not agree with the general crypto ecosystems view of slashing, under the wrong circumstances it can be a deathkiss for a validators entire business.

There are still teams that run withouth Horcrux (which should be respected as they keep the chain from having a majority dependency on external software) and for them doing maintenance is simply not feasible without downtime.

Forcing a validator into brand reputation every time they need to maintain their validator node is simply just crazy.

Summary:

I think this proposal completely misses the mark both for the lack of rationale and the usage of the wrong methods for the goals set. One can ask a lot of validators, but pushing them to potentially
irreparable brand damage for only 40mins of downtime (engineers often wake after 15-20) is just nuts.

best,
Ertemann
Lavender.Five Nodes

4 Likes
12

Posting on behalf of Chorus One

After reviewing the proposed changes to the slashing parameters, we have several concerns about their practical implications and the underlying rationale.

  1. Impractical Response Windows - The proposed 57-minute window (3072 blocks) creates operational risks. Alert systems typically need ~10 minutes to confirm genuine issues This leaves only 40 minutes for engineers to:

    1. Understand the problem (especially challenging for engineers less familiar with the chain)
    2. Implement and verify fixes
    3. Restore operations

    This timeline is unrealistic for thorough problem resolution and could force hasty decisions.

  2. Geographic Concentration Issues

    1. A high concentration of validators currently operate from Tokyo data centers. Regional infrastructure issues could affect multiple validators simultaneously. The proposed parameters wouldn’t improve network resilience in such scenarios
    2. Chain stability depends on maintaining 67%+ of voting power, not individual validator uptime

  3. Real Impact - The proposal acknowledges it would only affect 1-3 validators based on current performance. This suggests there isn’t a current performance problem to solve. The changes appear to be arbitrary rather than addressing specific issues! Given the high costs of running infrastructure in Japan and relatively modest validator rewards, adding these constraints seems unnecessary

  4. Impact on Validator Operations

    1. This nudges validators to implement HA signing solutions like Horcrux which creates additional operational complexity and costs
    2. It particularly impacts smaller validators who may lack resources for complex setups and could lead to further centralization of validation power

  5. Negative Perception - Slashing events are visible in popular wallet interfaces like Keplr. More frequent slashing events would create negative perceptions among delegators and will unnecessarily damage validator reputation for non-critical issues

Conclusion
The proposed changes do not seem to be addressing any real problems while creating new operational challenges. The current parameters already maintain good network performance while allowing realistic operational margins. We suggest maintaining current parameters unless specific performance issues can be identified that these changes would address.

3 Likes
13

I would like to thank the team for this clarification regarding the proposal to adjust the slashing parameters.

I understand the objective of optimizing the trading experience by offering greater responsiveness. It’s true that when the uptime of one or more validators drops, blocks rate slow down a bit.
The reason behing is that is a validator miss to propose a block, the ComentBTF’s logic is to wait for a timeout before the next validator proposes a block again.

In the absence of slashing, reducing block duration should not, in theory, cause any problems for validators, the main reasons for miss blocks are mostly due to lack of performance during high chain activity.
Changing the uptime percentage from 20% to 80% could, however, cause more problems if applied.

I’m not opposed to this proposal, as dYdX is a platform that demands impeccable quality of service to guarantee an optimal user experience.

Nevertheless, it’s important to stress that this evolution will require validators to have a high-performance infrastructure, and ideally to implement high-availability and redundancy mechanisms.

Given validators’ current revenues, which average around $10 per day, the costs associated with this redundancy could have a significant impact on their profitability.

It would be appropriate to examine this aspect in more detail to ensure the economic viability of participation in the network. It had been envisaged to reduce the set to 30 validators, which could increase validator revenues.

1 Like
14

Some downtime is bound to happen once every year or so. dYdX slashing parameters are already very aggressive. Most validators view a jailing event as a blot on their reputation.

Given the current state of network, i don’t think this proposal in any form is supportable.

Lastly, I still don’t know what is the problem statement that you are chasing with this proposal.