How ForceX Verifies the Integrity of Published Data

Overview

ForceX is a data-quality-first platform. Each block we publish is evaluated through a defined control framework designed to verify the integrity of the published dataset. This page explains what those controls are intended to detect, how validation status is communicated, and how to interpret what you see in the Data Quality panel.

If you arrived here from a View data quality details link, the panel you saw is the live status view. This page is the broader reference guide to the methodology behind it.

Our approach

ForceX does not simply display blockchain data. It verifies the integrity of the data it publishes through a governed validation framework designed to detect structural defects, write-path issues, accounting drift, and divergence from source truth.

Each control produces a recorded result, including its outcome and the point at which it ran. The Data Quality panel summarizes the live validation state of the published dataset in a public-facing form.

The live panel is one part of a broader control framework

The Data Quality panel shows the current validation status of published data, but it is not the full extent of ForceX’s integrity controls. The live panel reflects one visible layer of a broader control system that also includes structural enforcement at write time, write-path controls during ingestion, broader reconciliation gates, rebuild safeguards, reorg validation, and external confirmation against the Litecoin node. The panel is the status surface of that work, not the entirety of it.

The four layers of integrity control

ForceX applies integrity controls across four distinct layers. Each layer is designed to detect a different class of failure.

• Structural constraints — invalid relational states are blocked by schema design. Primary keys, foreign keys, uniqueness rules, and check constraints prevent invalid rows from being committed in the first place.
• Write-path controls — per-block and inline checks confirm that the writer committed what it intended to write. These controls are designed to detect parser defects, partial writes, and disagreements between in-memory state and stored block-level results.
• Accounting reconciliation — balances, totals, counts, and supply-related values are reconciled across canonical and derived data surfaces so independently built paths remain aligned.
• External source cross-check — periodic node-level comparison confirms that ForceX is not only internally consistent, but also aligned with the Litecoin node as an independent source of truth.

Why all four layers are required

No single layer is sufficient on its own.

Structural enforcement can block invalid relational states, but it does not prove that a correctly stored result is also the correct result. Write-path controls can confirm a block was committed as intended, but they do not by themselves catch every longer-range accounting drift. Accounting reconciliation can prove independently built data paths agree, but internal consistency alone does not guarantee agreement with the Litecoin node. External confirmation closes that gap by testing ForceX against source truth outside the platform itself.

This is why the framework is layered rather than relying on one class of check alone.

Three failure classes ForceX is designed to detect and guard against

Blockchain indexes can fail in ways that are not always visible from the user interface alone. ForceX’s framework is designed to detect and guard against three important classes of failure:

• Internal accounting drift — derived balances, totals, or summaries diverging from canonical chain state.
• Write-path corruption or incomplete ingestion — data being partially written, duplicated, omitted, or miscounted while the explorer still appears functional.
• Source divergence — the index remaining internally self-consistent while drifting from the Litecoin node’s view of chain state.

How validation status is reported

The Data Quality panel distinguishes between two types of validation that run on different schedules:

• Per-block validation — controls that run on every newly indexed block at tip. In the current model, LVR-001 through LVR-013 make up the live per-block trust signal applied to published data at the latest indexed block.
• Periodic external confirmation — a cadence-based node cross-check. In the current model, LVR-014 compares ForceX’s indexed UTXO total against the Litecoin node’s gettxoutsetinfo at controlled checkpoint heights, with a default cadence of every 1,000 blocks.

As a result, the panel may show the dataset as validated through the latest block while the next external confirmation is still awaiting its cadence boundary. This is intentional. The panel reflects what has been validated and when, without implying that every control runs at the same cadence.

The three integrity domains

ForceX groups publicly disclosed live controls into three integrity domains. Each domain addresses a different aspect of the published dataset and is reported separately in the Data Quality interface.

• Monetary Integrity — verifies that published monetary values reconcile to real chain data and supply-related invariants.
• Address Integrity — verifies that balances, received totals, sent totals, and transaction counts reconcile across ForceX’s address records and transaction-level links.
• Block & Write Integrity — verifies that block-level composition and stored write results remain internally consistent with what ForceX ingested and committed.

Control framework at a glance

The live rules shown in the Data Quality interface are part of a broader control framework that currently includes:

• 14 post-catchup data quality rules
• 14 live validation rules
• 14 pre-swap validation checks before rebuilt tables are promoted
• 6 post-reorg validation checks after rollback and rebuild events
• 4 pre-live validation gates before live mode is entered
• 190 structural database constraint enforcement points at write time

Taken together, that is 242 enforcement points across 9 type codes in the current 3.3 specification.

What “live validation” means in practice

In the current model, live validation is not a periodic afterthought. It is an active part of how ForceX maintains trust at tip.

The framework includes:

• incremental reconciliation controls across address and value surfaces,
• inline MWEB write-path conservation checks,
• per-block structural anchors at tip for counts and supply-related invariants,
• and a periodic external node cross-check for source confirmation.

That means the published dataset is continuously assessed through a mix of per-block controls and scheduled external confirmation, rather than relying on a single batch process after the fact.

Why this matters

Most explorers display blockchain data. ForceX verifies the integrity of the data it publishes. Without ongoing reconciliation, write-path validation, and external confirmation, an index can drift from chain state while still appearing functional.

ForceX treats validation as part of the product itself. The Data Quality panel is where that validation becomes visible, but the underlying framework extends beyond the panel and operates across the full data lifecycle.

Direct node access is where integrity starts, not where it ends

Running a full node is necessary, but not sufficient. Any platform built on top of node data still has its own ingestion path, derived records, aggregates, caches, and opportunities for divergence.

ForceX’s validation layer exists because direct node access alone does not guarantee that the published index remains aligned with the node beneath it. That alignment has to be verified.

Evidence and recorded outcomes

A core part of the ForceX model is that validation is recorded, not merely implied. The framework writes durable results to validation records so controls have attributable outcomes rather than silent assumptions.

This is important because a validation system should not only run checks — it should preserve the evidence that those checks were executed and what they returned.

How these controls are described publicly

We believe published data should be accompanied by clear, public-facing explanations of how it is validated. The entries below describe what each publicly disclosed control verifies, why it matters, and what a passing result means.

They are written for transparency and clarity, while detailed implementation logic remains part of ForceX’s proprietary data quality framework.

Public control catalog

ForceX publishes public descriptions for its live validation rules. Each rule has a fixed identifier, a declared cadence, and a governed public description. Below is the full catalog of live controls currently disclosed in the Data Quality interface, grouped by integrity domain.

Final statement

ForceX does not simply display blockchain data. It verifies the integrity of the data it publishes, and the Data Quality panel shows that status clearly.