In blockchain ecosystems, the Node Operator runs what is called a node. A node can be thought of as a power pylon in the physical world, which helps to distribute electricity around a wide network of users.
Photo credit: Marcus Wong
Without these pylons, electricity would be largely centralised in one location; the pylons help to distribute power to entire wide-scale populations. And if one pylon fails, the grid is set up to circumvent this pylon and re-route the electricity to a different route.
Similarly, in blockchain infrastructure, each node runs an instance of the consensus protocol and helps to create a broad, robust network, with no single point of failure. A node failing will have little impact on the Network as a whole; however, if multiple nodes fail, or disagree with information entered into the transaction, then the block may not be signed, and there are fail-safe measures to notify the rest of the Node Operators of this.
The terms Validator and Node Operator are somewhat synonymous. Validator is the term used more commonly in the Cosmos documentation when referring to a Node Operator that is validating transactions on a blockchain. The only point worth mentioning is you can have a Node Operator that is NOT a Validator. These are known as Observer nodes, which play a more passive role on the network, as they don’t stake on the network or validate transactions, but can observe them.
The Cosmos Hub is based on Tendermint, which relies on a set of validators to secure the network. By ‘secure the network’, this refers to the way in which validators “participate in consensus by broadcasting votes which contain cryptographic signatures signed by their private key”. In English pls…
A cryptographic signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A private key is like a password — a string of letters and numbers — that allows you to access and manage your crypto funds (your mnemonic is a version of this). So, the above is saying validators can broadcast that they agree with transactions in a block, using their password to sign their agreement in a mathematical way which ensures security and privacy.
Set up your node on cheqd and configure it to become a validator node.
Set up your Validator
Learn how to become a node operator and configure a validator node.
cheqd will launch with community-spend capabilities, allowing CHEQ Participants to approve spending from the Community Pool. This documentation is in active development, so please seek feedback and take care when using this information.
The community pool value is accumulated over time.
10% of all staking rewards generated (via block rewards & transaction fees) are continually transferred to and accrue within the Community Pool.
You can always see the balance of the cheqd Community Pools on one of our Block Explorers. Our main block explorer is here:
Funds from the cheqd Community Pool may be spent via successful governance proposal.
The prevailing assumption is that funds should be spent in a way that brings value to the cheqd Network. Or alternatively, something which benefits the wider world, such as spending the Pool on Carbon offset and sustainability.
If a community-spend proposal passes successfully, the number of $CHEQ encoded in the proposal will be transferred from the community pool to the address encoded in the proposal, and this will happen immediately after the voting period ends.
Drafting and submitting a proposal is a process that takes time, attention, and involves risk. The objective of this documentation is to make this process easier by preparing participants for what to pay attention to, the information that should be considered in a proposal, and how to reduce the risk of losing deposits. Ideally, a proposal should only fail to pass because the voters:
are aware and engaged
are able to make an informed decision to vote down the proposal.
If you are considering drafting a proposal, you should review the general background on drafting and submitting a proposal:
There are five (5) components:
Title - the distinguishing name of the proposal, typically the way the that explorers list proposals
Description - the body of the proposal that further describes what is being proposed and details surrounding the proposal
Recipient - the cheqd address that will receive funding from the Community Pool
Amount - the amount of funding that the recipient will receive in nanoCHEQ ("nCHEQ")
Deposit - the amount that will be contributed to the deposit in nanoCHEQ ("nCHEQ") from the account submitting the proposal
You should use our forum for Community Spend Proposals to discuss the Proposal with the cheqd community:
In this simple example (below), a network explorer will list the governance proposal as "Community Pool Spend." When an observer selects the proposal, they'll see the description. Not all explorers will show the recipient and amount, so ensure that you verify that the description aligns with the what the governance proposal is programmed to enact. If the description says that a certain address will receive a certain number of CHEQ, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise).
The amount
is 1000000000ncheq
. 1 billion nano-cheq is equal to 1 CHEQ, so recipient
address cheqd1qgfdn8h6fkh0ekt4n4d2c93c5gz3cv5gce783m
will receive 1 CHEQ if this proposal is passed.
The deposit 8000000000000 ncheq
results in 8000 CHEQ being used from the proposal submitter's account. There is a minimum deposit required for a proposal to enter the voting period, and anyone may contribute to this deposit within a 7-day period. If the minimum deposit isn't reach before this time, the deposit amounts will be burned. Deposit amounts will also be burned if quorum isn't met in the vote or if the proposal is vetoed.
A stake is the amount of tokens a Node Operator puts aside and dedicates to a network’s active pool to contribute to governance and earn rewards. Staking is the verb used to describe this contribution. As cheqd is a Proof of Stake (PoS) Network, rewards can be earned in direct correlation with the amount of stake a Node Operator contributes.
Token holders, ‘users’, can delegate their tokens to Node Operators in order to earn rewards and participate in governance. Once a user has delegated tokens to a Node Operator and has tokens added to the active pool, they are known as Participants.
Users can delegate to multiple Node Operators at the same time to essentially diversify their bonded token portfolio.
Bonded tokens are those present in the active pool.
Bonded tokens = staked tokens by Node Operator + delegated tokens by a user.
Users are persons who hold $CHEQ. Users are able to delegate tokens to Node Operators in order to have those tokens bonded and added to the active pool.
Once a User has delegated tokens to a Node Operator and has tokens added to the active pool, they are known as "Participants".
Participants may be eligible for a percentage of the rewards that Node Operators earn during the course of running a node. Node Operators may offer a certain commission for delegating to them. Participants earn rewards on the delegated tokens which are bonded to the Validator.
Therefore, you may want to delegate and stake your tokens for two reasons:
To participate in Network Governance;
To earn rewards proportionate to your stake in the Network.
Choosing your Node Operator or multiple Node Operators is an important decision. There are a few things you can take into consideration:
The incentive for delegating tokens to a Node Operator is that you, as a participant, can earn rewards based on the stake of the Node Operator. Each Node Operator will have a commission rate. This is the percentage of tokens that the Node Operator will take as commission for running the infrastructure — the remaining percentage is distributed to the Participants.
You should be mindful about what reputation the Node Operator has. This is because the Node Operator may use your votes against the best interest of yourself and the community. As cheqd evolves, it is likely that there will become a political spectrum of Node Operators, who will cast their vote in different directions. Some may want to create chaos on the network and vote to disrupt the established paradigms, for example. A chaotic actor may lure users to delegate to them with a favourable commission rate and use the accumulated bonded tokens against the network’s best interests. For this reason, the choice of Node Operator you delegate to is very important.
As the name would suggest, staking is not risk-free. As the word stake literally means “having something to gain or lose by having a form of ownership of something”, individuals should be wary of the risk, as we’ll come on to.
Think of it like this, if someone says to you “what’s at stake?” they are essentially asking: “what am I risking in return for the potential rewards?”
Node Operators might exhibit bad behaviour on the Network and, as a result, have their stake slashed. Slashing means taking the stake away from the Node Operator and adding it to the Community Pool.
Bad behaviour in this context usually means that the Node Operator has not signed a sufficient number of blocks as ‘pre commits’ over a certain period of time. This could be due to inactivity or potential malicious intent.
For example in June 2019, CosmosPool a former Cosmos validator experienced a server outage on their main node; downtime that resulted in its validator being temporarily jailed and its stake being slashed by 0.01%, including that of its delegators. This was what’s call a downtime slashing incident (soft slashing) whereby the validator and delegators were punished for downtime proportionally to their stake on the network. On top of this, further slashing later occurred as evidence was found of double block signing. Both CosmosPool AND the delegators’ stakes were slashed an additional 5% and the validator was permanently removed (‘tombstoned’).
Slashing can therefore certainly affect your delegated and bonded tokens, so it is important to consider your choice.
We currently have the slashing values to:
5% slashed for double signing
1% slashed for downtime (getting jailed)
These values may change over time through proposals that are voted on the network. You can read more about slashing here.
Yes, it is possible to instantly redelegate to a new Node Operator; however, you cannot ‘hop’ between Node Operators quickly. You must complete your redelegation to a Node Operator before moving again. If you want to completely withdraw and unbond your tokens, you need to be mindful that this process takes two weeks for the tokens to become available for use again. This unbonding period is an example of a parameter, which can be adjusted by the Governance Framework process.
Users with bonded tokens, Participants, are able to vote on Governance Proposals. The weight of a vote is directly tied to the amount of bonded tokens delegated to Node Operators.
The specifics of how a participant can vote on Proposals, or create Proposals, is detailed further in our Governance Framework.
If the User does not want to vote on a Governance Proposal or misses it for any particular reason, the Node Operator will inherit the delegated tokens and can use them to vote with.
Node Operator voting power = initial stake + inherited delegated tokens (if participants do not vote)
Participant voting power = delegated tokens (if a participant chooses to vote)
If you are particularly interested or passionate about a specific governance proposal or do not agree with your bonded Node Operator, it is absolutely possible to vote unilaterally. However, you must still have delegated tokens, bonded with a Node Operator to do so. To do this, follow the instructions in the section Voting on cheqd.
In short, yes. Participants may be eligible for a percentage of the rewards that Node Operators earn during the course of running a node. Node Operators may offer a certain commission for bonding to them. These rewards may come in two forms:
Writes to the cheqd Network incur what is known as a transaction fee, which is calculated based on gas. Gas may be higher when there are high transaction volumes on the Network, and vice versa. Node Operators may also set their own gas prices, above which they are considered in the pool of who creates that transaction block. However, we will not get into the nuances of gas here.
Block rewards depend on inflation. Inflation is the gradual increase in the number of blocks on the Network. A Node Operator may earn block rewards during a period of inflation, which can be disseminated to the Users delegated to the Node Operator. For this reason, it is suggested that token holders bond and delegate their tokens, to create a healthy Network and earn passive income.
These rewards are distributed continuously and instantly. You are able to see your accumulated rewards on our dashboard: cheqd.omniflix.co and can always claim them back into your account.
Use the below links to get up to speed with some of the core concepts and terminology in the cheqd network ecosytem.