Staking Pools
zFi staking pools are forked from Illuvium v1 Staking, this documentation will cover the high level usage and architecture of the staking pools, as well as drawbacks and other considerations.
The changes made to Illuvium Staking Pools was generally removal of code and genericism of variable names. Chiefly the synthetic token creation was removed in favor of staking rewards only being in the base token which are distributed from an external wallet instead of being minted.
zStake consists of two contracts, the zStakePoolFactory and the zStakeCorePool which can be referred to as the "factory" and the "staking pool."
The factory has a parent relationship to the pools.
For a staking pool to operate it must be registered with a factory.
A staking pool is a contract which users may deposit a specific ERC20 token into (staking.) As long as the user has tokens staked in the pool, they will earn rewards based on how many tokens they have staked.
Each staking pool has a weight. Based on the weight of a pool in relation to the sum of all pools registered to a factory, it receives a proportion of the rewards.
At the factory level, a "reward per block" is set, and the "total weight" is derived from the weight of all staking pools.
At the pool level, a "weight" is set, and the "reward" is derived from it's weight in proportion to the factory's "total weight."
A "reward token" (ERC20 Token) must be set at the factory level. This is the token which all rewards are paid in.
There must be a staking pool which accepts the reward token. For instance if the reward token is "WILD" there must be a "WILD" staking pool registered to the factory.
When a user claims their reward for staking tokens, their reward is automatically staked into the staking pool for the reward token.
One of two things may happen when a user unstakes tokens.
When a user unstakes tokens that they staked (not tokens that were rewarded for staking,) the tokens are simply transferred from the staking pool back to the user.
When a user unstakes tokens that were a reward for staking, those tokens are transferred from a "rewards vault" to the user. The rewards vault is a wallet or contract that contains reward tokens for staking. The rewards vault must have approved the factory to transfer (ERC20 token transfer approval) the reward tokens on it's behalf for the system to function.
The staking pool requests that the factory transfer tokens from the rewards vault to the user on an unstake of rewarded tokens. This makes it so the rewards vault only needs to approve the factory to transfer tokens.
We have identified that the events emitted by zStake are lacking in some areas. Since zStake works with internal "deposits" it would be incredibly useful to know what stake/unstake events are affecting which deposits. Unfortunately the stake/unstake events do not emit deposit id, making it difficult to extract the deposit id (and impossible from unstake events alone.)
The deposit concept is confusing to some users and adds a layer of complexity which some may wish to avoid.