Cardano Proposes Block Producer Software Registry

Josh Marchand has proposed a shared registry that would let Cardano explorers track which node clients produce blocks. Submitted on September 24, CIP-0203 builds on a signaling method already used by Dingo and Gerolamo. The proposal remains under review.

Software Identifiers in Cardano Blocks

Each participating node client would receive an identifier linked to its name, maintainers and public repository. Block producers would record that identifier in the block header, where explorers could match it to the registered software.

The proposal uses the existing minor protocol version field, which does not determine block validity. This allows identification without changing consensus rules or requiring a hard fork. Additional space would accommodate information such as software versions, using formats documented by the respective development teams.

Retired identifiers would remain in the registry and would not be reassigned within the same scheme, preserving the meaning of historical blocks.

Measuring Cardano Client Diversity

Node clients are the software implementations that allow computers to validate network data and produce blocks. As independently developed clients enter use, explorers need a consistent way to measure their contribution to block production.

The earlier CPS-0036 problem statement identified fragmented signaling conventions as an obstacle to that measurement. Its authors described client diversity as a relevant measure of network resilience. Without an agreed format, explorers and researchers must interpret each implementation’s conventions separately.

CIP-0203 would provide that common format. According to Marchand, the core identifier would allow observers to calculate each client’s share of produced blocks regardless of any additional data it publishes.

From Registry to Explorer Support

Participation would be voluntary, including an explicit option to withhold software information. Statistics would reflect producers’ self-reported identifiers, without independently verifying the programs they run.

Reviewers are still discussing how tools should decode optional information such as version numbers. The proposal leaves those formats to individual teams while requiring them to document their meaning.

The proposed path to Active status requires adoption on both sides: at least two independent clients producing blocks with registered identifiers on mainnet or a public testnet, and at least one public explorer or dashboard decoding those identifiers.