Network Bounties and Delegation Workflow

This document lays out the calculations within the SKALE Network that determine the bounties paid to the validator and then distributed to each validator's delegators (if applicable). These calculations are triggered by the nodes within the network at the end of each epoch with the actual calculations and distribution of payouts performed by SKALE smart contracts running on the Ethereum mainnet.

The SKALE Network and Bounty Calculations

Developers create chains within the SKALE Network by selecting the size of the chain (small, medium, and large), duration of the chain (6mo, 12mo, 24mo), and then staking SKALE tokens in order to provision the network resources. These tokens get staked into the Ethereum mainnet via one of the SKALE contracts that reside there. Each month, a certain number of tokens from this developer stake gets moved into a bounty pool which is then used to pay the validators within the network.

An inflation (issuance) event also takes place each month whereby new SKALE tokens are created via a contract on the Ethereum mainnet, the result of which gets pushed into the bounty pool for payout to validators. By way of example, if there are a thousand validator nodes in the network and they all perform well, they will each participate in the monthly proceeds from the bounty pool – this bounty pool consisting of a portion of the chain token stakes plus the inflation amount.

Note that the distribution to the validators is not necessarily shared equally as there is a modifier component that slightly adjusts the payout based on the duration of time tokens are staked into the network. Nodes with tokens that are locked up for twelve months, for example, will get a greater percentage than those locked-up for three or six months. 6 and 12 months delegation will be enabled in 2021 (exact date TBD).  

Terminology

MSR: Minimum Staking Requirement needed to register a node in the network

Epoch: An epoch is the period for which bounties are calculated and payouts to validators and delegators made. A single epoch starts with the beginning of the month UTC and ends the midnight of the end of the month UTC. There is no "number of days" calculation as it is always the calendar month, regardless of the number of days in the month. Delegators should delegate their tokens to a specific validator and delegation should be accepted by the validator prior to the start of an epoch. When epoch starts, delegators begin earning bounties, subject to potential bounty reduction as described below.

Delegation: Delegation is the practice of providing a portion of the total staking amount (collateral) needed for a node to run in return for an agreed-upon percentage of proceeds earned from validating. Delegation is done in agreement with a validator and on a validator basis, not on a node basis.

Delegator: A delegator is an individual/entity who enters a delegation agreement with a validator. Validators can choose to accept delegation from delegators or choose to self-delegate.

Delegation Period: The delegation period is the duration delegation as chosen by the delegator. At launch, the delegation period was set at two (2) months, at which point delegators can choose to continue to delegate.

Un-delegation: Undelegation is the act of withdrawing from a delegation agreement with a validator. Undelegation must be requested by the delegator while delegating during an epoch. The recommended un-delegation request time is 7 days or more prior to the end of the epoch. Once delegation ends, delegators are able to withdraw their funds, including any earned bounties, from the validator. . (In the near future, undelegation_request deadline will be 3 days prior to epoch ends and this implementation will be on-chain.)

Bounty: A bounty is the earned reward per node that is registered in the network. During the initial epochs, each node that meets the SLA requirement will receive the same bounty amount i.e. bounty = rewards. The bounty includes inflation and, in the future, will include proceeds from chain subscription fees in addition to the inflation.

Commission Fee: The commission fee is set by validator and agreed to by each delegator as part of a delegator's delegation request and acceptance. It specifies the percentage amount that validators will take from the bounty payout awarded to the validator. This percentage value is taken into account during the bounty and payout calculations. The payout amount less the commission fee is then distributed to each delegator.

Node Creation Window: The node creation window is the first three (3) days of an epoch. Validators should register nodes within the node registration window in order to receive payouts in the next month. Node registrations that are made after the window are still permitted and will be included in payouts, except that payments cannot be withdrawn until the payout date two months hence.

Validator and Delegator Withdrawals

One hour prior to the end of an epoch (UTC midnight), validator commission fees and delegator bounties are calculated for the then current epoch such that at the end of the epoch they are made available for withdrawal by validators and delegators (provided a node has been registered within the Node Registration Window)

Withdrawals by validators and delegators are accessed via functions within the Distributor contract running on the Ethereum mainnet. Validators make use of the withdrawFee call to receive their earned rewards based on their commission fee whereas delegators make use of withdrawBounty to receive their earned delegation bounties.

Notes

