API methodology

Valueverse API Methodology

Valueverse exposes normalized token economics from the Vega serve read plane, not a raw market-data feed. The API is designed around holder FCF, effective capital, P/FCF multiples, stream-level economics, methodology, verification, and curated supporting charts.

What we expose

Token economics

The API is centered on holder FCF, effective capital, P/FCF multiples, stream mix, methodology, verification state, and curated charts.

What we avoid

Raw provider dumps

Provider and Dune details stay behind serve. Public clients get normalized product surfaces and source metadata.

How to trust it

Sections and verification

Responses expose section readiness and verification summaries for agents and alerts. Customer UI should hide unsupported charts instead of showing debug badges.

Product Model

The API answers a product question first: what token economics are visible, comparable, and explainable?

A normal market API tells you price, supply, and market cap. Valueverse starts from a different model: for each covered token, we identify holder-relevant revenue streams, normalize the capital base those streams should be compared against, and expose the resulting multiples and supporting evidence.

The contract is intentionally mixed. Some fields are shared across every covered token, while stream labels, chart keys, formulas, and chart row schemas remain token-specific because token designs are not uniform.

Metric Glossary

The core terms users need before reading screener rows, token snapshots, or history series.

Holder FCF

revAnnualized, revenue.*, combinedRevenue

USD value the methodology treats as holder-relevant free cash flow or direct economic accrual: fees, buybacks, burns, distributions, staking yield, or token-specific paths.

Annualized FCF

revAnnualized, windows.*.rev

The selected holder-FCF run rate for the token or stream. It is annualized from trailing windows rather than exposed as raw daily revenue.

Effective market cap

effMcap

The capital base Valueverse compares against holder revenue. It may be market cap, a lockup-adjusted slice, or another token-specific effective base.

Effective ratio

effRatio

Effective market cap divided by reported market cap. It is not forced into a 0-1 range because some methodologies use composite or protocol-level capital bases.

P/FCF multiple

multAnnualized, windows.*.mult, erm_* history aliases

Effective market cap divided by annualized holder FCF for a window. Lower values mean the effective capital base is smaller relative to the current FCF run rate.

FCF momentum

fcfMomentum

Compact signal for whether recent holder FCF is improving or deteriorating against the longer run rate.

Windows

Holder FCF and multiples are annualized over trailing windows. They are not raw daily labels.

7d   = trailing calendar week, annualized with x52
30d  = trailing calendar month, annualized with x12
90d  = trailing three months, annualized with x4
180d = trailing six months, annualized with x2
365d = trailing year, annualized with x1

P/FCF(window) = effectiveMarketCap / annualizedHolderFcf(window)

Windowed metrics show the current revenue run rate at different horizons. A 30d multiple compares the effective capital base with a one-month holder-FCF run rate annualized by twelve.

Shared And Token-Specific Data

The API has one common contract, but token economics decide which details exist.

Shared across covered tokens

priceUsd
mcap
effMcap
effRatio
revAnnualized
multAnnualized
windows.7d
windows.30d
windows.90d
windows.180d
windows.365d
fcfMomentum

Token-specific by design

revenue stream keys and labels
stream mix and stream-level multiples
methodology cards and formulas
chart keys and chart row schemas
chart freshness and coverage state
verification summaries and gap entries

Data Surfaces

Read the catalog first, then choose the endpoint that matches the analysis.

GET /v1/tokensToken catalog

Start here to enumerate covered slugs and snapshot hrefs.

GET /v1/screenerMain table

The computed multiplier table used by the product: effective capital, annualized FCF, P/FCF windows, streams, and freshness.

GET /v1/tokens/{slug}Token snapshot

Current per-token product shell: KPI cards, stream structure, fundamentals, methodology, section readiness, verification, and chart definitions.

GET /v1/tokens/{slug}/metrics/historyHistory series

Normalized serve trend data for the token. A null data field means the series is not materialized yet.

GET /v1/tokens/{slug}/chartsChart catalog

Lists curated chart keys for that token, including title, supported timeframes, and the data endpoint path.

GET /v1/tokens/{slug}/charts/{chart_key}Chart data

Renderer-neutral chart payload with series config, rows, date bounds, freshness, and current timeframe.

Charts And Schema

Curated charts are evidence payloads, not a promise that every token has the same raw columns.

Chart catalogs are per-token because each token has different economics. The chart data endpoint exposes renderer config, date bounds, rows, and freshness. Provider details are intentionally not part of the public API.

{
  "id": "revenue",
  "type": "combo",
  "currentTimeframe": "90d",
  "dataThrough": "2026-06-29",
  "config": {
    "title": "Revenue",
    "series": [
      { "key": "rev_30d_ann", "label": "Ann. Revenue", "render": "line" }
    ]
  },
  "data": [
    { "timestamp": "2026-06-29", "rev_30d_ann": "12345.67" }
  ]
}

To inspect the shape of a chart, use config.series and row keys. Do not assume chart rows match history rows: chart schemas are token-specific, while history is the normalized serve trend surface.

Coverage, Nulls, And Alerts

Missing data is a verification signal for agents, not something to render as a customer-facing warning badge.

Coverage is explicit through snapshot sections, chart catalogs, verification summaries, and problem responses. A token can have a screener row and snapshot while lacking charts or history for a specific period.

Null values mean unavailable, unsupported, stale, or not meaningful for the token's methodology. Product UI should omit unsupported charts or panels. Verification agents should alert operators when expected surfaces stop rendering or drift from canonical data.

7d = trailing calendar week, annualized with x52 30d = trailing calendar month, annualized with x12 90d = trailing three months, annualized with x4 180d = trailing six months, annualized with x2 365d = trailing year, annualized with x1 P/FCF(window) = effectiveMarketCap / annualizedHolderFcf(window)

{ "id": "revenue", "type": "combo", "currentTimeframe": "90d", "dataThrough": "2026-06-29", "config": { "title": "Revenue", "series": [ { "key": "rev_30d_ann", "label": "Ann. Revenue", "render": "line" } ] }, "data": [ { "timestamp": "2026-06-29", "rev_30d_ann": "12345.67" } ] }