As most have noticed, the first launch did not go as planned. We have done a root-cause analysis of this issue. Below is the explanation.
The startBlock Variable
The masterchef contract has a startBlock variable which controls which block the pools will start earning rewards. The masterchef also has an updateStartBlock function where this variable can be updated (as long as farming hasn’t started yet).
Initial Start Block
When first initializing the masterchef, we did not know when we would have the website, vfat, and a few other things ready to start farming. Because of this, we set the start block for about 6-months out, knowing that we could always update the startBlock to be sooner with the updateStartBlock function.
Creating Initial Pools
To prepare for farming, we naturally created the first pools to people could stake their coins before farming started. This was the fatal flaw.
When a pool is created, it sets a pool-specific variable called lastRewardBlock.
We can see that the lastRewardBlock is set on the 3rd line. That line of code basically says: If the startBlock is in the future, then set lastRewardBlock to the startBlock, otherwise set it to the current block. This is what happened for all of our pools.
The lastRewardBlock Variable
This variable helps with the accounting of how much reward each user is owed. The pendingFox and harvest functions rely on this variable by computing how many blocks have elapsed since the lastRewardBlock.
As you’ve probably realized, if the lastRewardBlock is 6 MONTHS IN THE FUTURE, then it will say that nobody is owed any rewards yet!
And there is no way to update this variable on an existing pool, for good reason. It would mess up all of the accounting if the pool has already been launched.
Okay great, Why didn’t you figure this out BEFORE the launch?
This is a legitimate question. The main reason is that we didn’t make any actual code changes to the masterchef contract beyond changing “Fish” -> “Fox” in about 100 places. You can verify this in our PR against the PolyCat masterchef fork (see a few sample lines from PR below).
Because we didn’t make any real code changes and because the contract has the updateStartBlock function, we never even thought to test the case where you create a pool and then update the startBlock to be sooner than the first startBlock. So none of our unit tests or testing on test net caught this edge case.
Instead we have spent the vast majority of our time testing the code for our vaults, which is what we are the most excited to deploy. In our minds, the farming is just the setup for the real $FOX value proposition of creating vaults on Harmony!
Next Steps
We already have the fixes needed for this and are finishing some UI components for it. We are still on track for the Friday farming launch and we will have more updates on that later today.
Thank you!
