Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
src/hcs-8/state.ts
Outdated
| const existingVotes = this.state.results.voterWeight.get(voter); | ||
| if (existingVotes && !this.evaluator.allowVoteChanges()) { | ||
| this.recordError(message.op, 'Vote changes are not permitted', timestamp); | ||
| return; | ||
| } | ||
| if (existingVotes && this.evaluator.allowVoteChanges()) { | ||
| this.removeExistingVotes(voter); | ||
| } | ||
|
|
||
| this.state.results = applyVotes(this.state.results, votes); |
There was a problem hiding this comment.
Record votes under payer identity instead of entry accounts
During applyVote the permission and weight checks are keyed on message.d.accountId (the transaction payer), but the call to applyVotes stores weights under each vote.accountId. Because the per‑voter ledger lookup at line 191 also uses message.d.accountId, a payer can send multiple messages where the votes array contains different accountId values; each call passes validation (weight is limited per message) yet the stored votes are tracked under the forged account IDs, so existingVotes is never found for the payer. This allows one user to repeatedly vote and attribute the weight to arbitrary accounts, bypassing both duplicate‑vote prevention and identity tracking. The entries’ account IDs should either be ignored/overridden with the payer or validated to match before updating results.
Useful? React with 👍 / 👎.
Summary
HCS-8 + HCS-9 implementation