• Note that WithdrawBounty and WithdrawFee can be called anytime for earned bounties. If the fees or bounties are available, they can be withdrawn at any time (that day or weeks, months, or even years later).
• The withdrawal amount is always the full amount available to withdraw (i.e. no partial withdrawals permitted). The withdrawal gas cost depends on the then current ETH gas price at the time of withdrawal..
• Both forms of withdrawals are a part of the Validator and/or Delegator workflows and are initiated by each validator or delegator at their sole discretion.
• Delegator withdrawals are currently on a validator by validator basis. (If a delegator delegates to 5 different validators, they then will need to perform 5 separate withdrawals.)

Delegation States

The following list denotes the state of delegation states for a delegator with respect to its validator. A smart contract drives the change of state using parameters and keying off actions of a delegator and/or the validator.

Proposed – Delegators proposes delegation to a validator.

Accepted – Validators accepts a delegation. The only reason that a validator may not accept the delegation is to provide the optimum bounty amount to their delegators. In the near future, validators will have an option to auto accept all delegations.

Canceled – If a validator has not accepted the delegation, a delegator has the option to cancel their delegation and delegate to another validator.

Delegated – All accepted delegations turns to delegated status on the first day of each month and stay in this status until the delegation period ends or un-delegation is requested

Undelegation Requested – The default behavior for a token holder on chain is auto-delegation. If a token holder wants to stop their delegation and does not wish to auto delegate, they need to request un-delegation. Delegators are unable to request this action prior to the start of the delegation epoch in question. (NOTE: The recommended un-delegation request time is 7 days or more prior to the end of the epoch.)

Completed – When a delegator requests an un-delegation for a specific delegation, the delegation turns to completed state upon the end of the specific delegation period.

Rejected – If a validator does not accept a delegation and if the delegator does not cancel it before the epoch starts, then such a delegation will be automatically rejected until the beginning of the next epoch. Validators do not have the ability to reject a delegation.

Delegation Full Complete Cycle

Delegation Rejected

Delegation that is not approved by the Validator will be rejected start of the epoch

Delegation Canceled

Delegation can be only canceled after the proposed state:

Node Registration and Withdrawal Timelines

A node needs to register for an epoch after the start of the epoch as it cannot register for an epoch prior to its start. The reason for this is a check is made at the start of each epoch to make sure the Minimum Staking Requirement has been staked. (Whereby a validator may have accepted a certain amount of delegations, the smart contact checks during the then current epoch to verify the delegations are in the "Delegated" status.)

Another important item to note is that nodes should register within the Node Registration Window in order to allow for timely fee and bounty withdrawals. Whereas the bounty calculations and distributions occur at epoch end, withdrawal dates are contingent on whether a node has been registered within the registration window.If a node is registered within the Node Creation Window (i.e. within the first three (3) days of each month), the validator bounty will be released the next month. If after the window, it will be released two months hence. By way of example, if a node joins on or prior to the 3rd of March, they would receive their validator bounty on April 1st. If they join on or after the 4th day of March, they would receive their bounty on May 1st.

Bounty Workflow Smart Contracts

A bounty is calculated and paid at the end of each epoch. At the completion of each epoch, each node makes a call to a SKALE contract on the Ethereum mainnet to initiate the bounty distribution to validators and then subsequently the delegators. (The method is called getBounty and is in the SkaleManager smart contract.)

This function calculates the node rewards and allocates themes to each validator and their delegators. Note that rewards are paid to the validator, not to the nodes. Withdrawal windows, however, are dependent on whether or not nodes have been registered within the Node Creation Window

After the bounty calculations are made, the appropriate bounty will be distributed to validators which in turn will trigger a pay out to delegators less the validator commission fee and the delegation amount (via a function within the bounty smart contract)

Reasons Why a Node Might Not Be Able to Initiate Bounty Call

Here are a few reasons why a node might not be able to initiate a bounty call. A node will keep trying every minute until the bounty call is successful (provided the node or underlying container are operable).

• The node is down,
• The bounty container is down,
• Not enough ETH is in the node to facilitate call transaction,
• The Ethereum endpoints are not working properly,
• If node is set in Maintenance mode.

Note that nodes cannot make a getBounty call during the Node Creation Window. If for some reason, a node is down for a lengthy period of time or for a reason above, cannot call the bounty at the end of an epoch, it should call getBounty only after the close of the next Node Creation Window.

Network Inflation

Below is a table that lists the network inflation for the SKALE Network. This inflation takes place in the form of SKL token issuance as determined and controlled by a contract on the Ethereum mainnet.

‍

‍

