Methodology v0.1

Metric methodology

Canonical counting rules for LumenMap metrics. These definitions are descriptive of how the product measures activity; they are not marketing claims about network health or protocol performance.

← Back to dashboard

Operations

Count of Stellar operations closed in the selected period, grouped by operation type.

Unit
operations (count)
Aggregation
COUNT(*) of operations; dashboard totals sum type counts.
Time basis
Inclusive wall-clock period using the server period resolver (Today, last 7/30 days, or calendar month).
Source
`crypto-stellar.crypto_stellar_dbt.enriched_history_operations.type_string` filtered by `closed_at`.

Inclusions

  • All operation types present in Hubble for the period
  • Soroban and classic operations

Exclusions

  • Failed or non-closed operations not present in the enriched closed-at feed
  • Mempool / unconfirmed activity

Known limitations

  • This is not a transaction count; one transaction may contain multiple operations.
  • Hubble batch lag can understate the most recent partial day.

Transactions

Count of distinct transactions that closed in the selected period. Not currently shown as a dashboard KPI.

Unit
transactions (count)
Aggregation
COUNT(DISTINCT transaction hash / id) over closed transactions.
Time basis
Same selected period bounds as operations.
Source
Hubble transaction / operation linkage tables (planned surface; not queried by the current KPI cards).

Inclusions

  • Closed transactions in the period

Exclusions

  • Operations within a transaction are not counted here
  • Unconfirmed submissions

Known limitations

  • Transaction count and operation count are different metrics and must not be compared as equivalents.
  • Not exposed in the current dashboard UI.

Payment volume

Asset-denominated payment amounts moved in the period. Not currently shown as a dashboard KPI.

Unit
asset units (for example XLM or USDC), never a mixed-asset total without normalization
Aggregation
SUM of payment amounts per asset code/issuer. Cross-asset totals require an explicit FX normalization rule.
Time basis
Same selected period bounds as operations.
Source
Hubble payment amount fields on enriched payment operations (planned).

Inclusions

  • Payment and path-payment style transfers when enabled

Exclusions

  • Non-payment operation types
  • Unnormalized multi-asset rollups

Known limitations

  • LumenMap does not present a single cross-asset volume total without a documented normalization method.
  • Not exposed in the current dashboard UI.

TVL (total value locked)

Point-in-time estimate of value committed to protocols at a snapshot. Not currently shown as a dashboard KPI.

Unit
quoted currency at snapshot time (for example USD), after documented pricing
Aggregation
Sum of protocol balances at a timestamp; protocol adapters must state double-counting rules.
Time basis
Point-in-time snapshot, not a period sum.
Source
Protocol-specific reserve / pool state (planned; no default adapter yet).

Inclusions

  • Balances explicitly held by supported protocol contracts

Exclusions

  • Wallet balances not locked in a protocol
  • Unpriced or unverifiable reserves

Known limitations

  • TVL is sensitive to oracle price choice and can double-count assets bridged across protocols.
  • Not exposed in the current dashboard UI.

Active accounts (source)

Distinct account public keys that sourced qualifying operations in the period.

Unit
accounts (distinct count)
Aggregation
COUNT(DISTINCT op_source_account) for closed operations in-range.
Time basis
Same selected period bounds as operations.
Source
`enriched_history_operations.op_source_account` filtered by `closed_at`.

Inclusions

  • Accounts that appear as operation source accounts

Exclusions

  • Accounts that only receive payments without sourcing ops
  • Contract IDs and muxed accounts (M...)

Known limitations

  • The treemap account list is top-N capped per operation type and is not the full active-account universe.
  • Hubble lag can delay the newest hours.

Active destination accounts

Distinct classic accounts that received qualifying payment, path-payment, account-creation, or merge operations in the period.

Unit
accounts (distinct count)
Aggregation
COUNT(DISTINCT destination_account) across payment-style operation types.
Time basis
Same selected period bounds as operations.
Source
`enriched_history_operations` destination fields (`details.to`, `details.new_account`, `details.into`) for selected types.

Inclusions

  • G... accounts receiving payment, path payment, create_account, or account_merge

Exclusions

  • Source-only wallets that never received qualifying ops
  • Contract IDs, empty identifiers, and muxed accounts

Known limitations

  • Destination semantics differ from source active wallets; do not sum the two KPIs as a deduplicated user count.
  • Only the documented operation types contribute to the destination count.

Active contracts

Soroban contracts with fee / invoke activity in the period, as returned by the contract activity query.

Unit
contracts (count)
Aggregation
Number of contract IDs returned by the period contract leaderboard query after grouping.
Time basis
Same selected period bounds as operations.
Source
`crypto-stellar.crypto_stellar_dbt.hourly_soroban_fee_agg_contract` grouped by `contract_id` with null/empty IDs removed.

