[DRC] OHLP — Oracle Health & Listing Pre‑flight + Alert

Grants
1

TL;DR
dYdX’s Instant Market Listings let any user launch a launchable market by locking 10,000 USDC into MegaVault for 2,592,000 blocks (≈30 days, timing depends on block time). This accelerates growth but creates a practical risk: a market can go live while its oracle is stale, deviating, or updating irregularly. OHLP is a neutral pre‑flight + alerting layer that runs three objective checks which are staleness, deviation, cadence; and publishes a shareable green / yellow / red badge + short report that proposers paste into their threads (and validators/delegates can rely on). It complements, not replaces, existing risk dashboards.

Motivation (the problem)

  • Permissionless speed needs guardrails. With Instant Listings, a one‑minute flow plus a 10,000 USDC lock can take a market from idea to live trading. If oracle feeds are stale/laggy at launch, funding, margin triggers, and liquidations can misfire in the early hours. A neutral, public go/no‑go signal reduces bad launches and governance churn.

  • Oracle stack has evolved. dYdX integrated Skip Protocol’s Slinky Sidecar and Raydium pricing: per‑block updates with lower latency by moving oracle updates out of consensus, plus broader Solana‑asset coverage. Launch velocity increases the need for feed health at listing time.

  • Process context. Users can list “launchable” markets instantly via MegaVault, while a separate Market Listing Widget path creates a governance proposal with a 2,000 DYDX refundable deposit. OHLP sits before either path goes live and standardizes due‑diligence on oracle readiness.

    Scope (what OHLP will and won’t do)

    Will do (MVP):

    • Staleness: time since last oracle price update vs. expected block‑time cadence (rolling baseline).

    • Deviation: oracle price vs. a robust reference (e.g., consensus/median or a secondary venue where licensing permits; references are optional for MVP).

    • Cadence stability: regularity of updates (variance/interval), spike/outage flags.

    • Publish a pre‑flight page per market (e.g., /preflight/SOL‑USD) with a green / yellow / red verdict and one‑paragraph rationale.

    • Provide a Markdown snippet proposers paste into Instant Listing or forum threads.

    • Send alerts (Telegram/Discord/Webhook) on threshold breaches.

    • Expose a public, read‑only API (/oracle/health/:market, /preflight/:market, /status).

    Will not do (to avoid overlap):

    • No parameter recommendations, VaR simulations, or liquidity‑tier tuning (those live in the Chaos Labs risk/rec portals).

    • No governance automation; read‑only posture; no edits to Market Map.

      Design

      Data sources (read‑only):

      • Oracle/chain timing & price series from the dYdX Chain’s oracle surfaces (e.g., Slinky sidecar) and node/Indexer signals for block height/time. External references are optional adapters (only where licensing permits).

      Health engine:

      • Rolling windows compute staleness_ms, deviation_pct, and cadence variance; deterministic thresholds map to a color verdict. Thresholds are versioned and documented (to avoid moving targets).

      Badge & API:

      • Deterministic URLs per market; signed reports (hash of inputs + threshold version) so results are reproducible and mirrorable.

      Ops & licensing:

      • Apache‑2.0; Docker + Helm; one‑click deploy; validators/ops can host mirrors (no single point of failure).

        image
        image1536×1024 162 KB

How it fits existing workflows

  • Instant Listings: users can list any launchable market by depositing 10,000 USDC to MegaVault for 2,592,000 blocks (≈30 days). OHLP is a pre‑flight step: run checks and paste the badge link before launch.

  • Market Listing Widget (governance path): proposal creation uses a 2,000 DYDX refundable deposit; OHLP can attach to the forum post so validators/delegates see a standardized signal.

  • Market Map: “launchable” eligibility is curated on‑chain by a community‑elected operator (currently Skip as Market Map Updater); OHLP doesn’t change parameters—it only reports oracle health.

