Runtime readiness

Read runtime state in context.

Capability labels describe software. Readiness describes one running deployment. Neither label overrides gateway policy or proves economic finality.

Live posture Method-gated Role-specific No release inference

Do not cache readiness as a permanent fact. Re-evaluate it when the operation matters.

Useful public signals

Signal Use Boundary
talero_runtimeReadiness Current node role and local readiness Not a network-wide certification
talero_txCapabilities Effective transaction policy Check fields such as whether PQ is required and whether classic signatures remain allowed
talero_getPqNodeStatus Aggregate PQ posture A degraded or mixed state must not be advertised as full PQ protection
talero_finalizedHead Published finality state and semantic class bootstrap_lag is not payout-grade BFT finality
talero_getConsensusConfig Scheduled consensus activations Scheduled does not mean currently active

Interpretation rules

  • Implemented does not mean publicly exposed.
  • Enabled on one node does not mean active network-wide.
  • Scheduled at a height does not mean the chain has reached that height.
  • Advisory evidence does not decide consensus or settlement.
  • Experimental functionality must not be presented as a production guarantee.

Wallet diagnostics

The Wallet UI consumes authenticated runtime diagnostics for the signed-in user. Its detailed capability and diagnostic-pack endpoints are not anonymous discovery APIs. Public documentation therefore describes user-visible behavior and stable integration boundaries rather than reproducing internal flags, environment names or back-office controls.