Consensus Capability

Overview

Consensus capability describes which agreement functions a participant or software component can perform. A full validator may propose and vote, a light client may verify finalized headers, and an execution-only service may validate state transitions without joining consensus communication. Capabilities depend on software version, enabled modules, keys, stake or membership, synchronization state, and protocol fork. An advertised feature does not prove that the node is currently eligible, healthy, or connected to the canonical network. Infrastructure teams should inventory capabilities explicitly and restrict privileged duties to hardened systems. Applications should confirm that an endpoint can provide the required finality or proof data, rather than assuming every RPC node offers equivalent consensus assurance.

An accepted request or message is not necessarily proof that the intended state transition or settlement completed. Applications relying on Consensus Capability should retain the inputs, outputs, network, version, responsible component, and evidence of success or failure. Consensus Capability should be tied to a precise scope such as message format, state transition, participant role, contract interface, or operational policy. Similar labels can describe consensus-critical rules, local node policy, application conventions, or business procedures with very different effects.

A written rule has no operational effect unless the active components enforce it consistently. Implementations of Consensus Capability need an exact specification and version, deterministic validation, defined errors, and compatibility tests across independent software. Changes to Consensus Capability require clear activation and upgrade authority. Consensus-affecting changes may require coordinated deployment, while local-policy changes can alter propagation or service behavior without changing ledger validity.