Methodology

What this system can verify

• Validator set membership — from cosmos.staking.v1beta1.Query/Validators over a public application gRPC endpoint.
• Fibre registration — from the on-chain x/valaddr registry (celestia.valaddr.v1.Query/AllBondedFibreProviders). Only bonded validators appear there; when a validator leaves the active set its entry is removed.
• Transport reachability — DNS resolution, TCP connection, and a TLS 1.3 handshake to the registered host:port, each timed and classified.
• gRPC liveness — the standard health service with the service name fibre-liveness, which a fibre server marks SERVING as soon as the gRPC server answers.
• gRPC readiness — the same health service with the empty service name and celestia.fibre.v1.Fibre, SERVING only when the server's own dependency checks (app node, fibre module, signer, active set, registration, storage) all pass.
• Validator identity — the fibre TLS identity scheme (celestia-fibre-tls-v1): the server's self-signed certificate carries an extension (OID 1.3.6.1.4.1.66463.1.1) signed by the validator's consensus key. We verify the signature against the key from the staking registry, check the key binding, the signed validity window and the certificate's EKU. A bare TLS handshake never counts as verified identity.

What this system cannot verify

• Infrastructure details — disk separation, RAM/headroom, storage capacity, firewall rules, remote-signer mTLS, KMS latency, backups, incident response. These require operator evidence (category 3) and are UNKNOWN without a signed attestation. They can never be PASSed by observation alone.
• Shard availability with cryptographic proof — downloading a shard is possible (opt-in), but full RLC/commitment verification is not implemented, so proven availability stays UNKNOWN rather than guessed.
• Endorsement participation — no current-state gRPC query lists validator endorsements; deriving it needs transaction indexing.
• Registration height — the registry query returns only the host; the height exists solely in set_fibre_provider_info events. We display it as explicitly unavailable rather than fabricating it.

How the score works

Rules live in a machine-readable catalog with IDs, categories, weights, severities, thresholds, remediation and references. The observed readiness score is:

Σ weight(PASS) / Σ weight(PASS + FAIL) over category 1 and 2 rules, with WARNING counting half against.

• UNKNOWN and NOT_APPLICABLE never count as passing.
• On a reachable endpoint, an undeterminable health status still weighs on the score (critical unknown).
• Category 3 (operator evidence) is displayed but never scored — it cannot be observed publicly.
• A validator with no evaluable endpoint evidence gets no score, not 0%.

Liveness vs readiness

These are deliberately separate observations. A server can be alive (gRPC answering, serving shard downloads) while not ready (its app node is syncing, its signer is unreachable, its disk probe failed). Conversely a NOT_SERVING readiness with SERVING liveness is a precise diagnosis: the process is up but one of its dependencies is failing. We never derive one from the other.

Uptime and history

• Availability windows (24h / 7d / 30d) are computed from stored observations of this monitor, not extrapolated: a 30-day figure requires data spanning at least half the window, enough samples, and sufficient scan coverage.
• Monitor-side failures do not penalize validators. A scan that cannot complete discovery (RPC outage) is recorded as failed and produces no per-validator samples.
• Network-wide incidents do not penalize validators. If ≥80% of probeable endpoints fail transport simultaneously (with discovery healthy), the scan is flagged as an incident and its samples are marked inconclusive.
• Endpoints that do not implement the health service (older builds) are UNKNOWN for liveness — never failed — and may still serve downloads.

Probing behaviour and ethics

• Only registered, public endpoints are contacted — never private signing interfaces or internal gRPC ports, and no port scanning.
• Every dial goes through an SSRF policy: loopback, private, CGNAT, link-local (including cloud metadata), documentation and reserved ranges are refused; DNS is re-validated at dial time.
• Concurrency, timeouts, per-scan pause and response-size caps bound the traffic we generate. Each endpoint sees a handful of small gRPC health calls per scan.
• No blobs are uploaded, ever, without explicit opt-in (and upload probing is not implemented). Mainnet is never written to.
• Discovered hosts are treated as untrusted input: strict host:port validation, no redirects, bounded parsing.

Evidence labelling

Every observation is labelled by origin: verified (publicly re-computable), unknown (could not be determined — never shown as passing), operator-attested (signed submission; signature verified, identity binding declared not independently verified), or historical (past observation with its own timestamp). See the protocol research for upstream sources of every protocol detail.

Known limitations

• Measurements are taken from a single vantage point (the scanner's host). Latency is not a network-wide truth; reachability can differ from elsewhere on the internet.
• Fibre servers regenerate their TLS identity on restart, so an identity "version" change is normal across restarts.
• The health service reports the server's own view; a misconfigured server could claim readiness falsely. Identity verification guarantees who is speaking, not that their self-checks are correct.
• Scheduled GitHub Actions scans are best-effort and may be delayed or skipped during GitHub incidents — that is why durable monitoring should use the Docker deployment.