After literally having audited more than 100 Masterchef and Staking contracts, it’s time to share my knowledge with you, specifically the reward algorithm.
The goal here is to demystify it by focusing on one of its core concepts: The accPerToken variable. Understanding this will illuminate how rewards are calculated and distributed in a way that's both fair and efficient.
Understanding accPerToken
At the heart of the MasterChef contract is the accPerToken variable. This variable plays a crucial role in tracking
"the amount of rewards allocated to each token staked in a pool"
It ensures that rewards are distributed proportionally to the amount of liquidity each participant provides.
To simplify, imagine that Alice has staked 100 tokens in a pool. If the reward rate is set to 1e18 tokens per second, after 100 seconds, a total of 100e18 tokens will be distributed among participants as rewards. (Alice is the only participant at this moment)
Here's where accPerToken comes into play:
Time Passed: 100 seconds
Rewards Generated: 1e18 * 100 = 100e18 tokens
accPerToken: 100e18 (total rewards) * 1e18(multiplier) / 100e18 (total staked tokens)
The calculation inflates accPerToken by 1e18 to avoid rounding issues, ensuring precision in reward distribution but the main logic is to simply just calculate how many rewards each nominal token receives.
When calculating a user's reward, this inflated value is divided back by 1e18 to get the accurate reward amount:
User Reward = user.amount * accPerToken / 1e18
Key Points to Remember
Pool Updates: It's vital to update the pool and increase accPerToken with every balance change or interaction. This ensures that the reward distribution remains accurate and up-to-date. If this is not done accurately, the algorithm will be flawed.
Claiming Rewards: When users change their balance (by adding or removing tokens), they must claim their accrued rewards. This step is critical to prevent manipulation of the accPerToken system. After claiming, the user's rewardDebt is updated, which tracks the amount of rewards already paid out to ensure correct future payments.
These interactions, together with the correctness of the accPerToken variable increase lay the fundamental principle of the Masterchef reward algorithm. If there is any discrepancy, the logic is most likely flawed.
Understanding the accPerToken variable is essential to grasp how rewards are calculated and distributed using the MasterChef contract.
It ensures that rewards are allocated fairly based on the amount of liquidity each user provides to the pool. Remember, updating pools and claiming rewards are pivotal actions to maintain the integrity of the reward distribution mechanism.
I hope this explanation sheds light on the inner workings of the Masterchef reward algorithm. It's designed to demystify the process and make the concept accessible, especially for newcomers. If you have further questions or need clarification on any point, feel free to ask!
Attached below is an example from @TraderJoe_xyz written by @Louis_Mslf
The only difference is that this is using some other variable declarations but the logic is 100% the same.
The goal here is to demystify it by focusing on one of its core concepts: The accPerToken variable. Understanding this will illuminate how rewards are calculated and distributed in a way that's both fair and efficient.
Understanding accPerToken
At the heart of the MasterChef contract is the accPerToken variable. This variable plays a crucial role in tracking
"the amount of rewards allocated to each token staked in a pool"
It ensures that rewards are distributed proportionally to the amount of liquidity each participant provides.
To simplify, imagine that Alice has staked 100 tokens in a pool. If the reward rate is set to 1e18 tokens per second, after 100 seconds, a total of 100e18 tokens will be distributed among participants as rewards. (Alice is the only participant at this moment)
Here's where accPerToken comes into play:
Time Passed: 100 seconds
Rewards Generated: 1e18 * 100 = 100e18 tokens
accPerToken: 100e18 (total rewards) * 1e18(multiplier) / 100e18 (total staked tokens)
The calculation inflates accPerToken by 1e18 to avoid rounding issues, ensuring precision in reward distribution but the main logic is to simply just calculate how many rewards each nominal token receives.
When calculating a user's reward, this inflated value is divided back by 1e18 to get the accurate reward amount:
User Reward = user.amount * accPerToken / 1e18
Key Points to Remember
Pool Updates: It's vital to update the pool and increase accPerToken with every balance change or interaction. This ensures that the reward distribution remains accurate and up-to-date. If this is not done accurately, the algorithm will be flawed.
Claiming Rewards: When users change their balance (by adding or removing tokens), they must claim their accrued rewards. This step is critical to prevent manipulation of the accPerToken system. After claiming, the user's rewardDebt is updated, which tracks the amount of rewards already paid out to ensure correct future payments.
These interactions, together with the correctness of the accPerToken variable increase lay the fundamental principle of the Masterchef reward algorithm. If there is any discrepancy, the logic is most likely flawed.
Understanding the accPerToken variable is essential to grasp how rewards are calculated and distributed using the MasterChef contract.
It ensures that rewards are allocated fairly based on the amount of liquidity each user provides to the pool. Remember, updating pools and claiming rewards are pivotal actions to maintain the integrity of the reward distribution mechanism.
I hope this explanation sheds light on the inner workings of the Masterchef reward algorithm. It's designed to demystify the process and make the concept accessible, especially for newcomers. If you have further questions or need clarification on any point, feel free to ask!
Attached below is an example from @TraderJoe_xyz written by @Louis_Mslf
The only difference is that this is using some other variable declarations but the logic is 100% the same.
