A honeypot token lets a user buy but prevents or sharply restricts selling. The restriction may be explicit in a contract or may depend on an address, time, tax setting, liquidity state, or other condition. A token that sells once can still become unsellable later, and a scanner result cannot prove what a contract will do next.
Use the steps below to look for questions that deserve answers. They are not a certification process and cannot make a token safe. BSC.app did not trade a token or test scanner accuracy for this guide.
Start with the exact network and contract
Confirm that the wallet and explorer are on BNB Smart Chain mainnet, not Ethereum or opBNB. The BNB Chain wallet configuration page lists the BSC mainnet chain ID as 56. Copy the full token contract address from a source you trust; a name, ticker, icon, or search-result snippet can be impersonated.
Check that the pool or trading pair you are examining uses the same contract address. Search results can show similarly named tokens or multiple pools. A legitimate project name does not prove that a particular address belongs to it.
Read contract verification as transparency, not approval
BscScan explains that source-code verification matches submitted source code to deployed contract bytecode, making the code available for inspection. Verification does not mean BscScan audited the token, endorsed it, or proved that it is safe. An unverified contract leaves less information to inspect, but a verified contract still may contain harmful or owner-controlled behavior.
Look for the token’s administrative controls and who can call them. Depending on the implementation, relevant powers may include changing buy or sell taxes, blacklisting addresses, pausing transfers, restricting trading to approved addresses, minting supply, changing fees, or upgrading a proxy implementation. Function names vary, and reading a contract incorrectly can create false confidence. If you cannot identify the control path or owner, treat it as unresolved.
Renouncing one ownership role is not proof that every privileged role is gone. A proxy may delegate behavior to another contract; a multisig or role manager may retain authority; an external launch or router contract may add separate risks. Follow the implementation and admin addresses where relevant.
Check the actual market and liquidity
Inspect the specific BSC pool, not just a chart for the token. Ask:
- Is this the intended pair on the expected DEX?
- What assets and amount are actually available to swap against?
- Who controls the liquidity-provider tokens, and can liquidity be removed?
- Are the deployer and early wallets concentrated or connected to one another?
- Is trading active, and do recent buys and sells come from independent addresses?
There is no universal liquidity amount or holder percentage that makes a token safe. A pool can have liquidity now and lose it later; a lock service, if present, also has its own contract, duration, and ownership assumptions to verify.
Interpret simulations and scanner warnings cautiously
Some bots and token tools simulate a buy or sell and inspect contract flags. A simulation can miss behavior that changes with the sender, block, wallet balance, time, trading phase, or contract state. The simulation may also use a route or amount different from the order you plan to send. A successful hypothetical sell is not a guarantee that your later sell will work.
Conversely, a warning is a reason to investigate, not proof that funds are already lost. Read what the scanner actually checked and its limitations. Do not approve an unlimited amount or sign an unfamiliar message just to run a token check. If the tool asks for private keys, stop; a read-only contract or address lookup should not require your recovery phrase.
A practical review sequence
- Verify BSC network, exact contract address, and pool address.
- Open the contract page and check whether source code and proxy implementation are visible.
- Identify who can change fees, pause transfers, blacklist wallets, mint, or upgrade behavior.
- Review liquidity ownership and recent pool activity without relying on one chart metric.
- Compare results from more than one independent data source, noting what each tool did not inspect.
- Recheck the order preview, token address, route, slippage, approvals, and total fees before any signature.
If a material control or key fact is unknown, say so. Do not turn “not flagged” into “safe,” and do not use a small test buy as proof that an asset can later be sold. A test transaction can still lose money or become trapped.
For bot-specific token-screening claims, read our reviews and note whether a statement is documented, observed, reported, or unresolved. For transaction and wallet setup context, see getting started with BSC bots and our research methodology .