feat(rounds): gate voting by delegated Gnars votes at a fixed snapshot - #294
Merged
Conversation
Builds on xSatori's r4topunk#115 (all UI/route/service structure is theirs): rounds voting requires delegated Gnars voting power, enforced server- side at vote submission. One change on top: the power is read with getPastVotes at the round's voting-open instant instead of live getVotes. Live votes let the same Gnars vote once per re-delegation hop (A delegates to B, B votes, A re-delegates to C, C votes — usage is tracked per wallet, so every hop arrives fresh; on fixed_per_wallet each hop gets the FULL per-wallet allotment). The checkpoint at votingStartsAt is immutable, so those Gnars sat in exactly one wallet at that instant — the same snapshot model the onchain governor uses, and the policy that comes with it: delegating transfers the vote. The Gnars token runs timestamp clock mode (ERC-6372), so the timepoint is the round's votingStartsAt directly — no block derivation. A future timepoint returns 0 without touching the chain (ERC-5805 would revert, and an unopened round has no snapshot). Co-authored-by: xSatori <99294685+xSatori@users.noreply.github.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@sktbrd is attempting to deploy a commit to the r4to's projects Team on Vercel. A member of the Team first needs to authorize it. |
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
2 participants
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
Supersedes #115, keeping all of @xSatori's structure (route, service, UI states, tests — co-authored in the commit) and adding the one change review demanded: the power is read at a fixed snapshot, not live.
getVotesleft open: vote usage is tracked per(round, wallet)in Postgres, and nothing records which delegated power voted. A delegates to B → B votes → A re-delegates to C → C votes: the same Gnars vote once per hop, and onfixed_per_walletevery hop gets the FULL per-wallet allotment — delegation is free, so 10 Gnars + N empty wallets = N ballots. The gate this PR exists to build would leak through the very mechanism it gates on.getPastVotes(wallet, round.votingStartsAt). The Gnars token runs timestamp clock mode (ERC-6372) — already documented inuseCastVote.ts— so the round's opening instant is the timepoint directly; no block derivation, no schema change, same single RPC read. The checkpoint is immutable: re-delegating after voting opens moves nothing.votingStartsAtreturns 0 without touching the chain (ERC-5805 would revert; an unopened round has no snapshot).Who can vote, before → after
castRoundVote), not just in UI.Test plan
getPastVotesat the exact timestamp) and the future-round guardGenerated with Claude Code