Hyper-SAFU

9 min readJun 10, 2021

We’ve always endeavored to provide a safe environment to our community. Now we show you exactly what makes us different.

We have held off on publishing an article about the recent Flash Loan Exploits occurring on BSC and how we were safe. We have watched other projects post fluff pieces about being safe “because we are an exact copy of some other contract”. But that’s not what we wanted to present. We are different, our DEV team is different, we have made changes to the contracts. Changes that, we will show below, have made our community safer.

Everyone knows that the writer of these articles is too old to understand technology, let alone code, so I had to go out on a mission to learn about these exploits and how they occur, and what makes our project different. Being old means I am also slow, so it took some time for our DEV team to answer all of my questions, point out articles for me to read, and dumb it down enough for a geriatric to understand.

So let’s dive in.

What is a Flash Loan?

In the simplest terms, a Flash Loan is a loan that is borrowed and paid back in the same transaction. A user borrows funds, uses them for something, and then returns the funds, all within one block of chain data.

The general idea is that Flash Loans can be used by savvy traders to take advantage of an Arbitrage opportunity. When the trader sees a price discrepancy between two exchanges, a Flash Loan allows them to take maximum advantage of the price difference by borrowing funds to buy a larger amount of the token than they would have been able to acquire otherwise, immediately sell them on the second exchange with the higher price, pay back the loan and walk away with profit.

While, to many people, this may sound unethical, it is actually a practice that is relied upon by the AMMs to keep pricing stable across the various platforms. Arbitrage is considered a legitimate trading strategy and using a Flash Loan to maximize those opportunities is not considered malicious.

Coin Telegraph, which is full of much more established writers and researchers than myself have put together This Article defining a Flash Loan and its use cases if you would like to read more on the issue.

Exploits by Flash Loan

So if there is nothing wrong with a Flash Loan, why do we keep hearing about Flash Loan Attacks? Frankly, because it is easier to say “Flash Loan Attack” than it is to define what actually happened.

The Developers I have spoken with estimate that 90% of the Exploits that have taken place utilizing Flash Loans do so through one of two methods.

Oracle Exploits
Reentrancy Exploits

So let’s take a look at each of these exploits, and define how HyperJump keeps you safe from them.

Price Oracle Exploit

These exploits can take place when an AMM (or DEX) uses one centralized source of pricing to set their token prices. In these instances, the AMM relies solely on their own pricing, in real time, without taking any other price data in to consideration.

The attackers take advantage of this lack of outside pricing data to manipulate the price of a particular token creating what is effectively an Arbitrage opportunity without needing to use a second exchange.

Glassnode Insights lays out the Price Oracle exploit better than I can in the linked article, stating:

In such events, attackers essentially create artificial arbitrage opportunities by instantaneously borrowing, swapping, depositing, and again borrowing large numbers of tokens. This action exploits a vulnerability in certain price oracles, which leads to a target token’s price being artificially moved on a single exchange; a disparity which can then be arbitraged.

They later go on to explain:

Once an attacker has manipulated the price of an asset on the target DEX, they can then “trick” the protocol which relies on its price feed into allowing the sale or purchase of assets at above or below market price, at the expense of regular users.

The Glassnode Insights article finishes with an in depth look at the Cheese Bank exploit of 2020, with a step by step description of how that exploit took place. I encourage interested parties to go and read that article in full to better understand this sort of attack.

The way to protect the community from having funds stolen via a Price Oracle Exploit is to utilize an Average Price Oracle. This method resolves pricing during each function, ensuring that the price moves with each swap, or to use a third party Decentralize Price Oracle.

Services, such as Chainlink, Band, and others offer an Average Price Oracle to exchanges to utilize as part of their AMM.

Hyperswap utilizes code in our own contracts to update the reserves on every mint/burn/swap call. The AMM is its own price oracle, which updates the reserve before leaving the function, averaging the prices, and making a Price Oracle Exploit unprofitable.

Our code can be found in the Thugswap Factory Contract at line 290. Remember, we still utilize the Thugswap contracts and simply migrated to the new HyperJump branding and front end.

Reentrancy Exploit

When Burgerswap was hit a couple of weeks back, it was not a Price Oracle Exploit, but rather a reentrancy. This one is a little tough to explain, so I’m going to mostly borrow from smarter people here.

Coinmonks defines a Reentrancy as:

A reentrancy attack can occur when you create a function that makes an external call to another untrusted contract before it resolves any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the effects were resolved.
This simplest example is when a contract does internal accounting with a balance variable and exposes a withdraw function. If the vulnerable contract transfers funds before it sets the balance to zero, the attacker can recursively call the withdraw function repeatedly and drain the whole contract.

