Risk check
Honeypot checker
A honeypot is a token you can buy and cannot sell. ScanZX tests the sell side directly — it simulates a sell path read-only against the chain's main router — and then reports the contract powers that could block a sell later even when today's simulation succeeds. Both halves matter: a passing simulation is a statement about right now, not a promise about after you buy.
What a honeypot actually is
The word covers a family of contracts that share one outcome: value goes in and does not come out. The crudest version rejects any transfer that is not a buy. More careful versions allow a small number of early sells so the chart looks alive, then close the door once enough liquidity has arrived. Others never block a sell outright — they set the sell tax to ninety-nine percent, which is a honeypot in economics if not in mechanics.
A fourth family does not restrict selling at all at the moment you look. It simply retains the ability to start. A contract whose owner can enable a blacklist, pause transfers or raise the sell tax after launch is not a honeypot when you scan it, and can become one in a single transaction afterwards. This is why a checker that only answers 'can I sell right now' is answering a narrower question than the one you are actually asking.
How ScanZX checks it
First, a read-only sell simulation. ScanZX asks the chain what would happen if the token were routed back to the wrapped native asset through the canonical V2-compatible router for that chain — Uniswap V2 on Ethereum, Base and Arbitrum, PancakeSwap V2 on BNB Smart Chain, QuickSwap V2 on Polygon. This is an eth_call: nothing is signed, nothing is broadcast, no wallet is connected and no gas is spent. A call that reverts where a normal token would succeed is treated as critical observed risk.
Second, the contract powers behind the trade. ScanZX reads the contract for functions that gate transfers — blacklist and whitelist entries, pause switches, trading-enabled flags, and tax setters — and reports which of them exist and who can call them. A contract where the owner can change the sell tax is reported as such regardless of what the tax is set to today.
Third, an independent cross-check. GoPlus Security is queried for the same token and its honeypot and tax fields are compared against what the on-chain reads found. When two sources disagree ScanZX records the disagreement and lowers the report's confidence score rather than picking a winner silently — a conflict between providers is information, and hiding it would be the wrong kind of tidy.
Finally, the sell simulation runs against a V2 path. Where a token's real liquidity lives in a concentrated-liquidity V3 pool, or on a DEX outside that path, a simulation can fail for reasons that have nothing to do with the contract being hostile. That case is reported as an unavailable or inconclusive check, not as a pass.
Reading the result
A failed sell simulation is the strongest single signal in the whole model and is scored as critical. Treat it as a stop, and treat any explanation offered for it with suspicion — 'the router is just misconfigured' is what a honeypot looks like from the inside too.
A successful simulation moves the question to the contract powers. If the owner has renounced and no tax setter, blacklist or pause function exists, the sell side is about as settled as an automated check can make it. If ownership is live and a tax setter exists, the passing simulation tells you the door is open now and says nothing about who holds the key.
Read the confidence score alongside the risk score. A token where the security provider was unreachable and the explorer had no verified source will produce a report with few findings — and few findings is not the same as no problems.
What a finding proves — and what it does not
What a positive signal shows
- A failed sell simulation shows that a sell along the standard router path did not succeed at scan time.
- A detected blacklist, pause or trading-gate function shows that the power to block transfers exists in the deployed code.
- A detected tax-setter function shows the buy or sell tax can be changed after launch.
- A live, non-renounced owner shows those powers currently have somebody able to use them.
What it does not show
- A successful sell simulation does not prove you will be able to sell later. It describes the contract's behaviour at one moment, and owner-controlled rules can change afterwards.
- The absence of a detected blacklist does not prove none exists. Obfuscated or unverified contracts can hide behaviour that automated reads do not surface.
- A low honeypot score does not mean the token is a sound holding. Liquidity, concentration and deployer risk are scored separately and a token can be freely sellable and still lose all of its value.
- No result here is a recommendation to buy or sell. ScanZX reports observed signals and does not give investment advice.
Limitations
- Simulation uses one V2-compatible router per chain. Tokens whose liquidity sits only in V3 concentrated pools, or on a DEX outside that path, may return an inconclusive result rather than a meaningful one.
- Contracts without verified source can only be read through their on-chain interface, so behaviour that is not exposed as a standard function may not be visible at all.
- Provider rate limits apply. When the security provider cannot be reached the cross-check is reported as unavailable and confidence drops — the check is not quietly skipped.
- The simulation reflects the pool state at scan time. Liquidity, taxes and permissions can all change between the scan and any action you take.
Any check that cannot run is listed in the report as unavailable and lowers its confidence score — it never lowers the risk score. The methodology page sets out how the weights and the confidence model work, and the status page shows which providers are configured.
Common questions
Does checking for a honeypot require connecting a wallet?
No. ScanZX never connects a wallet, never asks for a private key and never requests a signature. The sell test is a read-only call to a public node — no transaction is created, signed or sent.
Can a token pass a honeypot check and still trap sellers later?
Yes, and this is the most important limitation to understand. If the owner retains the ability to blacklist addresses, pause transfers or raise the sell tax, a token that sells cleanly today can stop selling later. ScanZX reports those powers separately from the simulation result for exactly this reason.
Which chains does the honeypot check run on?
Sell-path simulation runs on the five chains with a configured router: Ethereum, Base, BNB Smart Chain, Arbitrum and Polygon. On other chains ScanZX runs a baseline market scan and reports the sell simulation as unavailable rather than assuming it would pass.
Chain coverage
The deep EVM scan runs on five chains. Each chain page lists which checks are configured there and the risk patterns that recur on it.
Related reading and checks
Guides that go deeper on this subject:
- What is a honeypot token? — How trading restrictions and sell failures appear in a risk review.
- Owner privileges explained: mint, pause, blacklist — The contract powers that decide whether your position is really yours.
- How to check a token before buying — A ten-minute routine, in the order that catches the most for the least effort.
Other checks in the same report:
Cryptoassets are high risk and you could lose all money used to buy them. ScanZX reports observed warning signs and data gaps at scan time. It never certifies that a token is safe, it is not financial advice, and nothing on this page is a recommendation to buy or sell. Checks that cannot run are reported as unavailable and reduce the confidence score. Always carry out your own further verification.