Honeypot is necessary but narrow
A token that blocks selling is an obvious stop condition, so honeypot testing belongs near the top of a pre-trade workflow. Simulation tools can also reveal taxes and gas behavior.
But a sellable token can still be mintable, highly concentrated, thinly traded, or subject to mutable controls.
Broader screening adds context
Jepeta combines explicit honeypot and mintability signals with taxes, observed holder concentration, observed LP-lock coverage, Base liquidity, source status, and data quality.
The policy result is designed to help a workflow decide whether to block, review, or continue to independent execution rules.
Use the right label
Do not call a negative honeypot result safe. Say the honeypot check was negative at that timestamp. Likewise, do not call a PASS verdict a guarantee.
Precise language makes evidence more useful to users and less likely to be exaggerated when quoted by an AI system or search result.
Read disagreement as separate observations
In a hypothetical response, a sell simulation succeeds while another source reports minting authority. These statements can both be true: one describes a simulated transfer path, the other a supply permission. Preserve each source, chain, contract, observation time and limitation. Do not average the two labels into a safety score or discard the permission because the simulated sale succeeded. The useful outcome is a specific unresolved question about supply control.
AI-assisted review of linked documentation; no independent product benchmark. Screening observations and policy labels do not guarantee token safety.
Practical checklist
- Honeypot = sellability and transfer risk
- Risk check = multiple dimensions
- Never translate negative honeypot to safe
- Keep timestamps
- Use broader context
