Token False Alarms on Bitsy Wiki

Capability Flags

Mon, 01 Jan 0001 00:00:00 +0000

A capability flag is a boolean asserting that a token contract can do something. GoPlus returns about forty-five of them, TokenSniffer runs twenty-six named tests, Quick Intel publishes twenty-two numbered checks, and MetaMask ships fifty-one token-risk labels; the four are different vocabularies over one operation, which is reading the bytecode for a function selector or a storage pattern. None of them has a field that can hold a bound, a delay, or the kind of account holding the key. Searching GoPlus’s response documentation for “timelock”, “immutable” and “audit” returns nothing under any of the three.

The Blank Field

Mon, 01 Jan 0001 00:00:00 +0000

The loudest false alarm is a red banner. The most common one is an empty response. GoPlus’s booleans are tri-state — "1" true, "0" false, absent means the question was not answered — and the vendor says so in three separate places, including “No return doesn’t mean it is risky” on trust_list. Downstream, absence gets rendered as a grey shield, a “no data” badge, or a zero, and the party that turned the blank into a verdict is the integrator rather than the API.

Liquidity and Holders

Mon, 01 Jan 0001 00:00:00 +0000

The heuristics that do not read code read four things: whether liquidity is locked, how concentrated the supply is, what else the deployer has deployed, and what the token’s counterparties have touched. All four are presented as analysis of on-chain state. Three of them are lookups against a curated list, and the fourth is a threshold somebody picked. Nothing written in the token contract changes any of the answers.

A lock is a name on a list#

GoPlus states the rule without hedging: “About ’locked’: We only support the token lock addresses or black hole addresses that we have included.” A custom timelock, a Safe with a delay module, or a locker the vendor has not integrated reads as unlocked — not as unknown.

Allowlists

Mon, 01 Jan 0001 00:00:00 +0000

Every heuristic in this section has exactly one reliable off-switch, and it is not a property of the contract. GoPlus’s trust_list, honeypot.is’s very_low band, RugCheck’s silent exemption for USDC, MetaMask’s VERIFIED, Uniswap’s SafetyLevel.Verified, Jupiter’s strict list — clean is membership. A token that satisfies every published criterion and is on no list stays flagged, and a token on the list stays clean whatever its bytecode says.

Membership does not suppress the findings#

The most common misreading is that an allowlist entry cancels the flags. It does not; it sits beside them, and the decision to suppress belongs to whoever renders the response.

How Often This Is Wrong

Mon, 01 Jan 0001 00:00:00 +0000

A detector vendor reports precision: of the alarms it raised, what share were correct. A deployer experiences the complementary quantity: given that my token is honest, what is the chance I get flagged. That is 1 − specificity, and the two numbers are not the same. Precision is inflated by the base rate of scams in the population sampled; 1 − specificity is untouched by it. Every published figure in this field is the first quantity, and nobody publishes the second.

Clearing a Flag

Mon, 01 Jan 0001 00:00:00 +0000

Remediation is not one process. It is a dozen vendor queues, each keyed to a different machine, most of which will not tell you they exist. Changing the contract does not help: the ENS token is behind a 48-hour timelock with a hard-capped mint and still reports is_mintable, and both PEPE and 1INCH have renounced ownership and still report the flags their unreachable setters produce. Once a flag exists, it is a queue problem.

Designing and Self-Checking

Mon, 01 Jan 0001 00:00:00 +0000

Only two kinds of design decision change what a scanner reports. One is removing a function from the deployed bytecode, so there is nothing to detect. The other is moving the token inside a list somebody else maintains — a recognised locker, an indexed trading pair, a verified source. Everything in between — capping a setter, adding a timelock, publishing an audit, renouncing ownership — is invisible to the schema. That is not an argument against doing those things, which protect real users against real risks. It is an argument against expecting them to change a boolean.