SIP-1: Adopt and enforce an incentivised LP staking mechanism - Zen Garden
Motivation
This proposal suggests for the protocol to adopt and enforce smart contracts (specified below) that enable, facilitate and reward liquidity provision to the xHNR/FTM liquidity pair. This proposal shall aid in establishing deeper liquidity in the Spooky.fi AMM (automated market maker) liquidity pool. This shall by achieved by the protocol adopting an LP staking mechanism - called Zen Garden - to further bolster liquidity and further enhance utility avenues for the xHNR token. Overall, 5 000 000 xHNR tokens shall be minted and provided for the purposes of incentivising the proposed LP staking mechanism - Zen Garden and the tokens shall be utilised until the depletion of the proposed allocation, which is assumed to be approximately 365 days from its deployment. The reward issuance shall be represented on Samurai’s frontend in a simplified, understandable and non-deceptive manner - rather than providing a % APY return representation, the frontend shall display the potential returns in concrete, discrete xHNR token terms.
Specification
Introducing the Zen Garden.
The Zen Garden is a staking contract consisted of pools with targeted base staking tokens.
The first pool (which this proposal revolves around) is the FTM/xHNR staking pool which would allow its users to deposit spLP tokens in order to earn xHNR.
How does the Zen Garden work?
There are several important metrics which must be considered and taken into account:
Rewards per Block
Block Speed
Starting Block and Ending Block
Total Rewards
Pool Allocation
User Share Per Pool
Note: These variables have been slightly abstracted for the sake of easing the explanation. The real variables carry a slightly more technical naming convention in the Solidity code, which is visible below.
When the contract is first deployed, it is initialised with several parameters. Those are: Starting Block, Ending Block, and Total Rewards. Furthermore, the Block Speed is fully adjusted accordingly to Fantom Opera, which at the time of the proposal happens to be at 1 block per approximately 1.1 seconds.
The difference is taken between the Ending and the Starting Block numbers to determine the number of blocks between. The Total Rewards are then divided by the difference of the blocks between to determine the Rewards Per Block metric.
This metric is self-explanatory, as it is ultimately the number of xHNR which will be issued per new block.
Supposing that there is only 1 single pool for FTM/xHNR present with 100% Pool Allocation, therefore if the Rewards Per Block is 5 xHNR per block, then the FTM/xHNR receives all 5 xHNR rewards.
Inside this single pool, there is currently only one user staking 1 spLP token. Thus, this user shall receive all 5 xHNR rewards per each issued block, as there is no one else to split the rewards with. However, suppose that another user decides to stake 3 spLP. The Total Tokens Locked will now become 4 spLP (1 + 3 new tokens). Thus on the next block, the first user, who has only staked 1 spLP, will now earn 1/4 * 5 xHNR - i.e. the user’s rewards are now only 25% of what they were before. Understandably, user 1 can also decide to deposit more spLP tokens in order to increase their share in the respective pool and subsequently earning more xHNR per pool.
This may also be generalised to:
(user share per pool / total tokens locked) * rewards per block = user’s reward per single block
To find out the total xHNR earned, should the user never withdraw until the end, then:
(user share per pool / total tokens locked) * rewards per block * block difference = user’s total rewards
The issuance of rewards:
The rewards are computed using an updater function with dependencies mainly on the number of passed blocks since the last update. Hence, the smart contract keeps track of all the necessary variables, to be able to update these values precisely.
The updater function can be invoked manually, or better yet, it is automatically invoked on each deposit and withdrawal. Hence, if a user is depositing or withdrawing, the pending rewards will be automatically issued to them.
Note that the values may or may not be caught up in real time due to the discrete nature of the updater function invocations. Hence, it is possible that the displayed values on dashboard could be delayed by several blocks. However, the values will always be automatically and precisely re-adjusted and globally updated on which deposit or withdrawal, thus eliminating the need to manually track and invoke the updater function.
How to stake:
Firstly, acquire the amount of spLP tokens that a user wishes to stake from SpookySwap. Locate the liquidity pool for FTM/xHNR and proceed with the liquidity provision.
In Samurai Dashboard, navigate to the Zen Garden staking and approve the spLP smart contract
Wait for approval to fully finish and realise
Enter the amount of spLP desired to be staked
Click on deposit and approve the transaction
Wait for the transaction to be confirmed
Refresh the application and track the pending rewards in real time
To claim the pending rewards, either deposit or withdraw an arbitrary amount of spLP
Contract deployment:
The Zen Garden contract shall be deployed with the Samurai deployer wallet.
The parameters for the deployment will be:
5000 blocks ahead of the starting block, to prevent staking rewards front running and to ensure fairness
5 000 000 xHNR devoted for staking rewards
configuration of 77000 blocks per day according to Fantom Opera (1.1 seconds per 1 block)
The duration of the staking will be approximately 365 days (this will determine the ending block)
The rewards per block will therefore approximately be:
5000000/(77000*365) = 0.177904287 xHNR per block
As such, 5 000 000 xHNR shall also be minted by the deployer and deposited to the staking contract after the contract creation as an incentive to the proposed LP mechanism.
An appropriate frontend interface representation shall also be developed and deployed on app.samurai.financial to allow users to Approve, Deposit, and Withdraw with ease.
The proposed Solidity code / smart contracts:
https://ipfs.io/ipfs/QmUy8BgK7zXVL4ySKVD7V2UtFvbJJwiUGYShYeWP6kJGxS
Last updated