Consensus ID

Overview

Consensus systems use identifiers to prevent messages from being interpreted in the wrong context. A consensus ID may identify a chain, validator, block proposal, height and round, committee instance, or domain-separated protocol session. The exact field is protocol-specific and should not be confused with a wallet address or EVM chain ID. Correct domain binding prevents votes, signatures, or proofs from being replayed across networks, forks, epochs, or separate consensus instances.

Implementers must construct and validate IDs exactly as specified, including encoding, version, and domain separation. Logs and monitoring should retain them for incident analysis. Accepting a valid signature without checking its consensus context can authorize an unrelated decision. Changes to Consensus ID should pass automated tests against known network identifiers, contracts, encodings, and expected outputs. Rollout needs environment separation, change approval, rollback, and historical traceability so past transactions can be interpreted using the configuration active at that time. This evidence helps distinguish incorrect configuration from an upstream node, protocol, or business-logic failure. Operational logs for Consensus ID should record the version, caller, resolved value, and downstream action without exposing secrets.

Consensus ID should be maintained through one versioned source of truth that defines identifiers, schemas, allowed values, ownership, and deployment scope. Human-readable labels are not sufficient when different chains, environments, or providers reuse similar names.

Unknown versions, ambiguous aliases, unsupported fields, duplicate records, and stale configurations should fail into review rather than being silently mapped to a convenient default. Inputs to Consensus ID need explicit validation and deterministic failure behavior.