BIGHT token markInfraVerifiable Storage

Proof

How Infra proves work.

See the witness, memory, storage, receipt, query, retrieval, repair, and challenge categories underneath the user-facing Verify and Retrieve paths.

Choose the next Infra action.

Wallet, purchase, storage, proof, retrieval, contracts, and status are kept as separate product lanes.

Public categories

Outcome labels that can be wired to live public feeds later.

Witness

Whether public witness state is available and fresh enough to inspect.

Memory

Whether retained public state can be located and summarized.

Storage

Aggregate storage readiness and retained-state labels.

Receipts

Public receipt export status and summary availability.

Receipt metadata

Receipt ID, source, class, height or epoch, root or hash, retention, proof, challenge, expiry, and disclosure posture can be public.

Paid memory

Later lookup, detailed retrieval, certified reissue, reconstruction, retention proof, linkage proof, and challenge history are BIGHT-paid services.

Queries

Whether public query surfaces are staged, testing, live, or unavailable.

Exports

Public-safe export freshness for testing evidence and status snapshots.

Storage proof model

Infra separates hot retrieval from cold retention, while cold records still require periodic hot-path verification.

Retrieval challenge

Providers must serve requested chunks when challenged before the service path is treated as healthy.

Merkle possession

Possession checks bind a served chunk to the expected object root without publishing private operator procedure.

SLA consequence

Missed hot retrieval, failed cold proof, or repeated repair failure can move the actor toward penalty, quarantine, or reassignment.

Replica audit

Audits can sample across replicas so redundancy is measured as actual coverage, not just declared count.

Cold plus hot

Cold retention uses proof and retrieval checks; hot query does not need cold-proof escalation

Receipt body boundary

Payload contents stay redacted by default.

State machine

Objects move through explicit lifecycle labels such as new, hot, cold, expired, or deleted instead of relying on vague storage state.

Challenge and repair path

Failures move through evidence, response, verdict, consequence, appeal or escalation, repair, and terminal receipt. A failed provider cannot be punished, paid, or erased from the object story by one shortcut.

Challenge path

Awaiting live data

Challenge evidence, provider response windows, appeal outcomes, repair proofs, quarantine updates, and terminal receipts remain separate facts. Public labels show the path without exposing private verifier procedure or payload bytes.

Receipt proof model

The receipt is the public handle. Infra can prove and serve metadata without turning private content into public content.

Receipt policy

Awaiting live data

Repair fallback

Native repair helpers are last-line local mechanics. Go classifies the repair first, and promotion requires receipt, hash, proof, atomic move, fsync, and backup evidence.

Fallback proof

Awaiting live data

Current labels

Loaded from data/infra-stats.json.

WitnessAwaiting live data
MemoryAwaiting live data
StorageAwaiting live data
Total storageAwaiting live data
Used storageAwaiting live data
ReceiptAwaiting live data
Receipt entitlementAwaiting live data
Public metadataAwaiting live data
QueryAwaiting live data
ExportAwaiting live data

What public proof can show

  • Whether data is labeled staged, testing, live, delayed, stale, or unavailable.
  • Whether public receipts or query summaries exist.
  • Whether generated event labels are present for public inspection.
  • Whether a public exporter has refreshed recently.

What stays out

  • Private proof thresholds and verifier procedure.
  • Operator-sensitive storage and repair paths.
  • Exploit-sensitive timing or emergency steps.
  • Raw zone-stake multipliers or unbounded provider routing shortcuts.
  • Any claim that Infra evidence becomes another chain's meaning by default.