What scanners reliably detect
Unrestricted mint functions, blacklist and whitelist mechanisms, transfer-blocking logic, owner-only functions that change fees or pause transfers, proxy upgradeability, and hard-coded privileged addresses.
These are structural and visible in the code, which is why detection is accurate when the source is verified.
What they miss
Novel logic that does not match a known pattern. Economic exploits where every function is individually correct but the combination is not. Off-chain dependencies such as an oracle or an admin key. And anything in an unverified contract, where only bytecode is available.
Most large protocol losses have come from this category, not from patterns a scanner would flag.
Why a clean result is weak evidence
It means no known pattern matched. Given that the most damaging exploits were novel at the time, absence of known patterns is a weak statement about safety.
The asymmetry matters: a flag is strong evidence of risk, a clean result is weak evidence of safety. Treat the two very differently.
False positives cut the other way. Scanners flag patterns that are legitimate in context, such as a pause function in a protocol with a published emergency process, so a flag is a prompt to read rather than a verdict. Understanding what was flagged beats counting how many flags there were.
Using it sensibly
As a cheap filter to eliminate obvious problems before spending attention. Then look at the things a scanner cannot see: who holds admin keys, whether the contract is upgradeable, how long it has held value, and whether a named firm audited it.
FBT Swap does not audit arbitrary imported token contracts and does not claim to. It shows the route, price impact and fee before you sign; verification of a token you selected by address remains yours.