There’s no denying that the cryptocurrency space has been booming as a whole. And more recently, Decentralized Finance keeps stealing the spotlight. All metrics indicate that DeFi keeps growing at an ever-increasing pace through the last few months. More and more capital keeps flowing towards decentralized apps and the usage keeps increasing.
Binance Smart Chain sits at the center of this spotlight, boasting ever-increasing numbers of transactions and record-breaking value being transacted inside its system; now being among the first DeFi supporting blockchains. And developers have been losing no time seizing the opportunity to jump into this seemingly booming ecosystem. Plenty of new projects are released daily and many of them are met with sudden and meteoric success.
Recently many launched projects have encountered wild success partly thanks due to marketing and social media, especially TikTok and Twitter. It seems that the success of a project can correlate a lot with how much of a reach the token name achieves on those social media, inspite of sometimes having little to nothing going on in terms of fundamentals.
Fear of missing out under this pretense can be high for anyone seeking to invest in new projects of the space. The potential for quick profits some projects have shown for early investors can indeed seem very attractive, but with great potential also comes great risk. Indeed, many will jump onto new projects without having managed to do proper due diligence, hoping to be that one early investor that ends up profiting a lot by investing in early. But there actually are plenty of tricks developers of a project could pull off to cheat their users.
One of these tokens that might have started as a joke was SafeMoon. The concept was a simple spin-off of the so-called "reflect token" system. Basically implying that part of all tokens in each transaction would be "reflected", meaning that every user balance is calculated from the smart contract logic instead of being a simple counter. In practice, that means that when a transaction happens, a reflect tax is applied on it and the holder balances then increase accordingly.
SafeMoon's difference was that on top of the "reflected" tokens, another fee would be applied on each transaction and would go towards providing liquidity in Pancakeswap. It is however worth pointing out that this wasn't a unique feature, as it was also previously seen in existing projects on Ethereum. It's worth pointing out that after SafeMoon's release in a presale, the token's price has kept increasing at an impressive rate.
When SafeMoon launched, not much was revealed about the technical details in terms of how it was going to achieve what it promised. And in fact, one could say that a lot of the early marketing for the token was even misleading. SafeMoon was advertised as "anti-rugpull" and as having its liquidity locked for 4 years… And to this day the website of the project remains very ambiguous as to how the locks and burns happen. In this post we’ll look into how true the project’s claims are, but spoiler alert, as you might have guessed, there are some inconsistencies.
With the massive market capitalization that SafeMoon has amassed, the reflected fees that ended up being added in liquidity have also come to be worth a lot. One of the main issues with the whole project is that while users are lead to believe that the Liquidity Provider tokens (essentially the receipt for having provided liquidity) are in fact locked and inaccessible from the founders, the exact opposite happens.
Let's take a deeper dive at the code and dig into how SafeMoon actually works.
In simple terms, the wallet at which all the fees for providing liquidity are directed to is an "Externally Owned Address", basically an address which belongs to the project's developer. You can check that address for yourself by looking at the SafeMoon token contract to notice the owner value.
The logic of the code behind that contract is programmed to do the following:
- On every transfer, tax n% and send the SafeMoon token to the SafeMoon contract balance.
- On every transfer, check if the contract balance is above a treshold.
- If that treshold is met, market sell half the contract balance into BNB using the pancakeswap router.
- Add BNB + SafeMoon liquidity to the pancakeswap router, using the owner address.
That means that the liquidity tax gets directly transformed into LP tokens that are added to the dev wallet.
https://gist.github.com/3e3da80c2e83d2f6d0d46fd7ef5fd9c6
The above function does the market sell of half the contract SafeMoon balance.
https://gist.github.com/f578932146f68ceff1ec650a00b90733
The above function adds the LP tokens to the owner wallet.
So what's currently happening is that the address getting the fees could do anything it wanted at any time with the tokens it receives. The owner LP tokens balance will keep increasing and they have total control over it.
This had lead up to the owner raising up to 53% of all LP tokens. Smart contracts are immutaeble so SafeMoon owner will permanently receive all of the liquidity fees from SafeMoon's smart contract.
To mitigate risks, SafeMoon ownership could be transfered to a smart contract that could be programmed to handle funds securely only using predefined functions. This would be a particularly important factor in terms of security and trustlessness.
But this is not the only worrying part of SafeMoon’s smart contract. The smart contract’s owner also has total control over the percentage amount of fees that are part of each transaction, and could set them to any number. Which means that they could set the fees they receive themselves for adding LP to 100% any time they please to do so, which would allow them to cheat users out of the entire amount they try to send when trying to transact. https://gist.github.com/e872717c4278416d39daad89235529d7
These two function have no conditional to enforce a specific treshold
Additionally, the owner by default is excluded from the transaction fees: https://gist.github.com/3af7969bcf8939bc551e8307ca6e4596
The constructor excludes the owner address from the fees
Which anyone could easily verify on BscScan :
And of course the owner can add and remove anyone to the fees whitelist using the following functions: https://gist.github.com/2a9c0dfb0dc4e80410a64d91e80b00e1
And last but not least, the contract owner can also outright block all transactions, by setting this value to 0: https://gist.github.com/3928c25c59d6247f69f0383e59c76e53
The owner is immune to the above limit though: https://gist.github.com/9820a921ce1b5c69bc16e27a06636bc9
At the time of our investigation, the owner’s wallet was shown to hold more than 50% of the total liquidity.
This is particularly worrisome as the developers could essentially pull out the liquidity and market sell against any other liquidity provider with the coins that they had received from Reflection fees from users. This would have been a textbook example of a rug pull.
And even more so, the functions that would allow the token contract’s owner to completely halt transactions and up fees to 100% for anyone else could be the perfect setup for pulling an exit scam, preventing everyone else from selling while grabbing anything that gets transacted...
And if all of that wasn’t enough, the liquidity continues being added to the developer’s wallet directly, whereas they could have directed the LP fees on a smart contract that would handle this process trustlessly, or at the very least a timelock contract.
In this scenario, the owner would wait until he owns a substantial amount of the LP tokens.
- Owner changes the reflect fees to 0%.
- This means that the reflect tax is no longer being applied.
- Owner changes the liquidity fees to 100%.
- This means that everyone who's not whitelisted from fees is now unable to trade SafeMoon. Any transfer of SafeMoon would be sent to the SafeMoon contract balance instead of the recipient, which would then trigger the liquity logic.
- Owner removes his LP, and dumps SafeMoon.
- The holders are now powerless and watch the price go to 0. Trying to sell through pancakeswap requires 100% slippage, and any SafeMoon token transfer is sent to the owner contract.
While SafeMoon's team has apparently been very successfull at marketing their project, albeit a bit shady, it's clear that there are many major red flags in the project's smart contract code. In short, there appears to have been lack of willingness to make the project's smart contracts trustless, which should definetely raise the suspicions of potential investors, as in this particular case, the smart contracts leave users open to being exploited in several different ways by the project's developers.