Check_d v4: Decentralized Endpoint Monitoring for Cosmos Hub

check_d v4: Decentralized Endpoint Monitoring for Cosmos Hub We have released check_d v4 , the latest version of Cumulo’s decentralized monitoring tool for public blockchain endpoints. check_d continuously tests validator-operated RPC and REST API endpoints from multiple independent geographic locations. The current monitoring network includes: • United States • Europe • Canada Instead of relying on ICMP pings or synthetic availability checks, check_d performs real protocol requests against each endpoint. This makes it possible to measure actual response latency, block height, availability and historical reliability from each region. For Cosmos Hub mainnet, the live results can already be explored through the following dashboards: • RPC Scan: Cosmos services by Cumulo • REST API Scan: Cosmos services by Cumulo image 2503×1276 239 KB What check_d monitors For every public endpoint, the system collects: • Real RPC or REST API response latency • Latest reported block height • Endpoint availability • Regional performance differences • Historical reliability over approximately seven days The resulting dashboards make it…

Excerpt (1195 of 4487 characters). Read the whole post on the forum ↗

This looks useful, particularly the regional reliability data and real protocol checks.

For client or wallet-side endpoint selection, does the JSON data include—or could it eventually include—details such as rate limits, CORS support, TLS/certificate status, pruning or archival availability, and the time of the latest successful check?

Also, how frequently are the results refreshed, and is there any recommended way to avoid switching endpoints because of short-lived latency changes?

Thanks, this kind of feedback is genuinely useful and helps us prioritize what to build next. Rate limits, CORS support, TLS certificate status : not supported yet, but we’re considering all three for upcoming versions. On TLS specifically, we can already indicate it partially and indirectly: when a request fails because of a certificate problem (hostname mismatch, expired cert, etc.), the raw error shows up in the `detail` field, so the information exists but isn’t a clean structured field yet. Pruning/archival availability : since we run our own curated list of validator resources, we can add this as a proper field there. We’re still expanding that list and plan to review it periodically. That said, it’s worth noting that the large majority of current Cosmos endpoints in the list are pruned already. Time of the latest successful check : not exposed per endpoint today. We track a `reliability` percentage smoothed over roughly 7 days of history, but there’s no explicit `lastCheckedAt` or `lastSuccessAt` timestamp per entry. This would be a simple addition, since every check cycle is already timestamped internally. Refresh frequency : regional checkers run every 5 minutes,…

Excerpt (1199 of 2301 characters). Read the whole post on the forum ↗

Thanks for the detailed explanation. The reliability-first approach, with latency used as a tiebreaker and client-side hysteresis, makes sense for wallet-side endpoint selection.

Structured lastSuccessAt data and a smoothed latency field would be particularly useful for distinguishing a genuinely better endpoint from a temporary performance change.

I’ll share these considerations with the Gem Wallet team as part of our ongoing discussions around wallet and endpoint reliability. Looking forward to seeing how the next version develops.

@Anzus_GemWallet hey! Following up on this, both of the fields you asked about have shipped: • `lastSuccessAt` is now persisted per endpoint alongside a `checkedAt` timestamp on every cycle, so you can see both “when was this last polled” and “when did it last actually succeed” as separate values, useful for spotting an endpoint that’s still responding but degrading. • `smoothedAverageLatency` is an EMA over the raw per-cycle latency (alpha 0.3), available both as a global figure and per region (`smoothedLatencyByRegion`). It sits next to the raw `averageLatency` so you can use the smoothed value for selection logic without a single noisy cycle causing a switch, which is exactly the temporary-vs-genuine distinction you flagged. On top of that we added a Smart Endpoint Selector: a small ranking API built directly on your reliability-first, latency-as-tiebreaker approach. It filters to currently healthy endpoints, sorts by reliability, and breaks ties with the smoothed latency, so a wallet can just call it instead of implementing that selection logic client-side: ``` GET https://aggregate-rpcs.cumulo.com.es/best-rpc?chain=Cosmos+mainnet GET…

Excerpt (1166 of 1439 characters). Read the whole post on the forum ↗

Great to see these updates shipped, and thanks for following up. Separating the last check from the last successful response should make endpoint issues easier to spot, while the smoothed latency should help avoid unnecessary switching. The Smart Endpoint Selector also sounds useful. I’ll share the update with the Gem Wallet team.