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.
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. documented network tip |
| Status classification | Green / yellow / red by lag, latency, and errors |
| Public JSON API | | 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's shutdown and the ecosystem shift toward self-hosted monero-lws increases reliance on community LWS operators — but visibility into their health has not kept up.
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 | 2 operator-confirmed mainnet LWS endpoints |
| Dashboard | Overview matrix, /endpoints registry, /compare side-by-side view |
| API |
/api/endpoints, /api/summary, /api/reference, /api/status.json
|
| Probes | Privacy-safe POST /get_version only |
| Reference tip | xmrchain.net (LocalMonero 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 & timeline (6 weeks total)
Milestones (6 weeks)
Milestone 1 — Production v1 · 4 XMR · weeks 1–3
- 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 · 6 XMR · weeks 4–6
- 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)
| Item | XMR |
|---|---|
| M1 engineering + production deploy | 3 |
| M2 alerts, export, docs | 5 |
| Hosting & domain (12 months) | 2 |
| Total | 10 |
All work MIT licensed on GitHub.
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.