We appreciate the proactive approach taken to move forward with concrete actions following the previous discussion phase in this forum (link to the topic here). To provide a TL;DR on the challenges highlighted in the earlier discussion, our perspective leaned toward the necessity of a broader governance reform, ideally leading to a constitution for the Hub. Such a document would establish guidelines for validator naming practices and outline enforceable actions against non-compliant entities.
We also find Melea’s actions to be problematic and believe they should not go unaddressed. While creating this constitution would require significant coordination and time, we feel that immediate, actionable steps should also be proposed to the community to define acceptable practices for validator naming. These initial actions could serve as the foundation for a future governance framework constitution.
Proposed Rules:
To clarify our position on this matter, we propose the following principles to define an “acceptable range” for validator naming:
- Validators should use the ASCII character set exclusively (non-standard symbols and special characters would be non-compliant).
- Validator names should not be used for marketing purposes, such as promoting external content, links, or incentives aimed at attracting delegators.
- Financial incentives should not be advertised through validator names (stakedrops, airdrops, fee rebates, lotteries, etc.) . Validators are welcome to promote these through other channels, such as social media or websites, but not through the validator name itself.
Proposed Sanctions:
Violations of these rules should come with penalties. We aim to refine our suggestions based on the author’s initial post, as follows:
We find this solution technically challenging, as it would likely require updates to the governance module, adding further dependencies. Therefore, we suggest passing on this option.
We support imposing financial penalties on non-compliant validators but feel that an on-chain tax would be complex to implement. Instead, we propose utilizing “jail-time” as a primary enforcement mechanism. Jail-time is an existing tool designed for handling governance-related violations and would not require additional module updates.
Proposed Approach:
- Misbehaving validators should receive a formal notice via a forum post, allowing 14 days for them to respond and present a defense.
- After this period, an on-chain proposal can be submitted, detailing the broken rules, proposed penalty, and linking to the forum discussion.
- Repeated infractions should incur increased jail-time, with extreme cases potentially resulting in tombstoning (permanent jail-time).
- If a validator attempts to evade penalties by spinning up a new entity, stake slashing could apply to enforce financial consequences.
For more details on jail-time, please refer to the Cosmos documentation: Slashing Overview | Cosmos SDK
Regarding complementary proposals, such as a validator transparency index or a delegator education campaign, we view these as supportive measures. However, we emphasize that jail-time, paired with a clear and fair set of rules, is the optimal approach.
Proposed Plan:
We propose splitting this initiative into two votes: the first to define the rules, followed by a second to enforce penalties on non-compliant validators. After a 14-day forum post listing non-compliant actors, validators would have sufficient time to modify their names to comply. For the specific case of Melea, whose long-term non-compliance is evident, we recommend a separate vote to apply a retroactive penalty. This could involve a set jail-time period, after which Melea would be permitted to rejoin consensus if they comply with the rules. Repeated violations would lead to progressively longer jail-time, culminating in tombstoning if they continue to disregard compliance.
Thank you for reading.
Govmos.
