What this is

The XRP Ledger is the public blockchain this whole site reads from — a global network of independent computers that all agree on every transaction. "Healthy" means new ledgers (think of them as pages in the ledger book) are closing on time and validators agree on what they contain.

How we know

We ask one of the network's public servers for the same status data anyone can read. We watch how often new ledgers close (every ~3.5–4 seconds is normal) and whether validators — the computers that vote on each ledger's contents — are in agreement. If close times stretch out or the quorum drops, the status above changes.

What this is

A live catalogue of the 31,496 AMM pools we currently track on the XRP Ledger. AMMs are pools of two assets that let people swap one for the other without an order book — they handle a big chunk of XRPL token trading.

How we know

A background worker scans the ledger every few hours, finds new AMM pools as they're created, and ranks them by how much value they hold (TVL). The result is the catalogue that powers the /pools page. "Ready" means the catalogue has been built; "building" means it's still being scanned for the first time.

What this is

A real-time watcher that sees every transaction the moment it confirms on the XRP Ledger. It tags the big stuff — large XRP transfers (whale moves) and token trades — so this site can show live activity, fill its rankings, and build history.

How we know

A persistent websocket subscription to a public XRPL node streams every closed transaction as it happens. "Streaming" means the connection is live and processing.

Ledgers close every few seconds, but the live watcher only logs the events this site tracks — whale transfers, token trades, and AMM creations. Those tick on their own cadence (often a few minutes apart), so the "Last tracked event" timestamp can lag the ledger heartbeat without anything being wrong.

What this is

Workers run on a Mac in Charlie's office. Prod (Render) is a separate machine in the US — it has none of the Mac's files. The mirror is the bridge: every time the Mac finishes a ranking pass or captures a new event, it writes the result to a shared Neon Postgres so prod can read the same data.

How we know

Each successful mirror write also stamps a heartbeat row. The age of that row is the freshness signal: under 5h 0m and the bridge is working, over and prod is reading stale data until the next write lands.

What this is

A growing archive of everything the live watcher captures, written to a database the moment it happens. Without this, the site would forget yesterday's data on every restart — no charts, no rankings, no history.

How we know

Every event the watcher tags is written into Postgres in real time and mirrored to a local file as backup. The two counts above are the cumulative rows currently stored. The freshness signal is separate — we read the age of the most recent event row directly, so a write path that stalls while the live feed stays connected still downgrades this card.