Sources And Corrections

Direct answer

HypeBasis prefers official sources, records review dates, and reviews high-risk pages monthly. If a claim gets old or loses source support, the page should fix it, mark it unverified, or remove it.

Source priority

• Official protocol or venue docs.
• Public terms, risk disclosures, fee pages, and help pages.
• Regulators, exchanges, or established education sources for traditional products.
• Public API data, with old or fallback data labeled in the UI.
• Third-party technical docs only when official docs do not explain an endpoint clearly.

How corrections work

• Identify the affected claim, page, source, and risk level.
• Check the official or primary source again before rewriting the claim.
• If the claim cannot be checked, remove it or label it unverified.
• Update the copy, review date, source block, and any tests that protect the claim.
• Add a plan note when the change affects money, jurisdictions, or product meaning.

What gets removed

• A fee, referral, restriction, or protocol claim with no official or primary-source support.
• A jurisdiction statement that encourages signups, deposits, trading, or workarounds where access is restricted.
• A calculator or data explanation that hides major assumptions such as fees, spread, liquidity, funding, settlement, or stale data.
• A comparison claim that relies on old fee tables, old access rules, or unsupported marketing language.

Perp DEX comparisons

Perp DEX comparisons start with facts: fees, funding, open interest, volume, spread, depth, incentives, custody, and access rules. Any takeaway must show its limits.

Aster, Lighter, edgeX, Paradex, and Vertex pages stay cautious until current sources and metric definitions are checked. Missing competitor data should stay missing, not become a conclusion.

External market depth

HypeBasis can use free public Binance and Coinbase order books to give BTC, ETH, and SOL more market context. Hyperliquid remains the main product. External books must not become venue recommendations, routing instructions, execution promises, or restriction workarounds.

Cross-venue depth moves fast. Pages should use saved public data with source, fetch time, old-data labels, incomplete-data labels, and missing-data labels.

• Hyperliquid remains the primary venue context; external venues are labeled as reference venues only.
• Use free public or self-hosted snapshots only; do not add paid feeds, API-key-only providers, or authenticated user endpoints.
• Do not fetch external order books during every production page render; use local/self-hosted collectors or scheduled snapshots before UI integration.
• Show source, fetched timestamp, source timestamp when available, stale labels, partial labels, and missing-data labels.
• Never present cross-venue depth as a recommendation, routing instruction, execution guarantee, or restricted-jurisdiction workaround.

Hyperliquid API checks

Live market pages check Hyperliquid `/info` responses before using them. The first check covers `metaAndAssetCtxs`, broken payloads, missing markets, old metadata, and incomplete data.

Spot-token mapping stays separate until a page needs it. It should not become a spot ranking or yield page by accident.

Validator data gets the same checks. HypeBasis can read active count, jailed count, stake totals, and concentration from the free primary endpoint, but staking pages should show source and fetch time before leaning on the numbers.