Quorum, heartbeat of each Super Validator, and the response of their endpoints.
SV heartbeats and reporting gaps, based on on-chain status reports.
SVs reporting now
13 of 13(quorum 9)
Time with ≥ 9 SVs reporting
100%of the last 30 days
Periods below the quorum
Nonein the last 30 days
Lowest 10 of 13 reporting. DSO activity 100%.
None in the last 30 days: at least 10 of 13 SVs were reporting at every moment (the quorum is 9).
| Hosting | |||||
|---|---|---|---|---|---|
| Up#118,6592m 51s ago | 99.993% | 3m | 0 | ||
| Up#118,6593m 12s ago | 99.893% | 46m | 3 | ||
| Up#118,6593m 26s ago | 99.791% | 1h 30m | 3 | ||
| Up#118,6593m 32s ago | 99.774% | 1h 38m | 1 | ||
| Up#118,6591m 44s ago | 99.743% | 1h 51m | 1 | ||
| Up#118,6592m 44s ago | 99.919% | 35m | 1 | ||
| Up#118,6592m 17s ago | 99.978% | 9m | 0 | ||
| Up#118,6592m 52s ago | 99.928% | 31m | 1 | ||
| Up#118,6593m 36s ago | 99.858% | 1h 1m | 6 | ||
| Up#118,6593m 36s ago | 99.885% | 50m | 2 | ||
| Up#118,6601m 39s ago | 99.817% | 1h 19m | 3 | ||
| Up#118,6601m 37s ago | 99.671% | 2h 22m | 6 | ||
| Up#118,6601m 27s ago | 99.635% | 2h 38m | 6 |
| Started, UTC | Super validator | Component | Duration | State |
|---|---|---|---|---|
| Oct 20, 17:27 | Participant | 7m 34s | Resolved | |
| Oct 20, 16:43 | Participant | 16m | Resolved | |
| Oct 20, 16:33 | Participant | 26m | Resolved | |
| Oct 20, 13:08 | Participant | 7m 30s | Resolved | |
| Oct 20, 07:25 | Participant | 19m | Resolved | |
| Oct 20, 06:22 | Participant | 17m | Resolved | |
| Oct 19, 14:52 | Participant | 1h 31m | Resolved | |
| Oct 19, 14:50 | Participant | 1h 47m | Resolved | |
| Oct 19, 11:05 | Participant | 10m | Resolved | |
| Oct 19, 03:20 | Participant | 5m 15s | Resolved |
1. Ledger
Each SV writes a status report about every 140 s. It is accepted only after 9 of 13 SVs confirm it.
2. Our indexer
Reads every report since June 2024, and the DSO’s member list.
3. Each SV
Up while its last accepted report is under 5 minutes old.
4. The network
Counted: time with at least 9 of 13 SVs reporting. Fewer is not proof of an outage.
Example: 5 SVs, quorum 4
Each report keeps its SV counted for 5 min. SV C and SV D go quiet; from minute 29 to 38 only three report, so that stretch is listed as a period below 4, with C and D as not reporting.
Heartbeat of an SV
Threshold
Time with ≥ 9 SVs reporting
Every accepted report proves the DSO confirmed it. Fewer reporting SVs does not prove the network stopped: an SV’s app can stop while its participant still confirms. The 5 minutes is our monitoring rule, not a Canton definition.
Probes do not count. A server of ours times each SV’s endpoints every 30 s; a failure there can be our route, so it is shown as diagnostics only.
GET/api/sv-health/raw
kindstringrequired
Which data: gaps, failures or incidents
fromdate
First UTC day; default 7 days before to
todate
Last UTC day; default today; at most 31 days
svstring
One SV by name; default every SV
sourcestring
For incidents: ledger or probes; default both
formatstring
json (default), csv, tsv or ndjson
curl '/api/sv-health/raw?kind=gaps&from=2026-09-23&to=2026-10-23'
{ "network": "mainnet", "kind": "gaps", "from": "2026-09-23T00:00:00.000Z", "to": "2026-10-23T00:00:00.000Z", "truncated": false, "next": null, "rows": [ { "sv": "Digital-Asset-1", "last_report_at": "2026-10-20T08:01:12.000Z", "started_at": "2026-10-20T08:06:12.000Z", "ended_at": "2026-10-20T08:09:40.000Z", "next_report_at": "2026-10-20T08:09:40.000Z", "seconds": 208 }, "…" ] }
| sv | string | SV name |
| last_report_at | date-time | Its last accepted report before the gap |
| started_at | date-time | 5 minutes after that report |
| ended_at | date-time | null | Its next accepted report; null while the gap lasts |
| next_report_at | date-time | null | The same as ended_at |
| seconds | integer | Length of the gap |