jepeta.
risk signal

How do I check if a Base token is a honeypot?

Use an exact-contract honeypot check that can return an explicit boolean rather than guessing from missing data. On Base, a honeypot check is an important first gate, but it is not the whole risk assessment: a token can be sellable and still be mintable, heavily taxed, illiquid, or highly concentrated.

Concept illustration of visible evidence in front of obscured, unknown information.
Jepeta · Original AI concept illustration; not a product photo or evidence

Key takeaways

  • Use the exact Base contract
  • Require an explicit honeypot result
  • Do not treat unknown as false

What a honeypot check tells you

A honeypot detector tries to identify whether buying is possible while selling is blocked or materially impaired. Honeypot.is documents an IsHoneypot endpoint with simulation results and buy/sell tax fields.

That answers a narrow but critical execution question. It does not by itself prove that contract permissions, liquidity depth, ownership concentration, or later contract changes are acceptable.

How Jepeta handles unknowns

Jepeta uses GoPlus as the required security source for its strict public honeypot signal. If the required honeypot value is unknown, Jepeta does not silently convert it to false; the public scan fails closed instead of manufacturing reassurance.

A usable Jepeta verdict requires explicit honeypot and mintability observations. The V5 contract represents observations in normalized evidence and logical signals; the V4 compatibility contract exposes is_honeypot and is_mintable directly. Consult the schema for the version your client requests.

What to do after the honeypot result

If the result is positive, stop. If it is negative, continue with mintability, taxes, holder concentration, liquidity, and source quality. A negative honeypot result is one passed check, not a safety certificate.

For permanent verification, use a Jepeta evidence page only when one exists for that exact token. Evidence pages are timestamped and disclose their last-checked time.

A simulation error is not a sale result

When a simulation fails, record its error and whether a honeypot result was actually supplied. Do not convert the error alone into either “honeypot” or “sellable.” Honeypot.is documents that some result fields can be absent; Jepeta has its own required-evidence rules. Compare the exact contract, chain, pair context and observation time before interpreting disagreement between tools. A fresh successful simulation still covers only its tested conditions.

AI-assisted review of linked documentation; no independent product benchmark. Screening observations and policy labels do not guarantee token safety.

Practical checklist

  • Use the exact Base contract
  • Require an explicit honeypot result
  • Do not treat unknown as false
  • Continue with permission and market checks
  • Re-scan close to execution

Limitations

This is educational risk-screening content, not investment advice. Token and market conditions can change after any snapshot. A PASS result or negative honeypot signal is not a safety guarantee.

Sources & methodology

Sources reviewed Nov 4, 2026.

Continue reading

Browse all articles