Rug Pull Scanner Limits: Negative Results, Unknowns and Future Behavior

Method

A negative honeypot result answers a narrower question than whether a token is safe to hold. It can describe the behavior the service was able to simulate or analyze at a particular time. It does not establish how liquidity, ownership or an upgradeable implementation will behave later. Those are central rug pull scanner limits.

Review how buy-sell simulation works before interpreting the returned fields or an unavailable verdict.

A historical claim that a token passed a checker and then exited needs a timestamped pre-event response and a separately verified account of the later event. We did not obtain that evidence for a historical case in this run. The article therefore uses a current response audit and documented API limits instead of naming supposed scanner failures that the evidence cannot establish.

The initial DexScreener search for WETH returned a bounded list without any Ethereum pair rows. We retained that failed sampling attempt and used one declared fallback: the Ethereum WETH token-pairs endpoint. From its returned pool addresses, the survey selected a deterministic lexical sample for read-only Honeypot.is requests.

This sample is intentionally narrow. WETH pools can contain established assets, and multiple pools can expose the same token. It is useful for checking how a consumer handles successful and unavailable responses. It cannot estimate the prevalence of scams among newly launched tokens.

Retain the chain and pool or token identifier with the response. Symbols are not unique. A comparison between two services is meaningless if one analyzed another chain, a different pool or a different implementation behind a proxy. The identifier is part of the observation, not a technical footnote.

The lexical pool selection can include several pools for the same token. Preserve the pair address in every row so the reader can distinguish those observations. Aggregating them by token symbol would change the unit of analysis and hide repeated assets. Our denominator is ten pool requests, including the two unavailable verdicts, rather than ten unique tokens or ten completed simulations.

Ten pool requests produced eight results and two unknowns

Method

Source and selection

Fallback after WETH search returned 30 pairs and zero Ethereum pairs: all 30 pools returned by the Ethereum WETH token-pairs endpoint; deduplicate pair addresses, sort lexically and take 10. Honeypot.is accepts pair addresses; call once per pool.

Retrieved

2026-09-05

Observation

The unit is a WETH pool request, not a distinct token. All 30 returned Ethereum pool addresses formed the fallback population; the first 10 lexical addresses were selected.

Results

Eight requests returned a successful simulation and a negative honeypot result. The remaining two returned HTTP 404, so their verdicts are unknown. Reporting ten clean pools would incorrectly turn unavailable observations into negative findings.

The successful responses identified repeated USDT and USDC observations across different pools. That repetition further limits the sample: it is not ten independently selected projects. The useful result is the handling rule. An integration must preserve unknown outcomes and the identity of the analyzed asset instead of presenting every non-positive response as a pass.

Limits

• The first WETH search returned 30 pairs with zero Ethereum matches. The explicit fallback returned 30 Ethereum pools.
• No historical rug-pull sequence was verified, and no future safety prediction follows from these responses.
• Two HTTP 404 responses make the scan portion partial. The service did not provide a diagnosis explaining those missing verdicts.

The reproducible record is kept in the repository: seo/research/articles-32-41-2026-09-05/surveys.py and seo/research/articles-32-41-2026-09-05/survey-39.json. These file paths are not public downloads.

Case table

The case table records requests rather than accusations about token issuers. A negative result means the returned field was false in the retained response. Unknown means the request did not produce that field. The sample does not classify the projects' future behavior.

The same token appearing in several pool responses is a reason to keep the observation unit explicit. A table of pool outcomes can otherwise be misread as a table of unrelated tokens, exaggerating both sample size and diversity. If the research question concerns projects, deduplicate at the appropriate project or contract identity before drawing a project-level conclusion.

A missing response also needs its original transport outcome. A user interface that silently converts a failed request into a reassuring default makes the scanner appear more conclusive than the source. Preserve the failure and explain that the requested verdict is unavailable. Do not invent a reason, such as unsupported pool type, unless the service actually supplies it.

A future revisit should retain the earlier response rather than overwrite it. Changes in contract state, pool selection or service behavior can all change the output. The timestamps and identifiers allow an investigator to determine which observation changed before inferring that the token itself became more or less risky.

Behavioral signals scanners miss

Honeypot.is documents that some fields are not guaranteed to be present. It explains simulation success separately from the honeypot result, including cases where other analysis can contribute information. A consumer should read those fields together rather than reduce the response to one color.

GoPlus's token-security response documentation also describes unknown and omitted fields. For example, ownership-related observations can depend on source visibility or proxy analysis. An absent owner-control flag is not equivalent to a verified statement that no such control exists. Preserve the distinction in any downstream report.

The timing boundary is just as important. A simulation can exercise a route under the state the service observes. A later configuration change, liquidity removal or implementation upgrade can alter the user's experience. A snapshot should therefore identify the conditions it actually supports rather than claiming permanent sellability.

Not every risk is a hidden token function. A project can depend on a treasury, a website or an operational promise that is outside the token scanner's model. The absence of a honeypot pattern does not verify those dependencies. The crypto due-diligence checklist separates technical controls from claims about the people and processes around them.

