Historical supplement — 27 October 2026: This non-normative update was issued alongside Final Publication Edition 3.3. It does not independently change that archived edition. Final Publication Edition 3.4 is now the controlling whitepaper and incorporates the four-network implementation clarification. The original Edition 3.3 DOCX remains preserved.
Why this update exists
The published Edition 3.3 reader, dated 16 October 2026, still describes Ethereum, Solana and Avalanche as the initial engineering focus in Chapters 36 and 40. That was an earlier cohort. The current Phase-1 engineering programme is Ethereum, Avalanche C-Chain, BNB Smart Chain and TRON; Solana is paused.
This update supersedes only the historical implementation-cohort description in those two chapter passages when discussing the present development programme. All canonical six-parent, 30-submetric definitions, equal weights, evidence rules, storage governance and Edition 3.3 macroeconomic scope remain unchanged. Nothing here establishes production-certified collectors or all-chain metric eligibility.
Clarification to Chapter 36 — Roadmap
The current Phase-1 implementation programme covers Ethereum, Avalanche C-Chain, BNB Smart Chain and TRON as four independently governed engineering networks. Solana, included in earlier development, is paused. This scope is not a declaration of completed certification, continuous evidence coverage, metric readiness or official scoring. Those claims require separately identified evidence, tests and approval gates for each network.
Clarification to Chapter 40 — Vox-in-a-Box
The current four-network engineering programme covers Ethereum, Avalanche C-Chain, BNB Smart Chain and TRON. Solana is paused. Vox-in-a-Box remains an independently governed distributed evidence-node architecture; this specification does not assert that a production network of such nodes is already deployed. Collector qualification, node qualification, archive reconstructability, metric certification and public publication remain separately governed.
Technical scope and verification boundaries
1 Purpose and current scope
The current Phase-1 acquisition programme covers Ethereum, Avalanche C-Chain, BNB Smart Chain and TRON. These networks are distinct measurement subjects, not interchangeable sources of one combined score. Solana was included in earlier development and is currently paused.
The four-network scope identifies the systems being engineered and evaluated. It does not certify all four collectors, all historical intervals, all adapter capabilities or all thirty submetrics.
2 Shared architecture and chain isolation
Each network requires an independently identifiable collection lane, source identity, progress frontier, evidence namespace, verification state and recovery boundary. Shared collector contracts must not permit one network to overwrite or validate another network's evidence.
Chain-specific source acquisition feeds common evidence and measurement interfaces. Universal definitions remain stable while network adapters supply the technically correct observations.
3 Ethereum
Ethereum evidence acquisition must account for execution-layer records and the applicable consensus-layer finality model. Block, transaction, receipt, event and state evidence must be interpreted within the declared source and finality scope. A visible chain head is not the same as a verified contiguous evidence frontier.
4 Avalanche C-Chain
Avalanche C-Chain is EVM-compatible but retains its own network identity, consensus environment, source interfaces and finality requirements. Its acquisition configuration and stored evidence must remain independent of Ethereum and BNB.
5 BNB Smart Chain
BNB Smart Chain uses an EVM-compatible execution environment with its own consensus, finality, provider and operational characteristics. Correct receipt extraction or block availability on another EVM network cannot substitute for BNB-specific source verification.
6 TRON
TRON requires native chain-specific block and transaction interpretation. EVM receipt assumptions must not be applied mechanically to TRON data. Block identity, chain timestamps, transaction representation, source agreement and finality must be verified under the TRON adapter contract.
A recent block observation does not by itself establish an independently verified transaction count. A missing count must remain unavailable, not become zero. Top-level transactions, internal execution activity and economically admitted transfers are separate concepts.
7 Collection progress and operational status
Service process state must be distinguished from durable collector progress, finality and verified contiguous coverage. A running service can be lagging, refusing an untrustworthy source response or missing a required evidence class.
Public statements about collector uptime, live transaction visibility or completed certification require dated, independently reviewable telemetry and qualification evidence. This supplement makes no fresh runtime or uptime certification claim.
8 Integrity, completeness and refusal
Progress claims require a declared network, coordinate range, completeness denominator and evidence-validation result. Maximum observed heights or slots do not alone prove a gap-free committed range.
Unknown, missing, unavailable, malformed or source-disputed data must retain its correct status and provenance. Failure must not be represented as valid zero activity.
9 Durable preservation and retirement
The operational storage target includes a thirty-day rolling active evidence window. This is distinct from any metric's analytical horizon and must not be interpreted as an automatic deletion threshold.
The inherited STAGE → SEAL → VERIFY → RELEASE governance remains unchanged. Evidence older than the active window may be relocated or retired from primary storage only after the required preservation, reproduction and audit conditions have been proven.
A digest is not a recoverable copy. The system must preserve independently readable evidence and establish reconstructability before claiming archive safety.
10 Vox-in-a-Box and distributed verification
Vox-in-a-Box is intended to support independent acquisition, custody, replication, verification and reproduction of evidence. Node independence does not authorise independent rewrites of canonical metric definitions.
Operational deployments, replication coverage, signing arrangements and independent restore tests require specific evidence before being described as production-ready.
11 Economic measurement boundary
The framework retains thirty canonical submetrics under six equally weighted parent indices. PoV.ES is an initial measurement-engineering priority; source capture, admitted observations, canonical measurements, parent calculations and official VTS publication are separate qualification stages.
This dated scope update neither authorises official scores nor changes any formula, metric weight, inclusion rule, confidence threshold or missing-evidence policy.
12 Public API and dashboard
The intended public API and dashboard are read-only publication interfaces. They must not have routine authority to alter collector state, canonical evidence, source journals or measurement definitions.
Live operational telemetry must show its observed status, freshness and limitations separately from research results and publication-approved scores.
13 Qualification and publication gates
No complete four-collector certification is declared by this supplement. Each network must independently satisfy scoped correctness, provenance, finality, continuity, restoration and adversarial failure checks.
A future final edition requires a fully matched HTML reader, downloadable document and publication record, plus reconciliation against the authoritative runtime, code and preserved qualification evidence. This status note is not a substitute for those gates.
Publication and evidence boundaries
This supplement does not claim that every collector is qualified, historical interval recoverable, node independently replicated or submetric production-approved. Only chain-, metric- and date-scoped evidence with inspectable provenance can justify such statements. The current official score count on the public website is zero.
Any future change to canonical definitions or publication authority requires versioned governance and independently reviewable proof. Final Publication Edition 3.3 remains available in its archived reader and downloadable DOCX. The current Edition 3.4 whitepaper supersedes it with a governed, versioned update; this dated note is retained for provenance.