TokenVotingUtil: Production Safety Audit + Roadmap

[Ragnar-no-sleep]

TokenVotingUtil: Production Safety Audit + Roadmap

Summary

Completed empirical code analysis of voting logic. Found 3 critical issues that make the system unsafe for real governance. Code works for happy path, but has edge case bugs that need fixing before $asdfasdfa can run actual votes.

Also: Infrastructure is ready (Jest configured, dependencies in place, tests can run).

Critical Issues Found

1. Threshold Boundary Bug 🔴

Location: public/index.html:1536 in checkThreshold()
Code: return { met: margin >= threshold, margin }
Problem: Threshold is "minimum margin percentage to win", but using >= means proposals pass when margin EQUALS threshold
Example: threshold=5%, margin=5% → met=true (WRONG, should be false)
Impact: Proposals can pass when they shouldn't
Fix: Change >= to > (margin must EXCEED, not equal)

2. No Tie Detection 🟡

Location: public/index.html:2050 in tallyProposal()
Code: if (t > totals[winnerIdx]) winnerIdx = i;
Problem: When two choices have equal votes, code silently declares first one the winner
Example: choice A: 100 votes, choice B: 100 votes → declares A winner (ambiguous)
Impact: Governance unclear on ties
Fix: Add explicit tie detection: if (margin === 0) return { tied: true, candidates: [...] }

3. Frontend Tally Authority 🔴

Location: All tally logic in public/index.html (client-side)
Problem: Vote results calculated and displayed by client JavaScript, no server verification
Impact: No immutable record of result; client can display wrong result
Fix: Add backend endpoint /api/proposals/:id/result that calculates authoritative tally

Positive Findings ✓

• ✓ Vote immutability: append-only, no UPDATE/DELETE
• ✓ Double vote prevention: hasVoted() checked correctly
• ✓ Input validation: solid on proposal creation
• ✓ Voting power modes: both modes (locked-only, all-holders) work correctly
• ✓ Rate limiting: in place (3 proposals/min, 10 votes/min)
• ✓ Error handling: good error messages

Questions for You

1. Are you aware of these bugs? Should we fix them before real voting?
2. Tally authority: Do you want to keep frontend tally for UX, or move to backend-authoritative?
3. Priority order: Which fixes matter most?
4. Review timeline: When would you be available to review PRs if we fix these locally?

Proposed Path Forward

We can:

1. Fix margin bug locally (30 min)
2. Fix tie detection locally (30 min)
3. If you agree: add backend tally endpoint (2-3h)
4. Run a real test vote to validate
5. Push PRs for your review

No pressure on timeline—we adapt to your availability.

Context

• We're contributors to $asdfasdfa ecosystem
• Goal: stabilize TokenVotingUtil for production use (internal governance + multi-DAO future)
• Found bugs via empirical code review + Jest infrastructure validation
• Previous work: Fixed Tier 1 security gaps (CORS, logging, rate limiter, tests)

---

What are your thoughts? Should we proceed with these fixes?