Cosmos Hub Improvement Proposal (CHIP): Validator Operation Agreement
Summary
The purpose of this Agreement is to define a set of operational rules and expectations for bonded, active Cosmos Hub validators. Its goal is to ensure fair competition, integrity in consensus participation, and sufficient decentralisation, by establishing minimum standards of behaviour and naming, and defining consequences for infractions.
Motivation
Over time, the Cosmos Hub has evolved into a foundational layer of the interchain ecosystem — a network whose legitimacy and resilience depend on the legitimacy of its validator set. As validator operations have become increasingly professionalized, the absence of a shared operational framework has left space for practices that, while technically permissible, undermine the Hub’s long-term decentralisation goals and the spirit of fair participation.
Two issues have become particularly visible: the emergence of duplicated active validators operated by the same entity, which can mislead the community about true decentralisation levels, and the use of validator monikers for commercial or promotional purposes, which can distort delegator perception and incentivize unhealthy competition. Neither of these concerns can be fully addressed by the on-chain consensus or slashing mechanisms, as they relate to operator conduct rather than protocol-level faults.
Scope
This Agreement applies to all active validators — that is, validator operators with bonded stake in the active validator set participating in consensus. It does not apply to:
- Validators which are bonded but inactive (i.e. outside of consensus participation because their bonded/delegated stake is not high enough), and
- Validator candidates or unbonded operators which have not yet become active.
1. Definitions
| Term | Meaning |
|---|---|
| Active Validator | A validator in the current consensus-participating bonded set. |
| Validator Operator | The entity (person or organization) or account controlling a validator (operator key). |
| Delegated Stake | The stake (ATOM) delegated by others (excluding self-delegation) to a validator operator. |
| Self-Delegated Stake | The stake which the operator themselves has bonded to their own validator. |
| Duplicate Validator | Two or more validators operators that are controlled by the same entity (physically, using same infrastructure, or beneficially linked), and which are active simultaneously. |
| Validator Name / Moniker | The public moniker or identifier used in the validator’s profile (“moniker” field) visible to the community. |
2. Obligations & Rules
2.1 No Duplicate Active Validators
- An operator shall not run more than one active validator under materially linked infrastructure, identities, or beneficial control.
- This prohibition applies only while validators are active. Operators may run multiple validators in non-active status (e.g. candidates / smaller stakes) for testing, verification, or other purposes.
- If an actor is alleged to violate this rule, a governance resolution may be initiated to adjudicate whether duplication has occurred.
2.2 Naming & Moniker Rules
- The validator moniker (name) must not include promotional, commercial, or financial incentive language (e.g. “100% APR”, “0% Fee”, “StakeDrop”, “Airdrop”, “stake here for rewards”, etc.).
- Validators must not use non-standard Unicode characters, emojis, or symbols intended to manipulate alphabetical sorting or visual prominence (e.g. “
Top Validator​:fire:”, “ⓉⓄⓅ Validator”, “
BestAPR”). Monikers must consist of regular alphanumeric and standard punctuation characters only. - Validators found in violation are requested to update their metadata through an on-chain signaling proposal. Failing to comply within one epoch (21 days) the can trigger a second proposal with applicable governance-led corrective measure.
The intent of this rule is to preserve readability, neutrality, and fairness in validator listings, ensuring all participants are displayed uniformly and without artificial emphasis.
Operators retain full freedom to advertise, brand, or promote their services externally, including through websites, social media, or governance participation — but the moniker field must remain functional and neutral.
3. Penalty Framework & Enforcement
| Violation Type | Trigger / Evidence | Penalty Options |
|---|---|---|
| Duplicate Active Validator | Verified proof that two or more active validators are under the same control, with materially linked infra / same operator, or other credible evidence. | Penalties include: tombstoning of duplicate(s) and slashing of delegated stake. |
| Misleading / Promotional Moniker | Moniker field includes prohibited characters or commercial promotion, after community or governance complaint and verification. | Penalties include: jailing of non-compliant validator entities, slashing or tombstoning (if severe or repeated). |
Due Process:
Validators and community members can submit allegations of violations (duplicate validator, naming issues) via a forum thread. Evidence should be transparent, with opportunity for community input. Any enforcement action must be taken via governance resolution, after a minimum period of 7 days allowing affected validator(s) to respond or comply.
Suggested Changes to Gaia Core Repo
- Add file docs/validators/validator-agreement.md under gaia/docs/docs with the Agreement text.
- In validator onboarding / setup docs (e.g. “Running a Validator”, “Validator Overview”), include reference to this Agreement.
- Possibly include CLI or UI warnings during create-validator or edit-validator --moniker to signal prohibited naming.