Cardano Seeks Standard for Block Producer Software
Cardano’s CPS-0036 addresses the absence of a common method for stake pool operators to declare which node implementation produced a block. The proposed signal would remain voluntary and would not affect block validity.
By SongMarketCap
A Cardano Problem Statement is seeking a shared method for identifying the software used to produce individual blocks. The CPS-0036 discussion opened on September 2 and received a Confirmed label on September 16, but the proposal remains open and does not establish a technical standard.
Its purpose is to define the problem before a separate Cardano Improvement Proposal specifies the signaling format, software registry and implementation rules.
Cardano Expands Beyond a Single Node Implementation
Cardano has historically relied on the Haskell-based cardano-node, while additional implementations are now being developed under the same consensus rules. CPS-0036 names Amaru and Dingo, and the proposal discussion also references Gerolamo.
In this context, a client is the node software that validates the Cardano protocol and can participate in block production. It is separate from wallets and other applications used to interact with the network.
Independent implementations can improve resilience because a defect affecting one codebase may not exist in another. That benefit depends on adoption. If one client continues producing most blocks, the network remains operationally dependent on that implementation even when alternatives are available.
Cardano currently has no standardized field that attributes each block to the software that created it. Researchers, explorers and monitoring platforms must estimate client distribution indirectly, producing datasets that may be incomplete or difficult to compare.
Activity on the network has made the issue more immediate. Reviewer yHSJ said Dingo and Gerolamo have already produced blocks using the protocol minor version field as a software identifier, while Amaru plans to follow the same approach.
CPS-0036 Outlines Voluntary Software Signaling
CPS-0036 calls for a compact, voluntary and consensus-neutral mechanism. Blocks without a software identifier would remain valid, and each stake pool operator would decide whether to publish the information.
The discussion describes two existing approaches. One uses four bytes from the protocol minor version field in the block header. The other uses a marker transaction of approximately 60 bytes. Without a common specification, implementations could adopt different formats and force infrastructure providers to maintain separate decoding rules.
The proposal also calls for an openly governed registry that assigns a recognizable identifier to each implementation. Explorers, researchers and dashboards could then interpret the signal consistently across the network.
Client identity is the first proposed use case. The mechanism could later support declarations about feature availability or software readiness before protocol upgrades.
Several design questions remain unresolved. A self-declared identifier can be spoofed, while cryptographically binding it to KES or VRF credentials would add complexity. Publishing detailed software versions could also expose operators running vulnerable releases. Any specification would need to remain compatible with Leios and its evolving block structure.
Client Data Could Strengthen Cardano Network Monitoring
A standard identifier would allow Cardano to measure declared client diversity directly from produced blocks. Network operators and researchers could calculate the share associated with each implementation, identify excessive reliance on one codebase and track whether alternative clients are moving into active infrastructure.
The data could also support protocol upgrades. If the standard later includes feature readiness, the ecosystem could obtain a network-level view before a hard fork or major software release. Testing and coordination would remain separate processes, while the on-chain signal would provide a common operational dataset.
The discussion indicates that a practical convention may already be forming around the protocol minor version field. CIP editor Robert Phair said a solution-focused CIP based on current practice could provide a more direct path than documenting the problem alone.
Software signaling cannot create client diversity or prevent failures, but it can make Cardano’s infrastructure easier to measure. If adopted, the standard would allow explorers and monitoring tools to replace fragmented estimates with consistent block-level data on which declared client is producing the network’s blocks.