A blacklist token is a contract where the deployer can block any wallet address from selling. The function exists silently in the contract from day one. It is not called at launch. Sells work normally. The scanner shows clean results. Then, once enough buyers are trapped, the deployer blacklists every holder in a single transaction.
This is one of the most common and most underdetected scam patterns active in DeFi right now. Here is exactly how it works and what to look for before you buy.
Blacklist traps pass sell simulation completely. The blacklist is not active at scan time. By the time it activates, it is already too late.
How the Blacklist Function Works
The contract contains a mapping of blocked addresses and a privileged function that adds addresses to that mapping. Only the deployer or owner can call it. At launch, the mapping is empty. Everyone can sell. After enough buyers accumulate, the deployer calls the function and adds every holder’s address to the blacklist simultaneously.
mapping(address => bool) private _blacklisted;
function blacklist(address account) external onlyOwner {
_blacklisted[account] = true;
}
function _transfer(address from, address to, uint256 amount) internal {
require(!_blacklisted[from], "Address blacklisted");
// transfer logic
}
The function name is the first thing scammers obfuscate. Instead of blacklist(), they use names like setBot(), addToList(), markAddress(), or random strings. The contract is sometimes deliberately unverified on Etherscan to hide the source code entirely.
The Three Blacklist Variants
Mass Blacklist
Deployer blacklists all holders at once after accumulation. Most aggressive and common.
Selective Blacklist
Deployer lets small sells go through to maintain the illusion of safety. Large holders get blacklisted when they try to exit.
Anti-Bot Blacklist
Marketed as bot protection. Function is real but scope is undefined — deployer can blacklist any wallet under the anti-bot justification.
Delayed Activation
Blacklist function exists but is locked behind a time delay or block number. Activates automatically after a set period.
Why Simulation Does Not Catch This
Simulation tests whether a sell is possible right now. At launch, sells are possible. The blacklist mapping is empty. The simulation succeeds. The scanner reports the token as safe.
“The danger is not what the contract does now. It is what the contract can do later.”
This is the fundamental limitation of simulation-based scanning. It checks the current state. Blacklist tokens are dangerous because of their future state — a state the deployer controls entirely.
How to Detect Blacklist Risk Before Buying
Since simulation cannot catch this, detection requires static analysis of the contract code itself:
- Check for blacklist mappings — any
mapping(address => bool)combined with a privileged setter function is a red flag - Check ownership status — if ownership is not renounced, the deployer can still call privileged functions at any time
- Verify the contract is verified on Etherscan — unverified contracts are hiding something by definition
- Check deployer history — if the same wallet deployed known scam tokens before, treat this token the same way
- Look at the function list — any function that takes an address as input and is owner-only deserves scrutiny
A contract with renounced ownership and no privileged setter functions cannot blacklist you after launch. Ownership renunciation is one of the strongest safety signals in DeFi.
Real Example Pattern
The QBTC token used a variant of this pattern. The contract contained a hidden address restriction function disguised as an anti-bot measure. Once the deployer accumulated enough buyer liquidity, the restriction was activated across all non-deployer wallets simultaneously. Full breakdown in the QBTC Scam Analysis.
mapping(address => bool) private _isExcluded; // sounds innocent
function excludeFromReward(address account) // sounds like a feature
external onlyOwner {
_isExcluded[account] = true; // actually a sell block
}
function _transfer(address from, ...) internal {
if (_isExcluded[from] && to == uniswapPair) {
revert();
}
}
What DexScanr Checks
DexScanr analyzes every contract for blacklist risk as part of its standard scan on every token. This includes:
- Privileged address mapping detection — flags any owner-controlled boolean mapping on wallet addresses
- Ownership renunciation check — confirms whether the deployer still has control
- Function signature analysis — identifies suspicious setter functions regardless of their name
- Deployer wallet history — cross-references the deployer address against known scam deployments
🛡️ Scan Before You Buy
DexScanr detects blacklist risk, ownership status, and deployer history on every token — automatically on DexScreener before you make a trade.
Install DexScanr Free →Summary
Blacklist tokens are dangerous precisely because they look safe at scan time. The function exists from day one but is never called until buyers are trapped. Simulation cannot catch this. The only reliable detection method is static contract analysis — checking for privileged setter functions, ownership status, and deployer history before you buy. Never assume a clean simulation result means a safe token.