On Dec 17th, just before the holidays, Gempad - a multichain token launchpad was exploited via reentrancy.

A token launchpad platform is a system that allows users to create and launch new cryptocurrency tokens using pre-built smart contract templates. Think of it like a website builder, but for creating tokens - users can select from existing templates and customize basic parameters like the token name, supply, and distribution rules without needing to write smart contract code from scratch.

Gempad Reentrancy Exploit

The vulnerability was found in one of Gempad's templates, specifically in the collectFees function in the GempadLock contract, which is a a liquidity (LP) token locker contract.

Usually in token lock contracts users are supposed to pay fees to lock their LP tokens. The collectFees function collects these fees before locking the LP tokens. Once fees are paid, the LP tokens get locked for a specified period.

What did the hacker do? They created a malicious token that has a special transfer function. When this token's transfer function is called (to pay fees), it re-enters the collectFees function. During this re-entrancy, the contract state hasn't updated yet! The hacker can create a new LP lock before the first transaction completes.

The hacker effectively creates an LP lock without actually paying the required fees. They can later retrieve their locked LP tokens when the lock period expires. The contract loses fee revenue and its economic model is compromised. This is similar to the classic DAO hack pattern, where the key vulnerability is that state changes happen after external calls. The DAO hack turned 10 in May of 2024.

The vulnerability existed in many smart contracts created with Gempad's faulty template, which caused 27 projects to be affected. The attacker ran the funds through a mixing service, preventing the stolen money being recorded and frozen on DEXs and CEXs.

Prevention and Best Practises

One way to prevent this exploit is by implementing checks for state changes:

function collectFees() {
    // Checks
    require(feeAmount > 0);
    
    // Effects (state changes)
    feesPaid[msg.sender] = true;
    
    // Interactions (external calls)
    token.transfer(feeCollector, feeAmount);
}

Another way is a reentrancy guard:

modifier nonReentrant() {
    require(!locked, "No re-entrancy");
    locked = true;
    _;
    locked = false;
}

function collectFees() nonReentrant {
    // function logic
}

Smart Contract Templates

Using smart contract templates can help many founders launch their projects faster.

We have audits for smart contract template providers and enjoyed working together to make sure the templates are safe, intuitive, easy to use and have all necessary protection guards. We made sure all naming and functionality is easy to adjust for people who don't normally write smart contracts. Auditing templates involves big responsibility for every project that will use them in the future.

Check our audit report for Add3 - Customizable & Compliant Web3 Products and see useful tips in writing smart contract templates for vesting, dynamic staking, static staking and token contracts.

Request an Audit with Our Experts ⛊

Security isn't a luxury - it's the foundation of trust in web3.

While rushing to market is tempting, just one smart contract vulnerability can destroy your project, your users' funds, and your reputation overnight. We've seen protocols lose millions because they skipped proper auditing to save a few bucks.

The cost of an audit is trivial compared to the potential losses from exploits, especially when your protocol begins handling serious volume. Don't gamble with your users' funds or your project's future. Get multiple audits from reputable firms, implement our recommendations, and make security a cornerstone of your development process. The question isn't whether you can afford an audit - it's whether you can afford not to pass one.

STAY SAFU

Audita's Team