# Milestone Payment Deliverables Acceptance (must all pass)
M1 Spec & Scaffold (wk 1–2) $7,000 Architecture spec; metric formulas; thresholds v1.0.0; public repo (Apache-2.0); Docker/Helm skeleton; CI Repo public + LICENSE; thresholds table committed; docker compose up returns /status; CI green.
M2 Ingest & Health Engine (wk 2–5) $18,000 Slinky + node/Indexer ingestors; health engine (staleness/deviation/cadence); CLI; tests; sample data (2 markets) ohlp run on sample data is deterministic (≤1% variance); ≥80% health-engine test coverage; docs for windows/cadence derivation; versioned JSON output.
M3 API, Dashboard & Alerts (wk 5–7) $15,000 API (/oracle/health/:m, /preflight/:m, /status) + OpenAPI; dashboard + badge + Markdown embed; alerts (TG/Discord/Webhook) All endpoints live; embed renders on test thread; simulated anomaly triggers all 3 alert channels; p95 API latency <300ms @100rps100rps**/60s**; no secrets; headers/CORS documented.
M4 Ops, Mirrors & Rollout (wk 7–8) $7,000 Helm chart; images; ops run-book; Prometheus/Grafana example; 10-min walkthrough video; forum DRC pack; docs PR Two clean installs (e.g., AWS+GCP) in ≤30 min from docs; mirrors show green /status and identical verdicts on sample markets; DRC + docs PR ready; handoff checklist delivered.
Contingency $3,000 Reserved for data quirks/perf tweaks Used only with a brief changelog tied to an accepted issue.

Deliverables (Definition of Done)

  1. Checks library (staleness/deviation/cadence) + unit tests.

  2. Public dashboard (market directory + detail pages) and badge renderer.

  3. Public API (3 endpoints) + OpenAPI spec.

  4. Alerts (TG/Discord/Webhook) + runbooks.

  5. Docs: quickstart, “how to cite,” self‑hosting guide, read‑only threat model.

  6. Helm & Docker for one‑click deploy; mirror instructions.

    Budget:

    • Backend ingest & health checks — $18k

    • Frontend & badge + API — $15k

    • Alerts & integrations — $7k

    • DevOps (Docker/Helm), mirrors, docs — $7k

    • Contingency — $3k

Timeline (8 weeks)

  • Weeks 1–2: final spec, schemas, threshold table; Docker/Helm scaffolding; 2 test markets wired.

  • Weeks 2–5: ingestors + health checks + tests.

  • Weeks 5–7: dashboard + badge; API; TG/Discord/Webhook alerts; docs.

  • Weeks 7–8: mirror run‑book; forum rollout; docs PR to community site

    Success criteria (first 60–90 days)

    • ≥10 listing threads include an OHLP badge link.

    • ≥200 alert subscribers (TG/Discord/Webhooks).

    • p95 ≤ 5 min from anomaly → alert delivery acknowledged by ops.

    • ≥3 validator/ops mirrors online.

Dapps over Apps is a builder collective advancing Web3 through developer tooling and education. We ship practical tools that improve developer experience and run initiatives that onboard new builders into blockchain ecosystems. Our work spans testing, SDKs, IDE extensions, identity tooling, and data utilities; with open-source repos and live demos.

Track record (evidence links)

Relevance to OHLP: we’ve shipped observability & benchmarking (RetrievalTester), chain/VM integration work (Anvil/Hardhat patches), and developer UX (VS Code extension) which are the exact mix needed for OHLP’s ingestors, health checks, API, and dashboard.

Core team

Risks & mitigations

  • Reference‑data licensing: MVP works without external CEX feeds; uses Slinky + chain/Indexer first; optional adapters only where permitted, with clear attribution.

  • False positives / threshold tuning: conservative defaults; versioned thresholds; include context charts; mirrors can tune thresholds publicly (documented).

  • Perceived overlap: scope‑locked to oracle readiness only; link out to Chaos Labs for macro risk/parameter context.

Call for community feedback

  1. Thresholds: Are the initial defaults for staleness/deviation/cadence appropriate across liquidity tiers?

  2. Adoption norm: Should we encourage an OHLP link in Instant Listing threads as a soft expectation?

  3. Mirrors: Which validator/ops teams want to run first‑wave mirrors?

  4. Placement: Where should the public dashboard live in community docs for maximum visibility?

2

Hi community, we would like to call your attention to out idea. How do we move forward from here. We look forward to receiving the input of the community on this. Thank you.