$BADAI Token Launch Review

9 min readFeb 24, 2025

Executive Summary

On February 20, 2025, the BADAI token launched on the BNB Chain with an implemented anti-sniping protection mechanism developed by GraFun. While the launch generated significant interest, it encountered severe technical difficulties that impacted trading activities and user experience. The primary issue stemmed from a flaw in the anti-sniping protection system that caused widespread blacklisting of legitimate users and created opportunities for exploitation.

The incident resulted from two critical failures: a cross-contamination issue between liquidity pools that caused mass blacklisting of regular users, and a vulnerability in the Connector smart contract that allowed certain actors to bypass trading restrictions. Despite these challenges, the majority of sniping attempts were successfully blocked, though some malicious actors managed to exploit the system. Further, there have been irregularities in the revocation UI of the GraFun platform that have contributed to revoking an incomplete list of sniping accounts effectively unfreezing some snipers, who have proceeded to sell their tokens into the liquidity pools. More on these can be found below.

This report provides a comprehensive analysis of the incident, its causes, and the subsequent resolution actions taken by the BADAI and GraFun teams.

Project Overview

About BADAI Token

BADAI is an BEP20-standard token deployed on the BNB Chain, incorporating GraFun’s Liquidity Protection system designed to prevent bots from sniping liquidity during launch. The token contract was partially open-source, with proprietary protection mechanisms implemented through unverified contracts to maintain security through obscurity. This means that if someone had access to the source code of the black-box part of the contract, they theoretically could engineer sniping strategies to bypass them.

Key Stakeholders

The project involved several key parties:

BADAI Team: Core project developers and managers
GraFun: Technical partner providing the token and launch infrastructure with the anti-sniping protection
Floki: Strategic partner and stakeholder providing TokenFi facility
BNB Chain: Platform ecosystem partner
External Auditors: Security assessment providers, in particular AmbiSafe

Contract Security Measures

Prior to launch, multiple security assurances were established:

Full contract audit by an external security firm AmbiSafe. The audit report has since been retracted by the AmbiSafe team (**).
Review of open-source components by the BADAI team.
Additional verification by Floki’s security team of the entire codebase of the contract, including both open and closed source components. *
Code review accessibility for CEX listing teams.

The contract architecture consisted of both open-source components (ProtectedToken Contract, UsingMultipleLiquidityProtectionServices Contract) and closed-source elements (LiquidityProtectionServices). This hybrid approach was advisable to protect against bot developers while maintaining transparency where possible.

The Incident

Anti-Sniping Protection Design

The protection system was designed with specific parameters:

Purpose: Prevent unfair token purchases by bots and MEV strategies during critical moments immediately after launch
Implementation: Two-contract system

Main ERC20 contract with protection checks before transfers
External GraFun-managed protection service contract (closed source) maintaining blacklists of identified snipers

Deployment: Token launched simultaneously on THENA and PancakeSwap DEXs
Protection Scope: Designed to block sniping attempts in the first several blocks post-launch

Launch Issues

The token launched on February 20, 2025, at 14:00 UTC. The following issues emerged immediately:

While users could purchase tokens, most were unable to sell
Transaction fee estimations showed abnormally high gas requirements (~0.14 BNB)
Failed transactions displaying “FirstBlock Trap: blocked” errors
Cross-pool contamination affecting legitimate traders
BAD staking functionality unusable because anti-sniping protection blocked transferring tokens

Anti-Sniping Protection Removal

The anti-sniping protection was designed to be removed automatically after several initial blocks, effectively jailing the snipers and allowing regular traders to interact with the liquidity pools. Due to the aforementioned issues in the contract, however, the restrictions have not been removed automatically and no indication of that has been given other than the community outcry across our social channels.

As soon as the issue was discovered by the BAD AI team due to a community outcry, we have requested GraFun to provide a list of snipers whose accounts should be revoked — those who have bought in the first several blocks. It should be noted that the intended workings of the contract would then leave it in the hands of BADAI to manually revoke addresses that have interacted with the pools in the first several blocks. This was designed for us to have an opportunity to manually unfreeze the accounts of regular users who happened to mistakenly interact with the pools during the first several blocks.

GraFun supplied the BAD AI team with a list of accounts marked for revocation — meaning tokens would be returned to $BADAI. After the revocation process, with guidance from the GraFun team, BADAI team has manually lifted any and all restrictions effectively restoring orderly trading.

