How to spot hidden mint functions

In this article we will talk about a sneaky trick that the scammers use in order to
fool the investors as well as the auditors in order to perform the classic “Rug Pull”
scam by creating new tokens and harming the tokenomics, and how to read
SolidProof’s report to make sure if there is a potential of this scam in a project.
What is a Hidden Mint function?
What is a Hidden Mint function?
A mint function is defined by all the major token standards (ERC-20, BEP-20 etc.) in order to create new tokens.
Usually when a token/currency is launched, the supply is fixed so when the project goes live, a certain amount of tokens are minted by the owners and then the investors invest into it accordingly. Whenever new tokens are minted by the mint function it affects the total supply of the tokens which has a direct impact on the price of the token.

Moreover, the “mint” function is always internal, which means that no one can call it from outside the contract in order to make new tokens for themselves, including the owners of the contract.
But in some cases, the developers make the mint function external and adds a modifier with them that is “onlyOwner”.

However, we are all familiar with this modifier and we know that the functions that have this modifier mean that they can only be called by the owner of the contract. Now, imagine this modifier implemented with the “mint” function. It will mean that the owner can mint tokens as much as they want and whenever they want. But we believe that this type of implementation for a scam is pretty common and very easy to identify even for a non-technical person who is looking to invest in the project.

Nonetheless, Apart from the use of this simple method the Scammers have gotten much smarter and now they use more complex methods to hide the mint function in the code. .Let’s dig deep into this and learn about the Hidden Mint function with the
help of an example - Mint function Hidden in a Library.
Mint function Hidden in a Library
Recently, we found a pattern emerging with the developers’ code who were trying to
hide the mint function. We noticed that they were manipulating the well known
“SafeMath” Library. The manipulation happened in the “sub” function of the library
by changing only a couple of characters in the code so that it will go unnoticed.
• This is what a normal ‘sub’ function from the OpenZeppelin library looks like:

function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
   require(b <= a, errorMessage);
   uint256 c = a - b;

   return c;
• It protects the values from underflow and returns the result and is called in the
following manner inside the ‘transfer’ function:

_balances[sender] = _balances[sender].sub(amount, "Error");
• This allows the contract to check whether has enough funds to transfer a certain
• Now, let’s look at the modified ‘sub’ function:

function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {
      if (b == 1) return uint120(0);
   require(b <= a, errorMessage) ;
   uint256 c = a - b;

   return c;

If we look at the ‘sub’ statement closely, it says “(b = =1) return ~uint120(0)” which means if the token transfer amount is 1 then then whenever this ‘sub’ function will be called in the transfer function then it will return the maximum value of uint120 into the caller’s account, in our case ‘tokens’. By this process, tokens will be minted.

We kept it simple for the sake of explanation but please keep this in mind that the scammers can make it even more complicated by:

• Adding a unique token amount to transfer in order to mint

• Encoding a wallet address (for hiding) and then making the ‘sub’ function to return

the tokens into that particular wallet.

Reading SolidProof’s Audit report
SolidProof’s report is a result of Deep Analysis of the Smart contract’s code to
identify the vulnerabilities that can be harmful for both the Project and the investors.
This include all the Security Vulnerabilities hunting along with the notion of
protecting the investors from any potential scam by the project owner’s.

Section 1.1

This section (1.1) has the project details that include:

I. Project’s Contract Address Link

II. A brief Description

III.Social Media Details

IV. Logo

• For the project owners, our report has an “Issues Section” (Fig 1.2) that lists all the

security vulnerabilities found in the contract that is categorised on the basis of

their severity.

Section 1.2

• For the Investors, we have our “Ownership Privileges” Section, that specifies what

are the authorities the owner/deployer or any other address have in a smart

contract. However, this section is targeted for the project owners also to some

extent because in some cases the owners are also not aware of their smart

contract’s code properly and a developer goes on to scam everyone. Moreover,

sometimes the owner’s private keys get stolen that results in a scam too.

Section 1.3

This section signifies about what the owner or a person in the contract’s authority

“can do”. We have added this but in not in any way we mean to say that the Owner

is evil or they “will do it”. It is simply a matter of transparency so that everyone will

about what “could be done”.


In conclusion, we always recommend to ‘dyor’ before investing/launching a
project and always look for audit reports or get the project audited. This
was a brief explanation about the protection from this type of scams. Stay
tuned for more!
Top Solana Vulnerabilities
Solana is a widely popular blockchain and attractively low transaction fees are certainly among the reasons developers choose it. Among Solana-based dApps are some of the most popular and valued projects. This is why knowing Solana and its weaker points is now more necessary than ever.


A Developer’s Guide: A Framework setup
Developers often ask how to correctly, efficiently, and securely set up a framework for developing smart contracts. This guide aims to help new developers do it quickly and conveniently.