Monero LWS Observatory — Public LWS Health Monitoring
Summary
Monero LWS Observatory is a neutral, public health dashboard and JSON API for Monero Light Wallet Server (LWS) endpoints. It answers a practical question for wallet users, developers, and operators:
Is my wallet's LWS broken?
The service polls curated LWS hosts via public POST /get_version (returns blockchain_height on monero-lws). No view keys. No wallet traffic. No port scanning.
In one line: monero.fail, but for the LWS layer — monero.fail monitors monerod remote nodes; nothing yet monitors the LWS servers that light wallets actually sync through.
Live preview: https://monero-lws-observatory.vercel.app
Source: https://github.com/panagot/Monero-LWS-Observatory
Roadmap / milestones: https://monero-lws-observatory.vercel.app/roadmap
What is this proposal about?
Light wallets (MyMonero-compatible clients, Skylight, Monero Merchant integrations, and others) sync through LWS backends, not directly through monerod. When sync fails, users and developers often cannot tell whether the problem is:
- the LWS server lagging or offline,
- the network reference tip,
- or the wallet itself.
Public infrastructure lists such as monero.fail cover monerod remote nodes — not LWS servers. There is still no maintained public list or neutral health dashboard for LWS endpoints (Stack Exchange #14557).
Monero LWS Observatory fills that gap with:
| Capability | Description |
|---|---|
| Curated registry | Version-controlled list of operator-approved LWS URLs |
| Privacy-safe probes |
POST /get_version only |
| Reference comparison | Lag vs. a multi-source network tip (highest height across independent explorers + a public monerod daemon), independently reproducible with a single curl -X POST …/get_version
|
| Status classification | Green / yellow / red by lag, latency, and errors |
| Public JSON API |
/api/endpoints, /api/summary, /api/reference, /api/status.json
|
Why is this important for Monero?
| Audience | Benefit |
|---|---|
| Wallet developers | Objective data when choosing or debugging default LWS servers |
| LWS operators | Early warning when their server falls behind the chain tip |
| Merchants / integrators | Shared signal when debugging sync failures (Skylight, Monero Merchant, self-hosted monero-lws) |
| Light wallet users | Indirect benefit — fewer silent sync failures as devs and operators act on shared data |
Why now: MyMonero shuts down January 6, 2026, and new wallets are shipping without a default LWS — Skylight (MAGIC Grants) requires users to run or choose their own, and Monero Merchant added LWS support in Dec 2025. The ecosystem is deliberately moving toward many community-run LWS operators, yet there is still no neutral health signal for them (Stack Exchange #14557 is an open, unanswered request for exactly this list).
What exists today (pre-funding)
A working open-source demo is already live — it proves the monitoring model and API before any CCS funds are spent:
Live demo: https://monero-lws-observatory.vercel.app
Source: https://github.com/panagot/Monero-LWS-Observatory
Roadmap: https://monero-lws-observatory.vercel.app/roadmap
| Area | Shipped today |
|---|---|
| Fleet monitoring | 1 operator-confirmed third-party LWS endpoint (Monero Web) + an observatory reference canary; M1 expands to 5–8 verified operator-opt-in endpoints |
| Dashboard | Overview matrix, /endpoints registry, /compare side-by-side view, per-endpoint detail pages |
| API |
/api/endpoints, /api/summary, /api/reference, /api/status.json
|
| Probes | Privacy-safe POST /get_version only |
| Reference tip | Highest height across independent live sources — xmrchain.net, a public monerod daemon, and moneroblocks.info — with fleet-consensus fallback |
| Registry | Operator opt-in policy + GitHub submission template — no port scanning |
| Status rules | Green / yellow / red by lag, latency, and probe errors |
If this proposal is funded, the demo becomes a dedicated public website on always-on VPS hosting with a custom domain — 24/7 polling, persistent history, an expanded operator registry (5–8 endpoints), endpoint detail pages with charts, and operator alerting (M2). The current Vercel URL is a pre-funding proof of concept only; production delivery is what M1/M2 pay for.
Milestones (4 weeks total)
Milestone 1 — Production v1 · 5 XMR · weeks 1–2
- Production poller + API on VPS with custom domain
- Durable history storage (Postgres or equivalent)
- 5–8 verified LWS endpoints (operator opt-in)
- Endpoint detail pages, 7-day charts, fleet comparison
- Reference height methodology documented and validated weekly
- 12 months hosting + maintenance begins
Acceptance: A wallet developer or LWS operator confirms ≥3 endpoints match manual curl -X POST …/get_version within ±1 block.
Milestone 2 — Operator tooling · 5 XMR · weeks 3–4
- Webhook alerts (Discord / HTTP) for lag, downtime, height drops
- Public machine-readable status JSON feed
- 30-day history retention, JSON/CSV export
- Self-host documentation
- GitHub-based endpoint submission checklist
- Tor /
.onionLWS probing where operators provide URLs
Acceptance: An endpoint operator configures alerts and confirms delivery within one poll cycle.
Budget (10 XMR total)
| Milestone | Scope | XMR |
|---|---|---|
| M1 — Production v1 | VPS poller + API, custom domain, durable history, 5–8 verified endpoints, endpoint detail pages + 7-day charts, documented multi-source reference methodology, 12-month hosting begins | 5 |
| M2 — Operator tooling | Webhook alerts, machine-readable status feed, 30-day history + JSON/CSV export, self-host docs, Tor/.onion probing |
5 |
| Total | 10 |
Hosting and maintenance for the first 12 months are included in M1. All work MIT-licensed on GitHub.
Sustainability & maintenance
- No single point of failure by design. The registry is a version-controlled JSON file and the whole stack is MIT-licensed, so if I step away anyone can redeploy the exact service from the repo in minutes. The project does not depend on me personally staying online.
- Hosting is milestone-gated, not prepaid indefinitely. The 12-month hosting in M1 covers a concrete, deliverable period; there is no open-ended recurring ask.
- Low, transparent running costs. A single small VPS + domain; no databases-as-a-service lock-in required.
- Portable data. History and the status feed are exportable (JSON/CSV, M2), so the data outlives any single deployment.
Updates
Milestone completion reports posted as comments on this Merge Request. Progress can be shared at community / dev meetings on request.
Expiration
October 7, 2026 — if not fully funded or completed by this date, remaining escrowed funds released per CCS rules.