In the case of the BurgerSwap Exploit, the entry was via the creation of a new token pair. The exploiter created a fake token and then created a liquidity pair with Burger on Burgerswap. As explained by Developer Purple Zky:

if during a swap transaction, your fake token instead of only giving balance during swap, you buy/sell tokens to manipulate price during swap transaction
you can get more out than went in.

Going back to a different article from CoinMonks, this manipulation can be run effectively in a loop, removing more funds from the AMM until there are not enough funds left to complete the contract call, and it stops.

Following are the execution steps when call function attack() of this contract: Step1: attack(),
Step2: deposit() with 1 ether on EtherRentrancy contract;
Step3: withdraw() function of EtherRentrancy contract;
Step4: withdraw() function, in turn, will call the receive function of HelloBreaksLoose;
Step5: receive function will again call the withdraw() function;
The last two steps — Step 3 and Step4 — will run in a loop until EtherRentrancy has a balance of less than 1 ether.

Coinmonks continues with two alternatives that Solidity Developers can add to their contracts to protect against this sort of exploit. In the Thugswap Contracts we include his second method:

2. Using a modifier blockRentrancy: the idea is to lock the contract while any function of the contract is being executed, so only a single function in the contract can be executed at a time.

This can be found starting at line 248 of the Thugswap Pair Contract.

FTMScan is not quite ready for prime time and allowing us to show the contracts on the FTM side, but they are exact duplicates of our contracts on the Binance Smart Chain, meaning that both of these exploit protections are included on both chains.

Summing Up

We fully recognize that there are many bad actors in this space. It has been our intent, from the very beginning, to make our dapps and services as safe as protective as possible. We can’t claim to be 100% unexploitable, no one can, and this is certainly not an exhaustive list of ways that an exploit can occur.

Our hope is that this article helps the baseline user understand what has happened in the recent Flash Loan Attacks, why it is an error to refer to them as Flash Loan Attacks (As opposed to Price Oracle Attacks or Reentrancy Attacks. The Flash Loan is just Leverage), and what HyperJump has done to protect our project from such attacks.

There is a Radio Advertisement that plays where I live from an IT outsourcing company that says something to the effect of “Your IT Security Team has to be right all the time, the hacker only has to be right once.” The same applies to Smart Contract Developers. HyperJump is committed to continuing to seek out and hire the best Developers with the goal of providing safe, effective, and entertaining product for our community to enjoy. We move slower than some of the other guys, but we do so with a vision and purpose in mind. Key to that vision is fund safety. We keep our funds here too.

Evolving Exploiters

Of course right before publication, another project was exploited on BSC and I needed to take some time to check out what happened and add a post script to this article to address it.

Evolution Defi uses NFT to boost farming yield. A quick review of this exploit seems to indicate that the exploiter used a Flash Loan to exploit a logic error in the NFT boost contract to borrow a huge sum of GEN, Boost the farming, then drain the farm.

PeckShield provided the following image on twitter to show the bug in the code which allowed the exploiter to run up their bonus and collect roughly a million dollars worth of GEN tokens before selling the extra GEN and repaying the Flash Loan.

This is an important exploit to note since NFT are part of the HyperJump roadmap, and boosted farming is in discussion. We will be vigilant as we move forward with those plans to ensure that we don’t leave logic errors behind for exploiters to take advantage of.

Again, the Flash Loan here is the leverage with which the exploiter got the funds to take advantage of a error in the contract. The Flash Loan itself is not the exploit, the logic error is.

A Note of Thanks

While many minds from the Hyper Team went in to the research and composition of this article, I did outsource some of the contract checking to our friend Purple Zky, Lead Project Developer for Bolt Dollar, who assisted with explaining the different exploits and went through contracts to help me pull the relevant code for this article. Without his help, this article might have been another month in the research. Thanks Purple!

Invest with the Crew!

We hope that we have provided some useful information that helps you understand what makes us different from other projects that have come and gone over the last eight months in this space. If you are convinced, and don’t already own one or more of our tokens, maybe it is time to pick some up.

Binance Smart Chain

Fantom Opera Chain

Join the HyperCrew

You know what to do next. Come join us on our many social channels for more information and to have your questions answered. We love welcoming new members of the Crew to our project!

The Good Stuff

BSC Swap — https://swap.hyperjump.fi/#/swap

Fantom Swap — https://ftm-swap.hyperjump.fi

Fantom Analytics — https://ftm-info.hyperjump.fi