Inclusions

  • Contracts with non-empty contract_id and activity in-range

Exclusions

  • Null or empty contract IDs
  • Non-contract classic accounts

Known limitations

  • The current KPI uses the leaderboard result length, which is capped (top 200), so busy periods can undercount.
  • Hubble lag can delay the newest hours.

Soroban share

Share of period operations whose type maps to the Soroban category.

Unit
percent of operations
Aggregation
(Soroban-category operation count / total operation count) × 100.
Time basis
Same selected period bounds as operations.
Source
Derived from operation type totals using LumenMap category mapping (`invoke_host_function`, footprint ops → Soroban).

Inclusions

  • Operations mapped to the Soroban category

Exclusions

  • Classic payment, DEX, trustline, and account categories

Known limitations

  • Category mapping is product-defined; raw Hubble types remain available in treemap drill-down.
  • Undefined when total operations are zero.

Top category

The LumenMap activity category with the largest operation count in the period.

Unit
category label
Aggregation
Argmax of summed operation counts across category groups.
Time basis
Same selected period bounds as operations.
Source
Derived from operation type totals and `TYPE_TO_GROUP` mapping.

Inclusions

  • Soroban, Payments, DEX, Trustlines, Account Operations, Other

Exclusions

  • Entity-level rankings (accounts/contracts)

Known limitations

  • Ties resolve by sort order of aggregated totals; label is categorical, not a numeric volume.

Time basis and partial periods

How LumenMap bounds Today, multi-day windows, and the calendar month.

Unit
n/a
Aggregation
n/a
Time basis
Period start/end come from the dashboard period control. The current day or month can be partial until the period ends.
Source
`lib/periods.ts` period resolver used by `/api/activity`.

Inclusions

  • Closed operations with `closed_at` inside the resolved bounds

Exclusions

  • Activity outside the selected bounds

Known limitations

  • Partial current periods are expected to grow as new Hubble batches arrive.
  • Host timezone can affect local period boundaries until an explicit UTC policy is enforced.

Hubble freshness

Analytics numbers follow Hubble’s batch refresh, not sub-second chain tip state.

Unit
n/a
Aggregation
n/a
Time basis
Intraday Hubble batches; exact lag varies.
Source
Stellar Hubble BigQuery datasets.

Inclusions

  • Data present in the Hubble tables at query time

Exclusions

  • Unindexed tip activity

Known limitations

  • Recent intervals can under-report until the next Hubble refresh.
  • API responses may be cached for several minutes server-side.

Payment-flow graph

The Flow view draws value movement between Stellar accounts in the selected period as a directed graph. It is a descriptive sample of payment edges from Hubble, not a complete ledger of transfers and not a measure of network health. The graph uses the same period, inclusive time predicate, partial-period, and Hubble freshness conventions as every other LumenMap metric.

Nodes

  • A node is one Stellar account ID that is the source or destination of at least one edge in the rendered sample. Each account appears once, however many edges touch it.
  • Labels come from entity directory data and fall back to a shortened account ID. A label or category (exchange, protocol, …) changes the display name only, never the node identity.
  • Node metrics are in/out operation counts, in/out degree (distinct counterparties), and in/out volume per asset. Node size and degree describe the sample only; they are not network-wide totals for that account.

Edges

  • An edge points from the source account to the destination account of a successful operation of type payment, path_payment_strict_send, path_payment_strict_receive, create_account (funding edge), or account_merge (drain edge).
  • Operations between the same source and destination in the same asset are collapsed into one edge whose amount and operation count are the sums of those operations. The same account pair can therefore have one edge per asset.
  • Failed operations, self-payments, rows without a source or destination, and all other operation types (DEX offers, liquidity-pool flows, fees, …) are not edges.
  • Edge amounts are not the Payment volume metric: that metric counts direct payment operations only, while the graph also shows path payments, funding, and drains.

Sampling and coverage

  • The graph renders the top-N edges of the period, ranked by operation count and then by amount within the same asset. Edges below the cut are omitted, along with nodes that only they touched.
  • The coverage badge reports returned versus total edges and returned versus total operations, and marks the graph as sampled when edges were dropped. Read absences as “not in the sample”, not “no activity”.
  • Hubble freshness applies: recent ledgers can be missing, and a range containing the current day is partial and provisional.

Asset modes

  • Every edge is denominated in exactly one asset, identified by asset code and issuer; native XLM is its own explicit bucket. Asset modes (for example XLM or USDC) filter the graph to edges of that asset.
  • Amounts in different assets are never summed. Edge thickness and node volume are comparable only within one asset mode, and an issued asset code is only meaningful together with its issuer.
  • Amounts are in the asset's own units; the graph applies no price or fiat conversion.