Tech Support: Polycub double-harvest bug 'fix'

A lot of people have been hit with this bug because it is so easy to trigger. Basically if you 'harvest' two farms at the same time the contract will bug out and it becomes impossible to claim locked coins. I've already personally walked 4 people through this bug so I figured I'd just create this quick tutorial in case I need to walk anyone through it again.

When this bug happens to any particular wallet, that wallet is essentially permanently bugged, and can never claim locked tokens ever again. The best thing to do if you still want to claim locked tokens in this case is move the LP tokens to another wallet and farm on an unbugged account.

Of course at this point as yields decline it will be less and less worth it to claim locked tokens, so perhaps this post comes a little late. Still, many in Discord ask about this bug when it happens, and it's super annoying so it's worth explaining a bit more in detail.

https://polygonscan.com/address/0xef79881df640b42bda6a84ac9435611ec6bb51a4#readContract

In order to claim some of the tokens manually that are locked behind this bug (after moving LP tokens to a new wallet), go to the above polycub contract and scroll down to #12 and #13:

pendingLength is how we find out how many harvests are locked in the contract. These harvests seem to be stored on some kind of array starting with an index of 0 and ending with pendingLength-1

Paste your public address into pendingLength to find out how big the array is.

We can see that this wallet has a pendingLength of 5 after we hit the Query button. This means that the user has harvested 5 times without claiming locked tokens. In this case the locked tokens can't be claimed, which is exactly what the bug does. What we are looking for is which harvest is the bugged harvest before we move onto the next step.

As I said before, these harvests are stored in some kind of array (I don't know how Solidity works but that's irrelevant). An array of 5 is stored in five indexes: 0, 1, 2, 3, 4 (for a total of five slots). Non-programmers would ask why a list starts at zero instead of one, but you'll just have to trust me that there are many reasons why it is done this way that are well beyond the scope of this tech support.

Find the bugged harvest.

Move up one section to #12 (pending), input the same public key, and starting at index 0, find the bugged contract. It will usually be index 1 unless you harvested farms before the bug happened without claiming locked to clear the array.

You'll know you've found the bugged index when you see that the startBlock and endBlock point to the same block. Something about the way Polygon works makes this particular contract bug out when two harvests are claimed on the same block.

Once you've found the bugged index, click the Write Contract button at the top of the page or click the following link:

https://polygonscan.com/address/0xef79881df640b42bda6a84ac9435611ec6bb51a4#writeContract

The first thing we need to do here is turn the red dot green to signal that our wallet is connected to Metamask. Often times it takes two tries for some reason, and you have to click a disclaimer that this is extremely experimental and potentially dangerous to craft custom operations by hand. Luckily you shouldn't really have much (if any) liquid funds on this particular wallet so the risk is minimal. Plus the operation that we are signing is super basic. It's hard to imagine there being any problems in this particular scenario.

After you get the green light head down to #2 claim and set _claimLocked to true and _limit to whatever the bugged index was we found in the previous step. Again, in most cases it will be 1, but not always. Click the Write button. A custom Metamask operation should appear for you to sign.

If Metamask looks like this you made a mistake and the transaction will fail. Not only that it will destroy over $1 worth of fees, which is a lot of fees for Polygon. If Metamask says it will fail, trust that it will. If everything looks fine, sign the transaction and wait for it to confirm on chain.

Doing it this way only claims one of the indexes.
In this example we had 5 indexes to claim.

So you can repeat this exact same transaction 4 times (clicking Write 4 times and signing Metamask) using the same variables of true and 1 or whatever the bugged index was. Each time you do this it will decrease the number of indexes in pendingLength by one, until there is only one left (index 0). The bugged index will remain unclaimable, and you won't get that money until it unlocks in 90 days.

If you are unsure if you got them all, there is no harm is checking other indexes or repeating the beginning step to see if you got them all. Metamask will let you know if it's not a valid operation by jacking up the fee to the roof and telling you it will fail. Do not attempt any such operations. They will fail and they will eat up all the gas you pump into them.

Conclusion

This is a super annoying bug that's not going to be fixed unless the contracts get redeployed. There are so many other priorities on the table that I wouldn't expect that to happen. Luckily, there are a few easy ways to avoid this bug entirely. The first of which is to always wait for harvests to confirm before harvesting something else, or even better simply use the Harvest all button on the home page.

This Harvest all button has been reprogrammed specifically to wait until the current harvest has been confirmed before it moves onto the next one, which will avoid the bug entirely without anyone having to think about it.

Hopefully this information is useful going forward, although it will be nice when yields decline and it becomes less and less worth it to claim locked tokens in the first place. I've already personally helped four people through this process, and Khal went over it with me personally as well in Discord, so I figured I could help out a bit on the tech support angle, seeing as how the queue seems to be quite full in that regard.

Posted Using LeoFinance ^Beta