> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rwa.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Quality

> Refresh cadence, validation, anomaly detection, and error handling

## Refresh cadence

| Data type                                      | Frequency   | Timing                                      |
| ---------------------------------------------- | ----------- | ------------------------------------------- |
| On-chain metrics (supply, holders, transfers)  | Daily       | Midnight ET                                 |
| Pricing data                                   | Daily       | Midnight ET                                 |
| Issuer-reported data (NAV, fees, fund details) | As reported | Typically daily or weekly, varies by issuer |
| Qualitative data (descriptions, legal info)    | As updated  | Reviewed and published by our team          |

## Validation pipeline

Data passes through multiple validation stages before appearing on the platform.

### On-chain data validation

* **Cross-reference verification:** On-chain metrics are cross-referenced against public block explorers (Etherscan, Solscan, etc.) to confirm accuracy
* **Supply consistency checks:** Total supply must be non-negative and consistent with mint/burn event history
* **Balance reconciliation:** The sum of all holder balances must equal the total supply

### Pricing data validation

* **Anomaly detection:** Automated systems flag prices that deviate significantly from expected ranges (e.g., >10% change from the previous day's value)
* **Cross-source verification:** When a flagged price is detected, we cross-check against the issuer, alternative exchanges, and on-chain price feeds
* **Stale price detection:** If a price feed stops updating, the asset is flagged for review rather than displaying the last known price indefinitely

### Issuer-reported data validation

* **Manual review:** All qualitative data submitted by issuers is reviewed by our team before publication
* **Document verification:** Key claims (jurisdiction, legal structure, regulatory registration) are cross-referenced against public filings and official sources
* **Change tracking:** Updates to issuer-reported data are logged, allowing us to audit changes over time

## Data gaps

When data is unavailable or unverifiable, we follow these rules:

| Scenario                                | Handling                                                                                        |
| --------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Data source goes offline                | Field is left blank; team contacts the issuer/network to investigate                            |
| Price feed becomes stale                | Field is flagged; not displayed until a fresh source is confirmed                               |
| On-chain data unavailable for a network | Metric is blank; the asset is marked with limited network support                               |
| Issuer stops reporting NAV              | NAV is forward-projected from the last known value until a fresh report is received             |
| Conflicting data from multiple sources  | Resolved using the [source priority hierarchy](/methodology/data-sources#source-prioritization) |

We never interpolate, extrapolate, or estimate missing values. If a data point is unavailable, the field is left blank.

## Edge cases

### Rebasing tokens

Tokens whose balance changes without transfers (e.g., stETH-style rebasing) require special handling. We track both the raw supply and the rebase multiplier separately, then compute the display supply from them. See [Metric Calculations](/methodology/metrics#raw-supply-and-rebase-multiplier).

### Bridged tokens

When a token is bridged to another chain, we track the bridged supply separately from the native supply. The asset-level total supply is the sum across all chains, but token-level metrics are reported per-chain. Bridge events are classified as bridge transactions, distinct from regular transfers.

### Multi-token assets

Some assets have multiple token deployments across different chains and platforms. We aggregate metrics at the asset level (sum of all tokens) and also report per-token metrics for chain-level granularity.

## Reporting errors

If you spot a data inaccuracy:

1. Email [team@rwa.xyz](mailto:team@rwa.xyz) with a description of the issue
2. Include the asset or token name, the field in question, and what you believe the correct value should be
3. A screenshot or link to a source is helpful but not required

We investigate and correct confirmed errors as quickly as possible. All corrections are logged internally.