How HypeBasis Stores Free Data

Direct answer

HypeBasis uses saved free data for history and checks. If the data is missing, old, broken, or incomplete, the page should say so instead of guessing.

Current free workflows

• Outcome-market history is shown only when saved history exists.
• Validator history can show concentration and commission changes over time.
• HyperEVM pages may show free DeFiLlama context, but protocol claims stay separate.
• HyperLend lending data can use the HyperLend protocol API only when saved market and rate records parse cleanly.
• BTC, ETH, and SOL depth can use free public books from Hyperliquid, Binance, and Coinbase.
• Alert rules can be checked without a paid email API, but the site must not promise delivery.
• Free durable storage can hold slow-changing public data when limits and failure cases are clear.
• Outcome history and reference depth can refresh on a slow schedule when free storage is available.
• Fresh saved data is reused; missing or old data stays visible instead of being guessed.

Persistence rules

• Free-data verification runs before tests, lint, and the production build.
• Pages must show clear labels when saved data is missing or incomplete.
• Saved data must include source, fetch time, stale limit, and parser warnings.
• Self-hosted storage needs documented free limits, retention, and failure states.
• Saved files should not be treated as user consent, delivery proof, or a reliable live data feed.

Optional durable storage

Durable storage can help keep slow public data available in production. It is still optional. If it is empty, broken, stale, or over a free limit, pages must show saved data or a missing-data label.

• Use durable storage only for slow public data, not private user records.
• If a write fails or a free limit is hit, show old or missing-data copy.
• Keep the same record shape across saved and durable stores.
• Do not store subscriber identity, wallet-specific alert settings, consent records, or delivery proof here.

Outcome history

Outcome history stores public market data only. It can improve probability-change labels without touching user data. If the history is missing or unreadable, outcome pages keep the missing-data label.

• Refresh slowly enough to stay within documented free limits.
• Data scope: public outcome-market history only. No user identity, wallet address, alert setting, consent record, or delivery proof.
• Outcome pages read saved history only when the data is valid.
• Status checks must report missing, available, old, or broken history without hiding failures.
• Activation rule: keep saved-data or missing-data labels when durable storage is absent, empty, stale, malformed, or temporarily unavailable.

Reference depth

Reference depth stores public BTC, ETH, and SOL order-book data from Hyperliquid, Binance, and Coinbase. Pages use it only when it is fresh enough and show missing-data labels when it is not.

• Refresh slowly enough to stay within documented free limits.
• Data scope: public BTC, ETH, and SOL order-book depth from Hyperliquid, Binance, and Coinbase only.
• Reference-depth pages use fresh saved data first, then show clear missing-data labels when data is unavailable.
• Status checks must report missing, malformed, old, incomplete, or available data.
• Collection must preserve source, fetch time, stale limit, and venue status.

Missing-data rules

• Missing data: say it is missing instead of inventing history from the current quote.
• Old data: label it old and avoid strong claims.
• Incomplete data: show only the fields that parsed cleanly.
• Third-party data: label it clearly and keep protocol claims separate.

What can move to durable storage later

A future free store can hold the same public records. The page must still work when that store is empty, old, incomplete, or offline.

The safest first candidates are public market data, public validator totals, and non-sensitive alert review records. Subscriber identity, email delivery, and account-specific alert settings need separate privacy and consent rules.

What stays out of scope

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