For more information about SKALE token economics please check out SKALE Validator & Delegator Token Economics by Conner Murphy.

Estimated Initial Epoch Bounties

Here are estimates of the bounty calculations for the most current epochs for validator nodes within the SKALE Network, as expressed in SKL tokens. Whereas there is a slight modifier in the payout calculations based on duration a validator stakes, these initial payouts do not make use of this modifier and instead pay validators on an equal basis. The Minimum Staking Requirement (MSR) at present is 20m SKL tokens.

‍Year 0: 385,000,000 SKL
Year 0 Per Epoch: 32,083,333 SKL

‍

‍

Sample Calculation SKL Rewards per Node

The calculation below takes into account network constants such as totalTokenSupply and inflationRate in combination with network variables such as numOfNodes and commissionRate to determine the number of SKL tokens that will be distributed across the validator set.

Please check here to calculate estimated SKL rewards you may earn from staking.

If we assume the commission fee is 10% and the numberOfNodes are 150, and all delegations have the same delegation period and have the same rewards multiplier, then we get the following output.

[After Fee Percent] = 1 - [10% commission fee] = 0.9
[Distribution Per Node Per Epoch] = 385,000,000 / Month#InAYear /
[#OfNodes] = 213,888
[Distributed to all delegators] = 213,888 * [After Fee Percent] = 192,499
[Expected Validator Fee] = 213,888 * [10% commission Fee] = 21,388

Example Bounty Distribution to Delegator:

‍

‍

Node Bounty Calculations

This equation details the algorithm that calculates the total amount of bounty in a particular epoch – including inflation – and then apportions the distribution of bounty per node for any validator. This equation also takes in the account the multipliers for longer delegation periods.

Two (2) month delegation durations are the current norm. When SKALE Network enables 6 and 12 months delegation periods, these delegations will receive more rewards compared to the delegators who delegate shorter terms.

B ⇒ total amount of bounty in particular month calculated by inflation algorithm + the bounties from previous month (bounty reduction or node leaving).
First year bounty is 32,083,333 per epoch

effectiveDelegations(validator(node)) ⇒ Total amount staked to a validator, with stake multiplier. When the SKALE network enables 6-12 months delegations with different stake multipliers the difference will appear. Validators with 6 and 12 month delegation will also receive a larger bounty.

∑ effectiveDelegations(v) ⇒ Total amount staked in the SKALE Network with stake multiplier.

[delegations(validator(node)/MSR] ⇒ Total node number that a validator can register in the network. This part is to make sure that a validator receives rewards for the staked nodes only. If a validator has 5 active nodes in the network from previous months but can only have 4 x MSR they will get bounty for only 4 nodes.

MSR ⇒ Minimum staking requirement to set up a node in the SKALE network.

At the end here is the simplified version of how bounty per node is calculated:

Example - Staking Multiplier Applied

Here is an example with two validators with similar delegations and staking multiplier but with different node counts.

‍

‍

Bounty Per Node - ValidatorA

Bounty per node equals 224,433.
Total rewards for the month is 224,433* NodeCount(2)  = 448,866

Bounty Per Node - ValidatorB

Bounty per node equals 213,746.
Total rewards for the month is 213,746 * NodeCount(1) = 213,746.

Example – Different Staking Rewards

This diagram explains the reason why validators should register nodes when they meet the MSR requirements.

Note that in the case of ValidatorD, rewards for 1 non-registered node will not be paid out or withdrawable by the ValidatorD but instead will be added to the next month rewards of the community rewards pool and shared with the entire network of nodes in the next months payout. Validators are responsible for registering their node in the network within the Node Creation Window (i.e. within first 3 days of each month).

‍

‍

Summary

The SKALE Network bounty distribution process is first triggered by nodes in the network but the actual calculations, inflation growth, and validator and delegator payout processes are performed by SKALE smart contracts running on the Ethereum mainnet. This structure lets SKALE inherit many of the security guarantees of Ethereum while still allowing it to offer the benefits of a truly decentralized Web3 cloud offering – namely increased transaction speed, faster transaction finality, and much lower transaction fees.

The transparency of these calculations and the validator and delegator bounties are also one more reason why a decentralized world is not just a nice thing to have but almost an inevitable one.

This article was written by Ebru Engwall, Director of Solutions Engineering along with data, algorithms, and insights provided by Dmytro Stebaiev, VP of Technology.

Additional Resources
Validator & Delegator Token Economics

Validator FAQ