Why LP-lock claims need scope
Tokens can have multiple pools, multiple LP holders, concentrated-liquidity positions, or liquidity that moves over time. A single locker record does not necessarily describe the whole market.
TokenSniffer's documented Base coverage lists several supported lockers, which is useful evidence but still represents a coverage boundary.
Jepeta wording is intentionally narrow
The V4 compatibility contract names the GoPlus-derived metric lp_locked_percent_observed and includes an LP-holder sample count. Historical public evidence pages preserve that observed sample coverage. It is not proof that all liquidity is locked.
That wording is carried onto permanent evidence pages so downstream AI systems do not turn an observed percentage into a stronger claim than the data supports.
What else to review
A lock does not remove mintability, tax, owner-control, holder-concentration, or honeypot risk. It also does not guarantee sufficient market depth.
Use the LP-lock observation as one item in a broader pre-trade checklist and check the timestamp before acting.
A lock claim needs a position and an exit condition
Ask which pool or liquidity position the record covers, what fraction of the relevant position is included, and when or under what conditions it can be released. If those details are unavailable, retain that limitation. A supported-locker list establishes that a tool recognizes certain lockers; it does not verify a particular token’s lock. Jepeta’s observed LP-holder coverage also cannot establish an unlock schedule that the returned evidence does not contain.
AI-assisted review of linked documentation; no independent product benchmark. Screening observations and policy labels do not guarantee token safety.
Practical checklist
- Identify the relevant Base pool
- Check observed lock percentage and sample count
- Do not generalize one lock to all liquidity
- Review locker/source coverage
- Combine with contract and holder checks
Limitations
Sources & methodology
Sources reviewed Nov 4, 2026.
