Snapshot Verification

Vorliq snapshots are deterministic public integrity manifests. They let community members compare chain height, latest block hash, transaction totals, treasury balance, active node count, deployment commit, public health statuses, SHA-256 hashes for public summaries and audit manifests, and optional Ed25519 signature metadata from one response.

Audit Summary

Vorliq can already verify audit export hashes, public chain links, latest block hash consistency, treasury ledger totals where possible, network manifest metadata, readiness status, storage health, derived index health, and JSON-to-PostgreSQL shadow rehearsal parity tooling. The missing layer was one public manifest that gathered the latest chain state, audit manifest hash, network manifest hash, storage/index/readiness signals, and secret-scan result in one place.

Deterministic snapshots help trust because independent users can fetch the same public endpoints, sort JSON keys, recompute SHA-256 hashes, and compare results without server access. Signed snapshots add public-key provenance by signing the canonical snapshot hash. Historical blocks, stored block hashes, confirmed transaction records, treasury ledger entries, and public governance history must remain immutable. Snapshots must not include private keys, wallet passwords, admin tokens, raw IP addresses, server paths, logs, environment variables, full analytics event lists, or raw user agents.

Snapshot Fields

• snapshot_version, generated_at, network_name, website, and api_base.
• chain_height, latest_block_hash, chain_valid, confirmed and pending transaction counts.
• treasury_balance, active_node_count, active_incident_count, and deployment_commit.
• Public storage_status, index_status, readiness_status, and the hashes map.
• signature metadata: Ed25519 algorithm, public key id, public key, snapshot hash, signature, signed timestamp, and status. Production snapshots are signed, and public key metadata is available at /api/snapshot/public-key.

Hash Inputs

Hashes use SHA-256 over canonical JSON with object keys sorted recursively. The snapshot hashes chain_summary, latest_block, transactions_index_summary, treasury_summary, governance_summary, lending_summary, exchange_summary, registry_summary, audit_manifest, and network_manifest.

The signed snapshot hash is SHA-256 over the canonical snapshot payload excluding the signature object. That hash is what Ed25519 signs.

Verify

node tools/verify_snapshot.js https://vorliq.org

node tools/verify_snapshot.js https://vorliq.org --require-signature

node tools/verify_snapshot_archive.js https://vorliq.org

node tools/bootstrap_verify_node.js https://vorliq.org

The CLI fetches /api/snapshot/latest and /api/snapshot/verify, confirms both agree on chain height and latest block hash, checks the verification result, scans for forbidden secret markers, verifies the Ed25519 signature, and exits non-zero on failure. Treat live snapshot verification as passing only when /api/snapshot/verify returns verified: true and signature_verified: true. Production uses required signatures; --require-signature should pass live.

The archive verifier checks the latest or selected archived signed snapshot and compares safe archive metadata against the embedded snapshot. The bootstrap verifier performs read-only checks before trusting a node as a source of public state.

What Snapshots Do Not Prove

Signatures prove control of the configured snapshot signing key for the signed payload only. They do not prove legal status, financial value, investment quality, custody safety, off-chain trade completion, or future network availability. Production remains JSON-backed in this release; PostgreSQL code is preparation-only and disabled. Snapshots complement audit exports by hashing their public manifest alongside the current public network manifest and health statuses.