feat(governance): add counted flag to proposal votes (re-land #352) - #353
Merged
Conversation
The votes endpoint returns every vote-cast transaction ever submitted for a proposal, but the ledger keeps only the latest vote per voter (upsert semantics) and drops a DRep's votes on deregistration, so the response can diverge significantly from the current ledger vote state (queryLedgerState/governanceProposals in Ogmios). Add a boolean "counted" to each vote entry: true only for the voter's latest vote on the proposal, and for DRep voters only when no deregistration follows the vote — re-registering does not restore previously dropped votes, so the check is "no dereg after the vote's tx", not "currently registered". Recency is a window rank per voter within the proposal's votes; the dereg check is an index-only scan on bf_idx_drep_registration_hash_deposit. Validated on mainnet db-sync: on the busiest proposal (453 votes) the flag marks 99 votes uncounted (36 superseded re-votes + 63 latest votes of since-deregistered DReps), no voter retains more than one counted vote, paged/unpaged outputs and ordering are unchanged, and a warm page returns in ~50ms. Requires @blockfrost/openapi with the counted field in proposal_votes (blockfrost/openapi#466); until the dependency is bumped the field is stripped by response serialization. Fixes blockfrost/openapi#466
…e set A DRep deregistration only drops votes from proposals that are still live; once a proposal is ratified/enacted/dropped/expired its tally is frozen, so a later deregistration must not retroactively mark the vote uncounted. Bound the deregistration check by the epoch in which the proposal left the active set (LEAST of the gov_action_proposal epoch columns; NULL = still live, tip semantics unchanged). On mainnet this matters a lot for closed proposals: gap 12 had 65 of 453 votes wrongly flagged uncounted by post-closure deregistrations (now 39 uncounted: 36 superseded + 3 pre-closure deregistrations).
Brings the counted field and cc_hot voter schema for
/governance/proposals/{tx_hash}/{cert_index}/votes so response
serialization no longer strips the new field.
feat(governance): add counted flag to proposal votes
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.
#352 was merged while its base was still
fix/proposal-votes-cc-cip129(GitHub only retargets stacked PRs to master when the base branch is deleted on merge, and #351 kept its branch), so its changes landed on that branch instead of master. This PR delivers the identical delta to master: thecountedfield implementation, the @blockfrost/openapi 0.1.93 bump, and the 6.8.0 version bump.See #352 for the full description, mainnet validation, perf comparison, and the Koios cross-check.
Fixes blockfrost/openapi#466