The finding: five comparisons changed the selected pool
In a read-only review of Jepeta's 13 published Base token risk-score events dated October 7–8, 2026, 5 events used a different selected DEX pool before and after the score change. The other 8 retained the same selected pool. That is 38.5% of this publication cohort—not 38.5% of Base tokens, trades, alerts elsewhere, or incidents.
Pool identity matters because a comparison between two different markets is not a measurement of how liquidity changed *inside one market*. A score can move when the scoring system selects a different pool. The stored score is a valid historical output of the stated policy, but it cannot by itself explain a token's actual market behavior. This audit has not independently reconstructed the historical third-party API responses.
The five affected records
| Published event | Stored score before → after | Selected pool identity |
|---|---|---|
| KRAV | 65 → 30 | Changed |
| ZED — first alert | 70 → 80 | Changed |
| flETH | 45 → 55 | Changed |
| ZED — later alert | 80 → 70 | Changed |
| YUNAI | 65 → 40 | Changed |
The two ZED entries are separate published events for the same token, not two distinct tokens. The cohort denominator is events, and includes repeated observations of tokens. This is not a claim that any of these tokens are unsafe.
Why a token can have more than one pool
DEX Screener's API reference exposes both pair-address lookups and a token-pairs endpoint, because a token may trade across multiple liquidity pools. CoinGecko's onchain documentation likewise retrieves and ranks multiple pools for a token. These official API contracts support the basic distinction between a token and the specific market selected to describe it.
Consider a reader seeing an apparent improvement in a risk score while the selected market changes. Without a stable pair identifier, a statement such as 'the original pool recovered' would exceed the evidence. The responsible next step is to compare the exact chain, token contract, DEX pool address, observation time and source coverage, then examine whether the scoring policy itself changed.
What did pass the narrower reviewed-feed test?
Two other October 7 cases—SM and TKN247—kept the same selected pool in their stored before/after records and passed a separately documented AI-assisted retrospective editorial review for Jepeta's narrowly defined first-party observations. That approval covers what Jepeta's system recorded; it is not independent verification of raw historical provider measurements or a judgment about either token.
The distinction is operationally important: a working news feed should not treat an automated signal, a reviewed internal calculation and independent market corroboration as equivalent. Jepeta's external publisher feed only includes its specifically reviewed records, and still requires third-party editors to decide whether any are newsworthy.
Reproduction: a small, bounded cohort
Population: every row with a non-null publication timestamp in Jepeta's `jepeta.live_intelligence_events` table at the audit time. Count: 13 published events; unpublished or withdrawn events were excluded. Calculation: compare the two exact stored fields `payload.context.previous_pool` and `payload.context.pool` per event. Five differ and eight match. The numerator is divided by thirteen and rounded to one decimal place. Scores are read from the original event payload, never recomputed under a new version.
Jepeta retained the per-event identifiers and selected-pool fields for this audit. The public Intelligence catalog exposes the corresponding dated reports, and the methodology describes the limitations of a screening result. Historical raw third-party provider bodies were not independently reproduced, so the audit proves an internal metadata classification, not that the underlying external markets changed in a particular way.
What analysts and readers can do with this
Before citing a token risk-score movement, ask five questions: Was the token contract identical? Did the selected DEX pool stay the same? Were the observation timestamps and methodology versions comparable? Which provider fields were missing or uncertain? Did an independent reviewer check the inference being made, rather than only the arithmetic? If any answer is unknown, describe the output as a dated screening observation and preserve the uncertainty.
Bottom line: this small first-party audit identifies a specific failure mode for interpreting automated risk headlines. It does not establish error rates for other projects, estimate market-wide prevalence or recommend trading any named token. The useful lesson is to keep market identity attached to every before/after claim. Jepeta's screening products and commercial relationships did not determine this classification.
Jepeta evidence and method
- jepeta data — Read-only cohort extraction of 13 published first-party Base Intelligence payloads, retaining exact before/after selected pool identifiers, score outputs and 13 canonical event URLs. · evidence · observed Oct 9, 2026
- calculation — Recomputed event-level pool identity comparison: 5 changed, 8 unchanged out of 13 published events; 5/13 rounds to 38.5%. Two ZED event rows are counted separately. · evidence · observed Oct 9, 2026
Editorial transparency
This article was prepared with AI-assisted tools and an evidence-oriented source review. Citations and limitations are provided below. Documentation comparison is not a hands-on test; historical content is not automatically certified under the later independent editorial review process. Editorial standards and corrections.
Sources
- Jepeta published Live Intelligence event catalog — Oct 7–8, 2026 · primary · verified Oct 9, 2026
- Jepeta risk-screening methodology and evidence limitations · primary · verified Oct 9, 2026
- DEX Screener official API reference — pairs and token-pairs endpoints · primary · verified Oct 9, 2026
- CoinGecko official onchain API — top pools by token address · primary · verified Oct 9, 2026
- Jepeta editorially reviewed publisher feed and publication decisions · jepeta · verified Oct 9, 2026