How BarryGuard Measures the Cost of Every Token Analysis

Every time BarryGuard analyzes a token, it runs up to 23 on-chain checks across multiple data providers. Some checks need a single request. Others chain several calls together — fetching contract metadata, holder counts, liquidity depth, and deployment history in parallel. The total number of requests per analysis varies significantly depending on the token, the chain, and how much data each provider returns on the first try.

Until now, we knew the outcome of every analysis — the risk score, the check results, the provider that delivered the data — but we had no structured record of what each individual analysis actually cost in terms of provider requests and credits. That gap made it hard to answer basic operational questions: Which tokens are expensive to analyze? Which providers carry the most load? When does deduplication actually save resources?

What the new telemetry records

BarryGuard now attaches a cost summary to every token analysis. The summary records the total number of provider requests made during that analysis, broken down along several dimensions:

• Provider: Which data provider handled each request — including how many requests went to each provider and what that translates to in credit terms.
• Transport: Whether the request used a standard RPC call, a DAS batch call, or another specialized data path. Different transports have different credit weights with most providers.
• Phase: Whether the request was part of the hot path — the initial parallel fetch that runs on every analysis — or a follow-up call triggered by something found in the first phase.
• Deduplication: How many requests were skipped because a valid cached result was already available. A cache hit costs nothing; the telemetry tracks both hits and misses so the actual savings are visible.

Where the data shows up

The telemetry is admin-only. It surfaces in two places inside the BarryGuard admin panel:

• Admin Tokens view: Each cached token entry shows its analysis cost summary — useful for spotting outliers that consistently consume more resources than comparable tokens.
• Admin Activity feed: Individual analysis events include the request count and credit estimate alongside the usual score, tier, and source information.

Neither view is visible to regular users. The data is purely operational.

What this means for users

For most users, this change is invisible. Scores work the same way. Analysis speed is unchanged. Nothing about how BarryGuard checks a token has changed.

What changes is how reliably we can keep provider budgets in check. Every provider that powers BarryGuard — for fetching holder data, contract source, liquidity depth, and more — has monthly credit limits. Without per-analysis cost visibility, the only way to catch problems is after they happen: when a provider starts throttling or when a budget runs low at the end of the month.

With per-token cost telemetry, we can act earlier. If a specific category of token — say, very old contracts with unresolvable deployers — consistently triggers expensive fallback chains, we can tune the analysis pipeline before it creates pressure on provider budgets. That means fewer degraded analyses and fewer cases where provider limits force a score to fall back on incomplete data.

No impact on scoring

The telemetry is purely observational. It records what happened during an analysis — it does not influence how the analysis runs or what score a token receives. The 23 checks run exactly as before. Provider routing, retry logic, and deduplication are all unchanged. The cost record is appended after the analysis completes.

This design is intentional. Cost data should inform how we optimize the platform over time — not which tokens get cheaper or more expensive analyses in real time.

What comes next

The telemetry ships today with collection and display enabled. The next step is to build aggregate views — cost per chain, cost per tier, cost trends over time — so we can spot systematic issues before they affect reliability.

For now, the goal is straightforward: know what each analysis costs, so we can keep the platform stable as the number of supported chains and checks continues to grow.

Check a token now →