Diving in to the Certik Audit of HyperJump

8 min readMay 29, 2021

So we finally got our Certik Audit completed and the report is out. Let’s take a little time to dive in to the results and see what they said, Our response, and try to put it in language that non-technical users can understand.

First, let’s take a high level look at the report as you find it right on the Certik Page. This is where most people are going to stop anyway, so let’s examine.

At first glance, this could look pretty scary. Twenty-three problems found? Yikes!

But when you dive a little deeper, it becomes much less dramatic. See those Green Check Marks on the right? That means those issues have been resolved by the project and are no longer “problems” in the code. Both of the “Critical Findings” were resolved.

Informational findings have absolutely nothing to do with the security of the project for the end user, and everything to do with how other coders read the contract. If you browse through other reports on Certik, project after projects has tons of informational findings. We can safely pass over these findings as inconsequential to the end user.

If you would like to dig in to the Informational findings, simply open up the PDF Report and you can read the findings as well as the Project reasoning for either implementing or not implementing the recommended fix.

So let’s take a look at what they did find that we either addressed or chose not to. Because at the end of the day, that is what we did. No one is without flaw, and our developers disagreed with the Certik findings on some of their issues, so we will endeavor to go through our reasoning for why the “problems” discovered are not issues at all. This is not an argument to get Certik to change their scoring, we already went down that road, this is just for our community to understand why we are comfortable with these issues remaining “unresolved”.

HBH-07, HCH-11 & HCH-15 | Centralized Risk

One Major and two Critical finding for literally the exact same thing. I post all images here so you can compare and see that they are duplicates.

Certik recommended the team “carefully manage the project’s private key and avoid potential risks of being hacked”. Well… okay. Since the project relaunched as HyperJump the people in charge of our private keys have been beyond reproach with a proven track record of accounting for every penny. But we get it, a lot of projects are running away with user funds.

The solution chosen here was to deploy a 24 hour timelock. It has been our constant assertion that timelocks will not stop an attack from occurring, and in many cases can even delay the developer team from making quick and effective patches to secure the project should an exploit be found. We understand that for most non-technical users, there is comfort in knowing a timelock is in place, “timelock” sounds secure, so we have implemented this resolution.

This does not come without some minor annoyances. We now must enable new farms and pools 24 hours before they can go live on the site. We will be working with our farm/pool partners to try to ensure that we keep a steady flow of new options for you to earn yield from, but the occasional hiccup while we deal with the timelock will be expected.

HCH-04 | add() Function Not Restricted

The Premise of this finding is that it is hypothetically possible for a user to create a duplicate pool in the farms, thus throwing off the reward calculations.

While we have agreed to implement the fix recommended in the next version of our contracts, we do not see this as an issue, and has not been an issue for the six months that we have been running our Yield producing products.

HCH-07 | Over-Minted Token

This one is really about semantics. Every project diverts a portion of the block rewards (newly minted tokens) to the Dev wallet. This is used for development, marketing, and project expenses. If you have questions regarding how many tokens are minted per block, and how they are allocated, we can lay it out precisely in a future publication. The bottom line is that a small portion of the newly minted tokens goes back to the team, this is industry standard and happens with all projects.

HCH-08 | Incompatibility with Deflationary Tokens

LP Tokens are not deflationary. Period.

Our Farms are clearly labeled where there is a deposit fee, aside from this fee, you will always remove the same amount of LP token as you put in (minus fee). Some tokens have a burn mechanism that triggers when creating and/or breaking LP tokens, (HYPR being a prime example), however this function is not triggered on the LP token itself, nor while in the farm, only when the end user manipulates the LP token. Users must do their due diligence to understand the burn mechanisms involved in the tokens they are utilizing.

In this instance we acknowledge that Certik feels there is an issue, and we contest it is a non-issue. No fix implemented.

HCH-09 | 20201103 pancakeswap hack

If this one wasn’t so aggravating we would be laughing. For those who are new here, the pancakeswap hack in question occurred on November 3, 2020. At the time, users could swap their CAKE for SYRUP which was then used in their SYRUP pools. Exploiters were able to work around the contract to create an infinite number of SYRUP tokens, which were also being bought and sold on the exchange. The exploiters unloaded this SYRUP on the market, crashing the price of SYRUP.

Since HYPERJUMP (At the time THUGS) is a fork of the same code as Pancake, MECHS were vulnerable, and in fact a small number of MECHS were created by the exploit before we were able to shut it down.

PCS and Hyper went two different directions with the patch of this exploit. Pancake got rid of SYRUP entirely, and now have you stake CAKE in their pools to earn the reward token. Our team patched the exploit so that we could continue to use MECHS for double rewards.

Conclusion — this finding is a non-issue and has been a non-issue since November.

HCH-12 | Lost of User Assets

This finding refers to the one way migration from DRUGS tokens to ALLOY tokens. The conversion tool is still a part of our code, as any DRUGS still out there can still be converted to ALLOY. The potential amount of loss to the user is a maximum of 0.000000000000000009 DRUGS tokens. ALLOY would have to reach a price in the millions of dollars for this amount to even remotely become significant to anyone.

Again, this is a non-issue.

Summing it up.

So in Summary…

2 Critical Findings — Actually 1 Critical finding repeated. Addressed by Timelock. Certik agrees. Current Critical Findings — 0.

3 Major findings — 1 is again a repeat of the two critical findings, resolved. Pancakeswap Hack finding resolved months ago but not acknowledged by Certik. Duplicate LP issue not recognized by Dev team as an issue. Current Major findings at issue — 0

0 Medium Findings

3 Minor findings — 2 are easily refuted but not withdrawn by Certik and the final one we believe we are following industry standard. Current Minor findings at Issue — 0

15 Info findings — DYOR on these. Again, they have these on every project, we don’t have the time or inclination to go through each one.

This is a terribly long winded way of saying that your funds are SAFU. We always have held user fund safety as our primary objective. We believe this audit confirms what we already knew, our code is solid and as safe as is possible.

We do have to, of course, acknowledge that our devs are human, and humans are prone to mistakes. Could there still be areas where a hacker/exploiter could take advantage of our project? Of course. But our goal is to always be one step ahead of the people trying to steal other people’s funds. We are as safe as we possibly can be.

Our community has asked for a Certik Audit, we have delivered that audit. We will be adding the Audited by Certik tag to our web presence and hope that this gives our community the peace of mind that they may have been missing.

Not Included

We’ve kept you long enough for one day, but we do want to make note of one pressing issue that is not addressed in this audit. No Audit is going to address the recent “Flash Loan” attacks. We will be creating a new medium in the coming days to address Flash Loan attacks and what Hyperjump has done to mitigate this issue on our project. Stay Tuned!

Join the HyperCrew

As always, we encourage our community to join us in our social media channels where we do our best to address any questions or concerns. We don’t have all the answers, but we sure do try. We’ve also been told we can be somewhat entertaining. So at least we have that going for us!