Introduction

Following on from our blog on The Proliferation of Honeypot Contracts in Web3 where we took a detailed look at a prolific honeypot creator, we take a look at the some common honeypot mechanisms and how they trap users funds. Honeypot contracts are tokens which users are able to buy but are then unable to sell, making them worthless despite their appearance. This blog looks at the common types of honeypot methods used by scammers and the scale at which they are deployed.

The Different Types of Honeypots

Honeypots prey on crypto investors that don’t have an in-depth knowledge of solidity. A honeypot price chart often shows all green candles which drive the fear of missing out (FOMO), causing users to impulse buy into a token. Once a victim purchases one of these scam tokens their funds are trapped in the tokens liquidity pair due to at least one mechanic preventing users from selling. These are some of the more common techniques we see on a daily basis:

The Blacklist

The blacklist is perhaps the most basic form of honeypot contract and doesn’t try to hide its purpose. Once a victim purchases the scam token, they are added to a blacklist. The token's sell function will check to see if a wallet attempting to sell has been added to that blacklist, if they have been, they are prevented from selling.

There are many variations of the blacklist that do try to hide their purpose which can include using function names that suggest they should belong. The ‘Approval For All’ function below doesn’t approve anything, it contains a hidden blacklist.

The function is given one or more wallet addresses and it simply adds those addresses to a _snapshot list.

When a user tries to sell or transfer tokens, the code will check if the wallets involved have been added to the _snapshot list. If they have been then _snapshotApplied must also be set to true. However, the _snapshotApplied variable is hardcoded as false, meaning any user on the _snapshot list will be prevented them from selling, equivalent to a blacklist.

The Balance Change

Rather than block users from selling the tokens they buy, this method changes a user’s token balance to an amount specified by the contract creator. The screenshot below shows a simple method of a scam contract changing a balance, though there are many variations of this.

The purpose of this function is to set a user’s balance to a lower value, usually one token. To the user, it may still appear as though they have the tokens they bought as the low balance is recorded within the contract but is not emitted, meaning a site such as Etherscan would not update the user’s balance. The user will not be allowed to sell more tokens than their balance recorded within the token contract. The user would therefore be stuck with tokens that they can no longer sell regardless of if they transferred to a new wallet.

In this second example (screenshot below), a contract’s owner has called a function which allows them to transfer tokens from one wallet to another. In this case they have sent tokens owned by 0x5F8 to a burn address which will be unrecoverable.

The Minimum Sell Amount

Technically this honeypot contract does allow a user to sell, however, they can only sell tokens above a certain threshold which is set to an extremely high number. In the screenshot below a user’s minimum sell amount has been set to the number in the amount field. The user would need to sell more than this which is likely to be unachievable as the amount will often be more than the available supply.

Again there are variations of this method, the _transfer() function (screenshot below) contains code which, when a user tries to sell, a threshold is set that requires the user to sell a specified amount of tokens more than their current balance. Here is how it works:

• Line 167: If a user’s wallet is set to ‘true’ in the hulkinfo list.

• Line 168-169: Add together the value of ‘infosum’, which is set to 34644 earlier in the code, and the user’s balance.

• Line 171: The user’s balance must be higher than the amount set above before they can sell.

Even if a user bought more tokens the process above would be repeated again and the user would still need X amount more meaning they will never be able to sell. For example if a user bought 35000 tokens which is higher than infosum (34644) and then tried to sell, the required amount to sell would now be the user’s balance (35000) + infosum (34644).

The Scale of the Problem

Honeypot tokens are a persistent threat which will likely continue as market conditions improve and new participants enter the Web3 space looking to participate in projects. Some honeypots may imitate well known projects and try to trick investors into purchasing their scam tokens. This can be done at scale as scammers automate deployment to create thousands of fraudulent contracts. In some examples that CertiK have investigated, the creation of a new honeypot contract from a single threat actor can be as quick as one every 30 minutes.

An investigation of EOA 0xC5535F839071b854a8deC65d3b30E36AB91229AB which is linked to a number token slippages that we have investigated shows that the wallet has created a considerable number of honeypot tokens. Between 24 August 2023 and 31 October 2023, the wallet funded 979 EOAs that then created a honeypot token. The chart below shows the connection between 0xC55 and wallets that were sent between 0.01 and 0.04 BNB which was used to create a honeypot contract that used the balance change method.

The funding for liquidity for each token that is created came from EOA 0xaec8fd4BE5d770a5f0d93bA48cA4D4AdBd4Cb9F4 which has over 296k BEP-20 transactions as it is also used to provide funds to wash trading wallets. More information on wash trading can be found in our blog on The Proliferation of Honeypot Contracts in Web3. Prior to 0xaec being used (which was used from 24 August 2023) over the period 30 June 2023 to August 24 2023, EOA 0xAe0B93C5BFA9B1171B7F5e742E3dA759674Fd588 funded 2551 EOAs which were used for wash trading honeypot tokens. This is just one user/group that has created 979 honeypot contracts in a two month period demonstrating the persistent threat of honeypots.

Losses

Losses incurred from honeypots are difficult to track. Using a fake Shia Token on BSC chain as an example, which uses the balance change honeypot method, the number of victims can be found by the number of times the honeypot mechanic was triggered. In this case, the contract creator calls a function called increaseAllowance() that changes a user’s token balance to zero. This function was called four times.

The increaseAllowance() function can be seen in the screenshot below starting at line 80. Highlighted in red is the calculation that takes the current balance of a wallet and subtracts it from itself. Often scammers will use random variable names to make interpreting the smart contract confusing to follow. In the below example, dsxxa8 on line 81 is the admin address.

Of the four users that had balances reset, the losses are approximately $60. Though losses are low, when you account for the number of contracts being created, the losses quickly add up. As an example, if each of the 979 contracts from the scale example made an average of $60 each it would net approximately $58.7k over the two months they were created.

Conclusion

As we said in The Proliferation of Honeypot Contracts in Web3, the prevalence of honeypot contracts in the Web3 space is alarming and constitutes a significant risk to investors. With automated implementation of mass-scale-operations, these schemes can be spun up rapidly and in some cases can leverage social media hype to attract victims.

The Squid Game honeypot token in 2021 was perhaps the most famous recent example of a honeypot token benefiting off media and social media hype. Despite the many warnings signs, millions of dollars worth of assets were lost in this instance. The Squid Game honeypot was quite unique and therefore hasn’t been covered in depth in this article, however it exhibited some common characteristics in its token chart, most notably an only green chart. Like with many of the common honeypot contracts that are outlined in this blog, the chart for the token’s are practically all green due to an absence of selling. Whilst this can look enticing, this is a major red flag. If you encounter an all green chart, with zero or a very small sell count then this is a good indication that you have encountered a honeypot contract.

Exercise extreme caution when encountering a token that has an all green chart, especially if it is being promoted in a trading channel. There are many free to use tools that can help you assess the risk of a token being a honeypot scam which should be utilized when doing your research.