Full understanding of the ‘vulnerability’ incident
Here is a short article that everyone can understand about why we were considered as a ‘high risk’ platform, and how we dealt with it
The issue !
So basically everything began when polycorn.finance went through rugdoc.io scanner.
Our code was compared to a database of code used for rugs.
One of our function definitions matched a function definition used by PolyButterfly to rug and particularly one parameter called _lpToken :
To explain you in a few words, this function is responsible for updating an already existing farm or pool.
It’s very useful to change the allocation point if you want to give more or less rewards to a pool for example.
But in our case we also have this _lpToken parameter which allows us to change the type of the LP or the token that the farm expects.
That means for example we have an ETH/MATIC farm, we could have changed into an ETH/USDC…
So, I guess you wonder why the hell would we do that ?!
Well honestly this had nothing to do into our final code…
This was super useful for testing purposes as we could try multiple LPs using only one farm and just updating it to test new things. However, it should have been removed from our code before it goes to production.
So sorry about that, we understand that it doesn’t look very professional.
The real problem is, that this piece of code can be used in a malicious way that we did not know at this time.
PolyButterfly for example, used it to change the LPs expected by its farms, then injecting a high quantity of ‘fake’ LPs that only them own (for example fakeTokenA/fakeTokenB).
Then, they would change it back to the ‘real’ pair and withdraw the same high quantity of ‘real’ LPs (which of course belongs to users).
Doing and repeating this untill all funds are siphoned, resulting in a hard rug.
So basically your funds would be unsafe, if we had any malicious intentions, but keep in mind that only the dev team could do this trick.
No external exploit was possible using this piece of code.
This is why rugdoc.io quickly (and wisely) flagged us as ‘high risk’ !
And at this time our strategy contracts were also unverified, not due to our lazyness, but because polyscan had trouble with multi file upload… however strategy contracts were verified on another tool called https://sourcify.dev/.
So we received a double red flag 😵…
The fix !
We managed to fix our masterchef by wrapping it with another contract : https://polygonscan.com/address/0x89443c958d3d9a4324b4c9f1bffede77dea1a03c#code
So now we can’t interact with masterchef contract anymore, but we interact with the wrapper contract which is the new owner of the masterchef contract.
We were able to redefine the set function to always use the current LP or token type of the farm :
And in the meantime we also managed to make the polyscan multifile verification work (and now we will always deploy single file contracts…), so we did finally verify contracts !
Things were at last getting better !
Happy ending ?
After our efforts rugdoc.io removed the ‘High risk’ flag from their review, but stated that they could not spend more time looking at our smartcontracts (know that they did not receive any money for the time spent on our case), which is totally understandable.
They also can’t state that our contracts are nor safe nor malicious as we have a big part of custom and innovative code that would need some extra time to review (mostly with the draining part).
And this why our next step will be to get a full review by an audit firm, so we can hopefully claim that our code is safe and clean as expected !
Know that we are already in discussion with multiple audit firms !
