Free data architecture

Free Data Persistence Methodology

How HypeBasis handles optional market, validator, alert, and HyperEVM snapshots without paid data feeds, API keys, or hidden vendor dependencies.

Last updated: 2026-05-11Last reviewed: 2026-05-11
Product boundary
Free data persistence is a trust boundary. Local snapshots can add historical context, but missing or stale snapshots must remain visible as unavailable states. HypeBasis should not invent history, imply guaranteed alert delivery, or hide a paid service behind a tool.

Direct answer

HypeBasis currently uses ignored local JSON files for optional snapshot history and audit trails. That keeps the site independent from paid feeds while allowing local or self-hosted collection. If a snapshot is missing, stale, malformed, or only partially parsed, the UI should say so rather than filling the gap with estimates.

Current free workflows

  • `npm run outcomes:collect` appends outcome-market records to an ignored local JSON history file.
  • `npm run validators:collect` appends validator network snapshots for local concentration and commission-change context.
  • `npm run ecosystem:collect` writes optional HyperEVM TVL/APY context from documented DeFiLlama free endpoints.
  • `npm run alerts:run` and `npm run alerts:deliver` evaluate local alert rules and write local outbox files without sending through a paid email API.

Persistence rules

  • `npm run verify` runs the free-data boundary audit before tests, lint, and the production build.
  • Production pages must render unavailable or partial states when a snapshot file or free store is missing.
  • A stored value must keep its source, fetched timestamp, stale threshold, and parser warning state.
  • Self-hosted storage can be added only when the free tier, schema, retention limits, and failure states are documented.
  • No local file should be treated as user consent, delivery proof, or a reliable live data feed.

Unavailable-state rules

  • Missing snapshot: show unavailable instead of synthesizing history from the current quote.
  • Old snapshot: show stale state and tell the reader a fresh local collection run is needed.
  • Partial snapshot: show the fields that parsed cleanly and keep unsupported fields unavailable.
  • Third-party context: label it as third-party context and keep primary protocol claims separate.

What can move to self-hosted storage later

A future free-tier store can hold the same snapshot records if it is documented as an operational choice rather than a data vendor. The schema should stay JSON-compatible, route rendering should preserve stale and partial states, and the page should still work when the store is empty or temporarily unavailable.

The safest first durable candidates are public market snapshots, public validator aggregates, and non-sensitive alert audit records. Subscriber identity, email delivery, or account-specific alert preferences need separate consent and privacy rules before they are persisted anywhere beyond a local development workflow.

What stays out of scope

  • Paid market-data feeds, paid email APIs, paid analytics databases, or key-gated services.
  • Private wallet monitoring, custodial account data, or hidden user tracking.
  • Yield, staking, validator, vault, or protocol recommendations based on snapshot history.
  • Backfilled history that was not actually collected from a documented source at the recorded time.

Related tools

Sources