Those which were present on the GraFun platform interface were revoked within several minutes, several however have been omitted on the interface. The reason for omission has not yet been made clear to the BADAI team — GraFun has stated that it could have been a front-end bug.

Further investigation revealed that some of these missing accounts belonged to snipers who had sold their tokens after the sniper-specific restrictions were lifted.

Technical Analysis

Root Cause Analysis

The core issues stemmed from the implementation of the liquidity protection mechanism that is called from the token contract:

The main ERC20 contract with the UsingMultipleLiquidityProtectionServices module that acted as a gateway:

function _beforeTokenTransfer(

address _from,

address _to,

uint _amount

) internal override {

super._beforeTokenTransfer(_from, _to, _amount);

LiquidityProtection_beforeTokenTransfer(_from, _to, _amount);

}

This protection check would then reach out to external protection service contracts, managed by GraFun, to validate transfers. The critical flaw manifested in two ways:

First, the cross-pool contamination occurred due to the protection logic treating both liquidity pools as potential sources of contamination. When a user interacted with either pool, the protection service marked them as “infected”, effectively creating a chain reaction where:

The pools themselves remained whitelisted and functional.
Any wallet that received tokens from these pools became blacklisted.
Transactions were still allowed to purchase but not to sell.
Each pool maintained its own separate blacklist, independent of other pools. The infection spread rapidly due to arbitrage transactions between two liquidity pools occurring in the same block as the initial liquidity provision

Second, the Connector has remained in the whitelist after the liquidity migration. This gave certain bots the opportunity to bypass security measures through a completely new attack vector. It’s important to note that even without the Connector being in the whitelist, this novel attack vector would have still worked, just somewhat less efficiently. The core issue was the innovative attack approach rather than the whitelisting oversight as described below:

Attackers reverse-engineered the Connector contract used for liquidity deployment
They created a process that in a single transaction would:

Purchase tokens from the DEX.
Transfer tokens to the Connector contract.
Mint worthless tokens and create new LP pairs.
Extract value through PancakeSwap routing.

The exploitation was successful because:

The Connector contracts were whitelisted in the protection system
The attack was executed within a single block before restrictions could take effect
Transaction traces were obfuscated through the LP pair creation process

The architecture’s closed-source components (LiquidityProtectionServices contracts) made it difficult to identify these issues before deployment, despite multiple security reviews. The complexity of the multi-pool protection system ultimately created more vulnerabilities than it prevented.

Given the unusual nature of the contract, the BADAI team had requested security assurances in advance. We were provided with:

a. A security audit from GraFun — AmbiSafe. Link to audit: https://www.ambisafe.com/assets/audits/GraFun-Contracts-Review-And-Verification.pdf

Audit also available in the BAD AI drive here: https://drive.google.com/drive/u/2/folders/1Rpz3sjKi3b2QwdqvjMTBnCMmmqvmy99U

b. An inspection of the open-source parts of the contract by the BADAI team, but without access to the proprietary “black box” areas of the smart contract technology, which were only given to Floki’s security team. *

c. Assurance from Floki’s security team that the contract was reviewed and approved. *

d. A commitment to show the “black box” areas to any interested CEX listing teams, though it’s unclear if any such audit was performed.

What we consider to be our main mistake was that we ultimately decided to proceed under the guarantees provided by Floki, GraFun, and Ambisafe, instead of insisting further to get the direct access to the proprietary part of the contract.

Trading Analysis

Analysis of the top traders during the incident revealed several patterns:

Successful Snipers: Some accounts managed to bypass protection and secure significant profits:

Account 0xd4f04374… successfully exploited the protection bypass using the Connector contract
Account 0x132d9bbdb… (Slurpycoin exploiter) successfully used similar methods
Several other wallets managed to extract value through sophisticated MEV strategies

2. Affected Legitimate Traders:

Multiple presale participants and airdrop recipients were unable to trade
Some traders like 0xd7f382c0b… bought for 255 BNBs but were blocked by protection, later selling at >50% loss
Large number of retail traders were completely locked out of selling

3. Overall Impact:

