A validator is a virtual entity that lives on the Opside Chain, represented by a balance, public key, and other properties, and participates in consensus of the Opside network.
A validator client is the software that acts on behalf of the validator by holding and using its private key to make attestations about the state of the chain. A single validator client can hold many key pairs, controlling many validators.
A node operator is the human being who makes sure the client software is running appropriately, maintaining hardware as needed.
Each key-pair associated with a validator requires locking 25000 IDE to be activated, which represents your initial balance as well as your initial and maximum voting power for any validator.
No. There is no advantage to having more than 25000 IDE staked.Depositing more than 25000 IDE to a single set of keys does not increase rewards potential, nor does accumulating rewards above 25000 IDE, as each validator is limited to an effective balance of 25000. This means that staking is done in 25000 IDE increments, each with its own set of keys and balance.
Each 25000 IDE deposit activates one set of validator keys. These keys are used to sign off on the state of the network. The lower the IDE requirement, the more resulting signatures must be saved by the network. 25000 IDE was chosen as a balance between enabling as many people as possible to stake without inhibiting decentralization by bloating the size of each block with signatures.Limiting the maximum stake to 25000 IDE per validator encourages decentralization of power as it prevents any single validator from having an excessively large vote on the state of the chain. It also limits the amount of IDE that can be exited from staking at any given time, as the number of validator that can exit in a given time period is limited. This helps protect the network against certain attacks. Although a validator's vote is weighted by the amount it has at stake, each validators voting weight starts at, and is capped at 25000. It is possible to drop below this with poor node performance, but it is not possible to raise above it.Do not deposit more than 25000 IDE for a single validator. It will not add to your rewards.
You can think of the deposit contract as a transfer of funds from an Opside account to a proof-of-stake validator account.It specifies who is staking, who is validating, how much is being staked, and who can withdraw the funds.
As a validator, you'll need to have funds at stake so you can be penalized for behaving dishonestly.In other words, to keep you honest, your actions need to have financial consequences.
Yes, but with small penalties. If you go offline for a number of days under normal conditions you will lose an amount of IDE roughly equivalent to the amount of IDE you would have gained in that period. In other words, if you stood to earn ≈0.01 IDE, you would instead be penalized ≈0.01 IDE.
The answer to this question very much depends on how much IDE you have at your disposal.You should certainly top up if your balance is close to 12500 IDE. This is to ensure you don’t get kicked out of the validator set (which automatically happens if your balance falls below 12500 IDE).At the other end of the spectrum, if your balance is closer to 24999 IDE, it’s probably not worth adding the extra ETH required to get back to 25000.
You can signal your intent to stop validating by signing a voluntary exit message with your validator.once you’ve exited, there’s no going back. Currently there’s no way for you to re-activate your validator.
As a staker you are required to maintain and operate a node, running BOTH a consensus client AND an execution client.This became a requirement at time of The Merge, so be sure you're running both before staking.
Validators are responsible for processing transactions and signing off on their validity.
As a validator you are rewarded for proposing / attesting to blocks that are included in the chain.On the other hand, you can be penalized for being offline and behaving maliciously—for example attesting to invalid or contradicting blocks.The key concept is the following:
- Rewards are given for actions that help the network reach consensus.
- Minor penalties are given for inadvertant actions (or inactions) that hinder consensus.
- And major penalities—or slashings—are given for malicious actions.
In other words, you maximize your rewards by providing the greatest benefit to the network as a whole.
Your balance is updated periodically by the Opside network rules as you carry (or fail to carry) out your responsibilities.Your validator has its own balance, with the initial balance outlined in the deposit contract. Your rewards and penalties are reflected in your validator's balance over time.Since The Merge, validators will also be responsible for processing transactions, and thus be entitled to unburnt gas fees associated with included transactions when proposing blocks. These fees are accounted for on the execution layer, not the consensus layer, and thus require a traditional Opside address to be provided to your client.
Rewards and penalties are issued every 6.4 minutes—a period of time known as an epoch.Every epoch, the network measures the actions of each validator and issues your rewards or penalties appropriately.Your validator will also receives unburnt gas fees when proposing blocks. Validators are chosen randomly by the protocol to propose blocks, and only one validator can propose a block for each 12-second slot. There are 7200 slots each day, so each validator has 7200 chances-per-day to propose a block. If there are 500,000 validators, each validator will average a block proposal every 70 days.
There is no easy answer to this question as there are many factors that go into this calculation.Arguably the most impactful factor on rewards earned for validating transactions is the total amount of stake in the network. In other words, the total amount of validators. Depending on this figure the max annual return rate for a validator can be anywhere between 2 and 20%.Given a fixed total number of validators, the rewards/penalties predominantly scale with the balance of the validator—attesting with a higher balance results in larger rewards/penalties whereas attesting with a lower balance results in lower rewards/penalties.Note however that this scaling mechanism works in a non-obvious way. To understand the precise details of how it works requires understanding a concept called effective balance.
Block rewards are calculated using a sliding scale based on the total amount of IDE staked on the network.In other words: if the total amount of IDE staked is low, the reward (interest rate) is high, but as the total stake rises, the reward (interest) paid out to each validator starts to fall.Why a sliding scale? While we won’t get into the gory details here, the basic intution is that there needs to be a minimum number of validators (and hence a minimum amount of IDE staked) for the network to function properly. So, to incentivize more validators to join, it’s important that the interest rate remains high until this minimum number is reached.Afterwards, validators are still encouraged to join (the more validators the more decentralized the network), but it’s not absolutely essential that they do so (so the interest rate can fall).
It depends. In addition to the impact of effective balance there are two important scenarios to be aware of:
- 1.Being offline while a supermajority (2/3) of validators is still online leads to relatively small penalties as there are still enough validators online for the chain to finalize. This is the expected scenario.
- 2.Being offline at the same time as more than 1/3 of the total number of validators leads to harsher penalties, since blocks do not finalize anymore. This scenario is very extreme and unlikely to happen.
Note that in the second (unlikely) scenario, you stand to progressively lose up to 50% (12500 IDE) of your stake over 21 days. After 21 days you are ejected out of the validator pool. This ensures that blocks start finalizing again at some point.
Overall, we'd expect your validator to be net profitable as long as your uptime is greater than 50%.This means that you don't need to go to extreme lengths with backup clients or redundant internet connections as the repercussions of being offline are not so severe.
Again, it depends. Behaving maliciously—for example attesting to invalid or contradicting blocks—will lead to your stake being slashed.The minimum amount that can be slashed is 1 IDE, but this number increases if other validators are slashed at the same time.The idea behind this is to minimize the losses from honest mistakes, but strongly disincentivize coordinated attacks.
Slashing has two purposes: (1) to make it prohibitively expensive to attack the network, and (2) to stop validators from being lazy by checking that they actually perform their duties. If you're slashed because you've acted in a provably destructive manner, a portion of your stake will be destroyed.If you're slashed you're prevented from participating in the protocol further and are forcibly exited.
Withdrawal Credentials is a 32-byte field in the deposit, for verifying the destination of valid withdrawals. Currently, there are two types of withdrawals: BLS withdrawal and Opsise address withdrawal.
- 1.BLS withdrawal: By default, the deposit-cli would generate withdrawal credentials with the withdrawal key derived via mnemonics in EIP2334 format.
- 2.Opside address withdrawal: Set
--ide_withdrawal_address <YOUR IDE ADDRESS>when running deposit-cli. Please ensure that you have control over the keys to this address.
If you lose your signing key, your validator can no longer propose or attest.Over time, your balance will decrease as you are punished for not participating in the consensus process. When your balance reaches 12500 IDE, you will be automatically exited from the validator pool.However, all is not lost. Assuming you derive your keys using EIP2334 (as per the default onboarding flow) then you can always recalculate your signing key from your withdrawal key. After this functionality is added, your balance can then be withdrawn—with your withdrawal key—after a minimum delay of around a day. After this functionality is added, your balanceNote that this delay can be longer if many others are exiting or being kicked out at the same time.
If you lose your withdrawal key, there is no way to access to the funds held by your validator.As such, it’s a good idea to create your keys from mnemonics which act as another backup. This is the default for validators who join via this site’s onboarding process.
If you provided a withdrawal address when initially generating your keys, the withdrawal key no longer has any use. The only address that validator funds can be transferred to is this address, and it cannot be changed once set.If this was not provided, the withdrawal keys will be needed to sign a message declaring a withdrawal address. This requires access to the mnemonic used when setting up the keys.If a withdrawal address has not been set, and you have lost access to the mnemonic seed phrase, your funds will remain locked in the validator account indefinitely.
Validating involves two keys for security reasons. Your signing key must be available at all times. As such, it will need to be held online. Since anything online is vulnerable to being hacked, it’s not a good idea to use the same key for withdrawals.
If you have questions, IDEStaker community is a good place to get help! You can find support on Discord.