StakeAPI.com
Architecture guide
Validator API and node operator reference for monitoring, signer safety, slashing protection, alerts, incidents, and automation.

Validator API operations

Build validator and node operator APIs around expected duties, observed results, telemetry freshness, signer safety, alerts, incidents, and evidence-based reconciliation.

Duty evidence

Join expected duties to observed work with protocol time, source, and revision history.

Monitoring model

Signer safety

Expose signer and slashing-database health without moving raw validator keys into the web tier.

Signing model

Incident workflow

Group symptoms into actionable incidents with ownership, evidence, runbooks, and resolution.

Incident model

Monitor expected work, observed work, and telemetry quality

Validator performance cannot be measured from observed successes alone. The API needs an expectation set, an observation set, and a coverage statement. It also needs to reveal whether collectors, RPC providers, queues, or databases are stale.

Layered health document

  • Host and process health
  • Execution and consensus client health
  • Peer count, synchronization, and head alignment
  • Signer and slashing-protection availability
  • Expected and observed duty outcomes
  • Collector freshness and sample completeness

Return summary severity with the observations that caused it. “Unknown” is a legitimate state when the monitoring system cannot establish current health.

Keep keys in a dedicated trust domain

The validator API coordinates duties and exposes health. A remote signer, hardware-backed service, or governed custody layer performs signing under a shared slashing-safety policy.

  • Public validator identifiers only in general APIs
  • Transactional slashing-history checks
  • Fail closed when safety state is unavailable
  • Controlled migration and no overlapping signers
  • Recovery exercises in an isolated environment
Slashing safety blueprint

Signer status example

ready: safety database consistent and signer enabled

disabled: administratively stopped

quarantined: migration or recovery checks pending

unsafe_unknown: safety state cannot be proven; signing blocked

Operational response

Alerts should imply an action

Group related validator symptoms, name the affected layer, preserve data freshness, and show the next diagnostic step. A deployment or upstream provider incident should not page once per validator.

Incident fieldWhat it communicates
Severity and stateProvisional, active, acknowledged, monitoring, or resolved.
ScopeValidators, hosts, clients, regions, providers, or tenants affected.
EvidenceDuty misses, head lag, process state, freshness, and correlated changes.
Owner and runbookWho responds and the next validated diagnostic procedure.
TimelineFirst symptom, detection, actions, recovery, and later corrections.