BIS Working Paper 1377: What noisy on‑chain metrics mean for RWA issuers

Key facts from the BIS working paper

• The BIS Working Paper No. 1377 (published 15 September 2026) examines the limits of translating raw blockchain execution into economically meaningful activity measures and highlights the methodological sensitivity of common on‑chain aggregates ([BIS Working Paper No. 1377](https://www.bis.org/publications/working-paper-1377-hidden-complexity-measuring-stablecoin-crypto-and-decentralised-finance-ecosystems)).
• The authors show that aggregation choices can change transaction‑value estimates by large margins (a Bitcoin example in the paper shows variation by up to a factor of six depending on methodology).
• They identify three structural sources of divergence: aggregation rules for transactions, the proliferation of smart contracts and tokens (many of which are spurious for economic measurement), and non‑comparable use cases across chains (for example, stablecoin activity serving different roles on Ethereum versus Tron).
• Their dataset classifies roughly 13 million active smart contracts and about 1.4 million tokens, underlining scale and noise that can mislead simple ownership or activity metrics.
• The authors propose a toolkit—explicit technical classification, disaggregation and bounded assumptions—to better align blockchain execution with economic meaning, a toolbox directly applicable to cap‑table, investor reporting and compliance workflows.

What those facts mean for founders and institutional issuers

H2: Treat on‑chain metrics as model outputs, not indisputable facts

The core implication is simple: an on‑chain metric is only as informative as the assumptions that produced it. If your cap‑table, investor reports or AML controls rely on a single vendor's “on‑chain holdings” or “active user” counts, those numbers may be method‑dependent. The BIS shows the same raw data can be turned into substantially different measures based on aggregation and classification choices ([BIS Working Paper No. 1377](https://www.bis.org/publications/working-paper-1377-hidden-complexity-measuring-stablecoin-crypto-and-decentralised-finance-ecosystems)).

H3: Practical implications for cap‑tables and token ownership

• Ownership snapshots: Don’t publish a cap‑table that equates token‑holding addresses with distinct investors without documenting de‑duplication rules (e.g., exchanges, custodians and contract wrappers can create many addresses that represent one economic owner).
• Voting power and dilution: When token supply or circulating estimates depend on contract classification, any downstream governance or dilution calculation must specify how “active circulating supply” was derived.

H3: Investor reporting and due diligence

• Vendors’ methodology matters. Ask data providers for explicit classification rules, their treatment of layered contracts, and how they attribute value flows (the BIS recommends a toolkit focused on classification and bounded assumptions).
• Supply alternative views. Provide both “raw on‑chain aggregates” and “economically classified” metrics, with a short methods annex describing exclusions, aggregation rules and uncertainty ranges.

H2: How issuers should design measurement‑aware workflows

H3: 1) Adopt a disclosure‑first approach

Document the exact definitions you use for metrics that matter to investors (for example, circulating tokens, top holders, locked supply). Reference the vendor methodology or your internal classifier. Investors will value reproducibility over headline numbers.

H3: 2) Select vendors by transparency, not just coverage

Prioritize providers who publish their classification logic, sample code or appendices detailing aggregation rules. Where possible, prefer vendors offering disaggregated feeds (contract‑level attributions, token archetypes) versus opaque summary indices.

H3: 3) Maintain dual reporting during migration

If you switch vendors or adopt a BIS‑style toolkit, publish both the old and new series for a transition period so investors can reconcile historical numbers. Explicitly note any methodological breaks.

H3: 4) Build provenance into investor‑facing artifacts

Embed the source of on‑chain measures (block numbers, snapshot hashes, vendor API versions) in investor reports and cap‑table exports so auditors and counter‑parties can reproduce claims.

H3: 5) Be conservative with attribution across chains and wrapped assets

Where assets move across chains (bridges, wrapped tokens) disclose the mapping logic and the uncertainty introduced by multi‑chain flows.

H2: What remains uncertain (and why founders should care)

The BIS paper is aimed at public chains; questions remain about how the toolkit will be adopted by market data vendors, whether regulators will require standardised methodologies for on‑chain disclosures, and how the recommendations map to private or permissioned ledgers. Founders should therefore design their reporting to be adaptable: explicit methods, reproducible snapshots and vendor‑agnostic provenance make compliance and investor due diligence simpler if standards evolve.

H2: Short practical checklist for token issuers

• Publish definitions and methodology for every on‑chain metric used in reporting.
• Require vendors to provide classification logic or choose vendors that do.
• Release provenance metadata (snapshot hashes, API versions) with cap‑tables.
• Present alternative measures where feasible (raw vs classified) and note uncertainty ranges.
• Plan for transition periods when changing metrics or vendors.

The BIS toolkit reframes on‑chain numbers as interpretive outputs. Issuers who operationalise that insight—through transparent methods, provenance and careful vendor selection—will produce reports that investors can audit, regulators can assess, and counterparties can rely on.