Can You Trust SafeMoon?

7 min readApr 21, 2021

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.

Great Success, but What About Due Dilligence?

Recently many launched projects have encountered wild success partly thanks due to marketing and social media, especially TikTok and Twitter. Clearly, the success of a project can correlate a lot with how much of a reach the token name achieves on those social media, which leads to projects owner putting more effort into marketing than they do in having high quality and safe smart contracts.

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. And in fact, 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.

The Case of SafeMoon

One of these successful 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.

SafeMoon, Maybe Not so ‘Safe’ After All…

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.

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.

The Many Red Flags in SafeMoon’s Code

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 threshold.
If that threshold 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.

The above function does the market sell of half the contract SafeMoon balance.

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 immutable so SafeMoon owner will permanently receive all of the liquidity fees from SafeMoon’s smart contract.

To mitigate risks, SafeMoon ownership could be transferred 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.

These two function have no conditional to enforce a specific threshold

Additionally, the deployer by default is excluded from the transaction fees:

The constructor excludes the deployer address from the fees

Which anyone could easily verify on BscScan:

Edit: Note that while the deployer isn’t the current owner, it is still an EOA under the control of the development team.

And of course the owner can add and remove anyone to the fees whitelist using the following functions:

And last but not least, the contract owner can also outright block all transactions, by setting this value to 0:

The owner is immune to the above limit though:

At the time of our investigation, the owner’s wallet was shown to hold more than 50% of the total liquidity (since then the owner LP was transferred to a UniswapLocker contract until 2025).

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 is the perfect conditions to pull the rug under the users feet.

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.

Finally, the liquidity continues being added to the developer’s wallet directly, whereas they could have directed the LP fees to a smart contract that would handle this process trustlessly, or at the very least a timelock contract.

Worst Case Scenario

In this scenario, the owner would wait until he owns a substantial amount of the LP tokens.

1. Owner changes the reflect fees to 0%.

This means that the reflect tax is no longer being applied.

2. 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 liquidity logic.

3. Owner removes his LP, and dumps SafeMoon.

The holders are now powerless and watch the price go to 0. Trying to sell through PancakeSwap which would now require 100% slippage, and any SafeMoon token transfer is sent to the owner contract.

Conclusion

While SafeMoon’s team has been very successful at marketing their project, it’s clear that there are many major red flags in the project’s smart contract code. The SafeMoon smart contract leaves users open to being exploited in several different ways by the project’s developers.
Investors should be extremely careful of the security risks involved while dealing with un-audited smart contracts.

What Obelisk can do for you

At Obelisk our expertise lies in smart contract auditing, development and security. We firmly believe that security is the foundation of building successful projects in the Decentralized Finance space and we always strive to help our partners succeed with ambitions through our auditing services. If you are an investor that wants to safely delve in a DeFi project, a developer that is seeking to launch a new blockchain project or perhaps an already established project looking to improve security and transparency and gain user trust then we would love to hear from you. Get in touch about your audit now through the channels below: