A Delegator’s Guide to Staking
A guideline for thinking about delegation and preparing fundraiser participants for launch
As a delegator, you have a responsibility to contribute your Atoms’ voting power to the validator that best represents the security, responsibility and value you want in the Cosmos Network. In exchange for your due diligence, the Cosmos Hub protocol provides you with fees and inflationary provisions minus a commission that is kept by the validator itself. We expect a competitive market to emerge around commission rates. Cosmos validators are the foundational piece of a new financial infrastructure and your job as a delegator is to assign voting power to whomever is most qualified for the job. This post will offer some guidance to Atom holders in making delegation decisions but should be at most a starting point for thinking about your choices. This post also serves to inform potential validators about what factors delegators might consider.
A follow-up blog post about the next Voyager release will walk you through a step-by-step guide to show you how to stake your Atoms in the Voyager UI.
- System Architecture
- Economic Model
- Track record
A validator’s track record is indicative of the strength of their setup and commitment to the Cosmos project. Delegators can analyze a validator’s track record based on network or node availability, monitoring capabilities and DevOps such as attack or denial-of-service mitigation.
Delegators will be able to follow and evaluate a validator’s track record in the upcoming adversarial testnet game. Watch for winners of “A Testnet of Steaks”.
In the first 12 months of network launch, the technical setups between each validator will vary by a lot. But this list of desired attributes should differentiate the sophisticated setups from the naive ones. If a validator checks off two or more of the items in each desired attribute, you can be reasonably confident in their setup. This is at least a reasonable expectation for genesis validators.
High Uptime (All the Nines)
A validator that has been offline for over a certain amount of time will be booted from the validator set by the protocol. And while any number of arbitrary failures could trigger a slashing condition for a validator or boot the validator off the validator set, the single most common fault is unavailability. As such, it stands to reason that the most important attribute that a validator should have is the ability to maintain high availability. Highly available validator infrastructures demonstrate:
- Resiliency against power outages, such as backup power generators or location redundancy for network power and datacenters.
- Lightning fast internet connectivity with additional benefits from proximity to fiber cables or satellite connection as backup
- Quick turnaround time for broken hardware replacement or lost connectivity, ideally within 24 hours. 24 hours is the window of time that validators have before the protocol starts slashing (minor slashing condition).
- Two or more sets of every piece of critical hardware stored in inventory as backup for replacement hardware. For example, backup local servers just in case hosted remote servers go temporarily offline.
- On-call staffing of highly skilled network, storage, and server reliability professionals 24/7 for performing fixes as-needed.
- Reliable fail-over or generally some sort of active replication scheme for both validators and sentries. In case a validator node goes down, implementing a sophisticated manual fail-over system can mitigate the perils of a single point of failure (one validator node) while ensuring fail-over node(s) do not enter into a race condition and double sign, triggering a severe slashing condition. In the future, validators will be able to run across multiple nodes, eliminating the need for a manual fail-over system. There is an open github issue tracking progress here.
The operational security component of a validator’s system also helps mitigate downtime. There are several operational pieces to evaluate such as:
- The validator’s reliable monitoring and detection implementation. For example, digital forensics TTPs that help investigate root cause of failure (combined with OSQuery-style monitoring) will be key as the Cosmos Network matures.
- The physical security surrounding a validator’s equipment such as staffed security guards, biometric locks, etc.
- Sentry nodes. Ability to spawn many sentry nodes and near real-time response DDoS by spawning new sentry nodes to replace old ones that were under attack.
High Grade Hardware
Lastly, a delegator should consider the quality of a validator’s hardware. Some examples of high grade hardware setups should include:
- Hardware Security Modules to mitigate risk, add cold storage functionality and secure store keys.
- Key management service to rotate, update and manage encryption keys. YubiHSM 2 will be supported at launch.
- Enterprise grade hard drives with mechanisms to tolerate/recover from data corruptions.
The social layer is where decisions become more subjective-based, as the validator businesses with demonstrably best-in-class services will eventually converge on similar technical setups over a long enough period of time. The variables that will then become likely more relevant become the difference in commission rates, social reputation, amount of self bond, and how much validators have invested in the ecosystem beyond just its business.
Some values that may emerge as to why delegators will decide on a specific validator over another could be the following:
- How long a validator has been involved in the greater ecosystem
- Clear communication about a validator’s contributions and activities in the greater ecosystem
- Educational content such as tutorials, videos, guides, blog posts, etc. contributed to the community
- Interactive content shared with community such as hosting AMAs, interviews, podcasts, and meetups
- Willingness to be helpful in community discussion channels
- Giving back to the Cosmos ecosystem by contributing open-source tools for network deployment, monitoring, and debugging
- Stake in the ecosystem, such as developing applications and protocols above base layer
- Other value shared with community
- Governance track record such as high engagement in voting and proposal activity
- Amount of self-bond. When a validator misbehaves, part of its total stake gets slashed. This included the validator’s own stake as well as its delegators’ stake. Thus, a validator with a high amount of self-bonded Atoms has more skin-in-the-game than a validator with a low amount.