Staking protocol
The Blast platform employs a delegated staking protocol in which Node Providers act as validators and accept delegations from Delegators into their associated staking pools. The individual rewards are calculated and distributed to the existing active pools per epoch (e.g. on a fixed time interval).
All participants who are willing to join the platform and support their preferred networks with their knowledge and, of course, their nodes will be able to take part in a fair and well-thought incentivization mechanism based on the INFRA token. On the other hand, in order to ensure the quality of the platform and the best infrastructure services in the industry, Node Providers will also be required to have some skin in the game through staking. This will allow the platform to automatically maintain a high quality of service and self-regulate by rewarding the best-performing nodes while taking immediate actions against underperforming ones so that the end users will never be affected in any way.
You can read more about the Blast Integrity Protocol: what are the conditions under which nodes will get jailed and how their performance scores are calculated here.
Moreover, the Blast staking mechanism offers $INFRA holders and supporters the opportunity to delegate their tokens and receive consistent APYs thus participating in the advance of the entire Blast ecosystem.
In the following sections, we will describe how the Blast staking mechanism works and what are the potential earnings for each type of participant.
For the purpose of clarity, we define the following terms used to better describe the staking process within Blast platform:
- Staking - the process of locking up $INFRA by a node provider who is running an Active node within Blast and has created a corresponding Staking Pool
- Delegation - the process of locking $INFRA by a token holder on a specific Staking Pool that they don’t own with the purpose of obtaining an APY
- Staking Pool - structure capable of accepting stake deposits from its owner, Node Provider, and Delegators and attaching to a running node in order to earn $INFRA rewards for its contributors
- Epoch - a time period used as a reference for the calculation of rewards. Implicitly, the amount of time that needs to pass before new rewards become available
- Epoch duration: 24h
In order to create a Staking Pool and start the staking process, a Node Provider needs to have a corresponding active node registered within the Blast platform.
At the same time, a minimum of 5000 $INFRA are required as a base stake before a Staking Pool can be created.
The staking model within the Blast platform relies on the calculation of a total amount of rewards per epoch from which individual rewards are distributed to both Node Providers and Delegators.
At the end of an epoch, the protocol computes for each operative pool how much of its stake earned rewards that epoch (the earning stake of the pool) using the formula:
(1)
The enclosed variables are defined as follows:
: saturation cap for the earning stake of a staking pool
: total stake on the pool at the epoch (capped at
)
: pool owner’s stake at the epoch (capped at
)
: influence of pool owner’s stake over the earning stake
To encourage the onboarding of third-party nodes and the creation of more Staking Pools, the protocol enforces the saturation cap over a pool’s earning stake, roughly defined as:
saturation cap ≔ circulating token supply / desired number of nodes in the protocol (2)
Delegating to a staking pool is permissionless, but harmful to one’s APY if the saturation threshold has already been exceeded. Participants are more incentivized to spin up additional nodes and create new staking pools for them in order to optimize their own stake.
Once the earning stake of a pool has been determined, the protocol proceeds to computing its epoch rewards:
pool earning stake * earningStakeAPY, scaled down to the duration of the epoch (3)
earningStakeAPY is a global protocol configuration applied to all pools, it represents the maximum APY a pool can produce over its entire stake.
From (1) it can be inferred that the maximum earning stake is reached when the pool is filled up to the saturation cap and the entire stake has been deposited by the pool owner itself.
However, a pool owner is additionally rewarded for maintaining the underlying node by means of a commission fee percentage configured on the attached staking pool. The owner gets this share out of delegators’ rewards which further increases its APY, possibly more than filling the pool itself would.
The minimum stake constraint for creating a new pool along with the earningStakeAPY ensures that the absolute amount of rewards will have a support level and cover the infrastructure costs of the node provider, which in turn leads to a healthy economy for the entire ecosystem.
Yet, a pool’s rewards are subject to its node’s off-chain performance, which is measured by the integrity protocol. Each pool will have a performance coefficient, ranging from 0% to 100%, injected into its epoch rewards calculation:
pool epoch rewards ≔ pool epoch rewards * performance% (4)
Given that the infrastructure cost varies between different networks, the protocol will reward the pool owners, additionally to their commission rewards, a baseAPY at the granularity of the node attributes: network, chain (testnet or mainnet), node type (full-node or archive) and infrastructure type (cloud or baremetal):
* baseAPY for the particular node specs * performance% (5)
A delegator's rewards are proportional to its stake within the pool:
pool epoch rewards * (100% - commission%) * (d / s) (6)
where d is the stake of the delegator and s is the total uncapped stake of the pool
Stake required to create a Staking Pool: 5000 $INFRA
Undelegate locking period: 14 days
Rewards claim frequency: at each epoch (24hrs)
Note: A Staking Pool owner will be able to stake an amount higher than required, but they can undelegate only down to the minimum limit of 5000 INFRA. In order to undelegate all tokens, an owner will have to close the Staking Pool which also causes the related node to be deactivated.