Likewise, a positive or suspicious result should be investigated before it becomes an accusation. The service may report a condition whose interpretation depends on the token's intended restrictions. Preserve the raw response and identify the exact behavior at issue. A label without the underlying condition is difficult to verify and easy to misstate.

Separate a transaction observation from a control change

Consider a hypothetical dashboard that records a successful simulation for a pool and then displays the result for several days. During that interval, an administrator may change a parameter, an implementation may change or liquidity conditions may move. The old response still describes the service's earlier observation. It does not establish the behavior of the later state.

A useful data model therefore stores the response timestamp and target identity alongside the verdict. If the provider supplies a block reference or configuration details, retain those too. Do not invent a block number when the response omits one. The missing context is itself relevant to how confidently a later investigator can reconstruct the observation.

Ownership needs similar care. A simple owner field may not describe every privileged path. The review should consider the actual implementation and authority mechanism, including the possibility that an external component controls relevant behavior. An empty field or renounced-owner claim should not be expanded into a conclusion that no actor can change the system.

Liquidity is another separate question. A negative honeypot result does not establish that the size and route of a later trade will be available on acceptable terms. The user needs evidence about the intended transaction and the current market state. Combining these questions into a single green badge makes the displayed conclusion broader than the underlying checks.

These examples explain the information boundary; they are not accusations against any pool in our sample. We did not observe a later administrative change, liquidity removal or investor loss in the measurement. The sample supports a narrow statement about returned simulation results and unavailable responses at the recorded time.

A historical claim that a scanner missed a rug pull needs a different dataset. Retain the pre-incident response, identify the same chain and contract, establish the later event from primary evidence and explain the mechanism connecting the two. Without that chain of records, a current negative response cannot be used to reconstruct what the scanner said before an unrelated incident.

For an analyst maintaining a watchlist, define what invalidates an earlier observation. A changed implementation, a stale response or a failed refresh may require a new review state. The display should expose that state plainly so a user can see that the prior result has limited applicability rather than assume that silence means continued safety.

Do not convert this workflow into a prediction of price or intent. The evidence can describe observable permissions and service responses. It cannot establish an operator's future conduct or guarantee that a position can be exited.

What a human review adds

A human review can connect the observed behavior with the application's intended rules and authority model. It can inspect whether a privileged role is expected, whether a proxy can change implementation and whether a reported condition is reachable. That contribution depends on the review scope and evidence, not merely on a person looking at the same scanner screen.

Begin with the contract identity and available source. Map privileged actions, upgrade mechanisms and asset-transfer conditions. Then inspect the relevant liquidity and integration assumptions. A review that stops at token ownership can still miss a different authority path or a dependency that controls user access.

1. Separate positive, negative and unavailable service responses.
2. Inspect the condition reported and the implementation behind it.
3. Identify roles, upgrades and liquidity controls that can change behavior.
4. State what the evidence supports and which future actions remain unknown.

Pharos Production's manual smart contract review of logic and access controls page describes code review alongside automated analysis and remediation guidance. That scope is relevant when a scanner cannot resolve how an authority path or contract composition affects users. A scoped review can investigate those conditions; it cannot guarantee future operator conduct or investment performance.

Our member profile identifies the provider, and the tools hub helps place scanners within a broader review workflow. Ask for the exact target, assumptions and delivered evidence. The smart contract backdoor analysis provides a more detailed treatment of privileged behavior.

A human reviewer should also be willing to leave a conclusion unresolved. Unverified source, a changing implementation or missing historical output can prevent a firm answer. Record the missing evidence and the resulting decision boundary instead of replacing uncertainty with a stronger opinion.

Investor checklist

Use a scanner to decide what to inspect next, not to outsource the entire decision. The first question is whether the requested analysis actually completed and which asset it covered. An unavailable verdict should change the state of the review rather than disappear into a default green label.

1. Confirm the chain and contract or pool address. Preserve the scan timestamp and the service response.
2. Separate successful analysis from a missing field, failed simulation or transport error. Do not treat unknown as negative.
3. Identify the implementation and the actors able to alter privileged behavior. Check the actual mechanism rather than relying on a token symbol or badge.
4. Review the relevant liquidity controls and the application path through which a user submits a transaction.
5. Read the scope and revision of any audit claim. Determine whether the report covers the deployed behavior being considered.
6. Record the unresolved assumptions before making a decision; none of these checks predicts future price or guarantees exit liquidity.

An illustrative dashboard makes the distinction concrete. If its API call fails, the correct display is analysis unavailable with a retained error reference. If the service returns a negative result, the display should describe that result and its timestamp. Neither state should become a permanent safe-token badge.

The same principle applies when two tools disagree. Compare identifiers, timestamps and the conditions each service reports before choosing the more reassuring answer. One tool may have analyzed a different pool or supplied information from another method. The disagreement is an investigation input, not a vote in which a majority establishes safety.

For a later incident investigation, the retained response is the valuable artifact. It allows an investigator to compare what the service reported with the state and event that followed. Without that record, a statement that the scanner passed the token before the incident remains unverified, regardless of how plausible the story sounds.