Most snipers were successfully blocked with no significant profits
Some sophisticated attackers managed to bypass protection and extract value
Legitimate traders faced significant losses due to inability to sell during price peaks
The subsequent removal of restrictions led to increased sell pressure

The incident demonstrates that while the anti-sniping protection was partially successful in its intended purpose, its implementation caused more harm to legitimate traders than protection against malicious actors.

The Impact

The incident created a complex trading environment characterized by:

Asymmetric trading capability (buys possible, sells restricted)
Limited selling access to only a few groups:

Snipers who successfully bypassed protection
Other participants who did not buy with the liquidity pools

Widespread user frustration due to inability to execute trades
Elevated gas fees for basic token operations

The situation was further complicated by the BNB chain’s public warning about potential honeypot characteristics, which intensified community concerns and selling pressure once restrictions were lifted.

Resolution & Current Status

Actions Taken

Protection System Deactivation

disableProtection() function was called via transaction on BSCScan
disableProtectionExtra() function was called via transaction on BSCScan

2. Ownership Renouncement

The contract ownership has been fully renounced via transaction on BSCScan, using OpenZeppelin’s standard renounceOwnership() function
This permanently removes the ability to call any functions with the onlyOwner modifier

Current Token Status

Token Contract Architecture The token is now operating as a standard ERC20 with:

Base functionality from OpenZeppelin’s ERC20 implementation
No active protection mechanisms
No administrative controls
Verified source code on BSCScan

Decentralized Operation

All centralized control functions have been permanently disabled:

// These functions can no longer be called as ownership is renounced:

function LiquidityProtection_unblock(address[] calldata _holders)

function LiquidityProtection_setWhitelist(address[] calldata _holders, bool _value)

function LiquidityProtection_setLiquidityProtectionService(address plps, address pool)

Trading Status

Full trading functionality restored
No transaction restrictions or blacklists
Standard ERC20 transfer functions operating normally:

function transfer(address to, uint256 amount) public virtual override returns (bool)

function transferFrom(address from, address to, uint256 amount) public virtual override returns (bool)

Moving Forward

We’re working closely with BNB Chain’s security team, HashDit, GraFun and Floki teams to piece together exactly what happened. Our main focus is on several high-volume traders who interacted with the token during launch, particularly three addresses of interest:

A sniper who moved 750 BNB: 0xbccbf00c9b046fd2a84174b7b7010fd3435cc032
An account that managed to bypass protections: 0xd4f04374385341da7333b82b230cd223143c4d62
The Slurpycoin exploiter: 0x132d9bbdbe718365af6cc9e43bac109a9a53b138

As we uncover more details about the transaction patterns and methods used, we’re documenting everything transparently for the community. This includes full transaction traces, detailed wallet analyses, and a comprehensive breakdown of how the protection mechanism ultimately fell short of its intended purpose.

Lessons Learned & Future Steps

Key Technical Lessons

The fundamental failure stemmed from trusting a third-party black box contract for critical functionality without full code access or control. Despite the assurances, the proprietary GraFun liquidity protection mechanism proved to malfunction. The cross-pool infection between trading venues and exploitable Connector contract design demonstrated how closed-source components can introduce unmanageable risks, even with partner guarantees.

Process and Governance Insights

The team should have never proceeded without full access to the protection mechanism’s source code, regardless of partner assurances or partial audits. The incident revealed critical gaps in due diligence processes and launch coordination. Moving forward, no critical infrastructure components will be deployed without complete team visibility and control.

BAD team has since developed its own SC infrastructure for future token launches. This technology will be used in all tokens launching on BAD going forward.

Path Forward

Future launches must prioritize open-source, fully auditable protection mechanisms with clear isolation between trading venues. While third-party integrations may still play a role, they cannot be black boxes affecting core functionality. Focus should be on building internal security capabilities while maintaining transparent community communication about system risks and improvements.

*In response to comments from the community after this piece went live we want to note that Floki is not the auditor and had no controls over the contract, but instead reviewed and gave their opinion as BADAI’s main launch partner. Floki is not a security firm, thus cannot be blamed for what happened and all along has been most supportive in any and all BADAI undertakings.

**Upon review by GraFun after this article was posted, it was clarified that this was an audit of an older implementation. The final report can be found on AmbiSafe’s website here: https://www.ambisafe.com/assets/audits/GraFun-Contracts-Review-And-Verification.pdf