Staking BRIK, Receiving BRIKI
Overview
In order to protect the liquidity of BRIK in the early stage of the project, we incentivize token holders to deposit their BRIK into our Staking Pool, which seals your tokens but helps grow the volume every day until you wish to withdraw them.
Sealing money still sounds like killing its utilities? Don't worry, we replace such utilities by returning to stakeholders the exact same amount of another derivative 17 tokens, called BRIKI, as the amount of BRIK has been staked. This BRIKI can be used like an ordinary ERC-20 token to transfer the capability to withdraw staked tokens from the Staking Pool. Moreover, the balance of BRIKI will grow daily as the corresponding volume of BRIK will grow inside the pool as well.
Concisely, interactions with the Staking Pool can be described shortly:
Any user can stake their BRIK into the Staking Pool, implemented as a smart contract. These amounts of BRIK will be locked, while equivalent amounts of BRIKI will be transferred back to the corresponding stakeholders. These BRIKI can be spent with a liquidity rate of 1:1 with BRIK.
Every single day within 3 years since the pool starts rewarding (right after all auctions end), 14 million BRIK will be issued into the Staking Pool, while the same amount of BRIKI shall be issued to all stakeholders' balance, directedly and proportionally to their shares.
Any stakeholder, or in other words, any BRIKI holder can withdraw their stake in BRIK and burn an equivalent amount of BRIKI.
The Mathematics Behind
On day , the BRIK contract will be triggered to issue a predefined tokens into the Staking Pool contract. These tokens will be shared among stakeholders correspondingly to their share within the total value locked inside the pool. The stake inflation of each stakeholder is proportional to every other, and also to the inflation of the whole pool.
Simple scenario
Consider an arbitrary BRIK holder who would like to stake exactly once with tokens on the -th day since the Staking Pool deployed. Today, the -th day , his stake will increase following the traditional Compound Interest formula:
A formula like this is impractical to implement on smart contracts, due to its loop of multiplication can grow enormously while the gas being charged on the complexity of the called function.
It requires to proceed a few more transformations. Let to be the accumulated product of all daily interest rates from day to day :
The value of can be calculated easily and only once every day as to being stored globally. With , we can simplify the first formula:
General Scenario
Now, consider staking multiple times. Due to the reward of each occurrence of staking being independent, the whole stake simply is the sum of all singular rewards. Generally, on day an address that has staked different times will possess the total stake:
To this point, the formula has become more clean for implementation. The input parameter has been isolated from the loop while the rest can be easily precomputed and stored. Therefore, it is possible to create functions to update individual stake values by individual stored factors or to update the whole group of stakeholders through some global values, each with a complexity of .
This formula of compound interest has created a dynamic-balance token for 2 reasons:
When rewards are sent to the staking pool, the balance of all holders will be increased, only by updating the accumulated product.
When rewards are sent to the staking pool, the relative ratio between each pair of holders remains the same.
To protect the value of the system from early unstaking, we will charge the unstaking holder some fee which is equal to a specific percentage of unstaked amount. The fee rate is implemented to start at 50% and reduce to 0% after 3 years. All the fees will be included in staking reward to be shared among the remaining stakeholders
The Staking Pool will start rewarding after all auctions are finished. To prevent value loss from inflation, token allocated to Core Team, External Treasury and Market Maker will be staked right after the system deployment.
Last updated