fix(governance): return CC voters as CIP-129 cc_hot ids in proposal votes - #351
Merged
Conversation
…otes For voter_role constitutional_committee the voter field carried the raw 28-byte hot credential hash in hex, with no way to tell a key hash from a script hash. DRep voters in the same response are already CIP-129 bech32 and SPO voters are pool bech32, so committee voters were the only ambiguous role. Expose committee_hash.has_script from the votes queries and encode the committee voter as a CIP-129 hot credential (cc_hot1...) via the same getCommitteeCredentialId util the /governance/committee endpoints use. Committee votes are always cast by the hot credential: Conway only admits HotCommitteeRole voters, and on mainnet every distinct voting_procedure.committee_voter matches committee_registration hot_key_id (13/13) and none match a cold key. Output verified byte-for-byte against Koios voter_id for mainnet CC votes. Fixes blockfrost/openapi#465
This was referenced Sep 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
For
"voter_role": "constitutional_committee", thevoterfield of/governance/proposals/{tx_hash}/{cert_index}/votes(and the{gov_action_id}variant) returned the raw 28-byte hot credential hash in hex, with no way to tell a key hash from a script hash (blockfrost/openapi#465). DRep voters in the same response are already CIP-129 bech32 and SPO voters are pool bech32, so committee voters were the only ambiguous role.Changes
committee_hash.has_scriptfrom the paged and unpaged votes queriescc_hot1...) via the samegetCommitteeCredentialIdutil the/governance/committeeendpoints use (already covered by CIP-129 official test vectors in unit tests)Why cc_hot and not cc_cold
Committee votes are always cast by the hot credential: Conway only admits
HotCommitteeRolevoters inVotingProcedures, and on mainnet every distinctvoting_procedure.committee_votermatches acommittee_registration.hot_key_id(13/13) while none match a cold key.Verification
Output verified byte-for-byte against Koios
voter_idfor real mainnet CC votes (proposal9b62b3c6...#0), e.g.85c47dd4...(script) →cc_hot1qwzuglw5hx3wwr5gjewerhtfhcvz64s9kgam2fgtrj2t7eqs00fzv.Spec counterpart: blockfrost/openapi#467
Fixes blockfrost/openapi#465