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.
Integration capability guide
View the public capability guide