Higher APY, Accurate APY ($MAGMA Staking)
It might not be easy to catch, but a standard fork of farms with any form of harvest lockup would lead to inaccurate APY for native single staking, due to inaccurate measurements of your share of the pool. Long story short, with the given emission rate, your APY for single staking native pool should NOT be as low as advertised, and it is due to the locked reward tokens that lead to this discrepancy. There's no need to fear, however, as the team at MagmaCake Finance managed to pinpoint this particular issue, and successfully solved it! So, you'll be getting the actual and accurate APY for the single staking native pool, which is far far higher than what you would be getting from a normal harvest lockup fork! We'll be going through the technical details below, if you're interested in finding out why!
Technical Details / Proof
Our $MAGMA single staking pool has actual accurate APY on it. How is the APY of a pool calculated? It is calculated based on the total balance of that specific token in the MasterChef.
As for pure LavaCake forks that have a collective lockup period, there would be a lot of native tokens minted that are 'locked' within the MasterChef, but are not actually staked by native farmers. Those extra minted native tokens are the locked rewards. Hence, they should NOT count towards the total balance of the native token in the MasterChef, as that would significantly reduce your share of the reward pool.
However, pure LavaCake forks do not take this scenario into account, and as a result, the native single staking pool's APY goes to shit even though the actual amount staked in it is not nearly as much as advertised.
This is all a bit confusing, so I'll show you in code to help you understand it better.
As you can see, on the normal version of updatePool, on line 1916, the lpSupply is defined to be the balance of the particular token in the MasterChef contract. However, as stated above, since the reward tokens are minted to the MasterChef during the harvest lockup, the balance of the native token in the MasterChef would be heavily inflated. For example, if there are X native tokens actually staked in the MasterChef, and Y native tokens minted as reward, but are locked up, then the balance of native tokens in the MasterChef would be X + Y, although the real staked tokens are only X. Compare it to the MagmaCake's version of updatePool, and you would see that from line 206 to 208, we first check if the token of the pool we are updating is the native token. If it is, then instead of using the standard method of using the lpSupply as the balance of the particular token in the MasterChef contract, we use a variable called pool.amount, which stores the actual amount of tokens staked. As a result, using the example above, it would accurately fetch that there are only X staked native tokens. What are the repercussions of doing so? As you might know, the amount of reward tokens you get for staking depends on your share of the pool. Take for example the normal version of updatePool, and let's assume that you staked 10 tokens in that native pool. Your share of the pool would then be 10 / (X + Y), which is NOT accurate as there are only X real staked tokens. MagmaCake's version of updatePool would however, calculate your share of the pool accurately, which is 10 / X, and as you can tell, the accurate calculation of your share of the pool would lead to a higher APY for all native stakers! *updatePool: This is a method called in the MasterChef contract whenever anybody deposits or withdraws tokens, and in short, it would calculate how much reward tokens to be given out to the particular pool. Sorry if this explanation is long-winded and confusing. If you're still confused, do head over to our Telegram group and ask more questions about it, we would gladly answer it, although do please take some time to digest it!
Last updated
