GDS Flash Loan Attack – Technical Analysis

GDS Flash Loan Attack Analysis Graphic
GDS was the victim of a flash loan attack on 03 Jan 2022

According to our monitoring of the blockchain, NUMEN Labs has discovered that at 12:21:14 AM UTC on January 3rd, 2023, the GDS project on BSC was the victim of a flash loan attack. This attack resulted in a total loss of $187,000 and caused the price of GDS currency to plummet.

The main reason for this is that the reward calculation in the code logic only considers weight, and does not take into account factors such as time. The team behind the project has now shut down the logic execution state.


Hacker address:

Attack tx:

Transaction Screenshot from bscscan

The attacker lent a large amount of BSC-USD through the flash loan platform, with sufficient initial funds, and then the attacker used PANCAKE to exchange BSC-USD for GDS. Then add BSC-USD and GDS to the corresponding liquidity pool to get a lot of lp-token. 

screenshot of the transaction information

The attacker deployed many contracts, each of which was the same. But he only called the transfer function of GDS, and the attacker transferred the previously obtained lptoken to the deployed contract. The attacker calls the withdraw function in the self-deployment contract, and the withdraw function calls the transfer function of GDS to realize the profit. 

screenshot of the transaction information 2

GDS is a BEP20 token contract (, But it has been modified. The transfer will call _transfer, and then _afterTokenTransfer will be called at the bottom. The from parameter is the address of the caller, that is, the address of the contract created by the attacker, which stores a large number of lptokens. 

The key code logic is that _refreshDestroyMiningAccount will be called in _afterTokenTransfer. Because the to address of the transfer is equal to the dead address. It will enter the first branch, and because isOpenLpMining is true at this time, it will enter the nested branch inside and execute _settlementLpMining. 

Code Screenshot 1
Code Screenshot 2
Code Screenshot 3

The parameter passed in by _settlementLpMining is from. I said before that a large amount of lp is stored in from. When calculating the reward (GDS), it is actually a constant * from’s lptoken holdings/lptpken total circulation. Therefore, the more lptokens in from, the more rewards. In the current function, _internalTransfer transfers the reward directly. 

About one hour after GDS was attacked (Jan-03-2023 01:01:28 AM +UTC), the project party called closeLpMining in the GDS contract, changed isOpenLpMining to false, and suspended the function. The detailed transaction is as follows.

Another point worth noting is that the attacker interacted with the Binance hot wallet 1 day and 16 hours ago, see the link for details.


The main reason why the project was attacked this time is that when calculating the transfer reward, only the weight of the lp token held by the trader is taken into account. Factors such as time were not considered, thus the attacker was able to exploit the loophole.

NUMEN Cyber Labs recommends that project parties do a complete code audit and testing before deployment. When calculating the reward, it is important to calculate the reward with various factors such as time and quantity. This will effectively help in avoiding flash loan attacks.

To seek our assistance in avoiding exploits such as these, contact us here. Our experts would gladly help work out the best possible solutions for your projects.

Numen Cyber Labs is committed to facilitating the safe development of Web 3.0. We are dedicated to the security of the blockchain ecosystem, as well as operating systems & browser/mobile security. We regularly disseminate analyses on topics such as these, please stay tuned for more!


More Posts