Juryza
Voting integrity

Community voting is the hard problem

Judged scores can be made fair with maths. Community voting cannot — it is an adversarial game against people who want to win. This page tells the real story of how one hackathon community's voting broke, again and again, and maps every failure to a mechanism Juryza enforces in the backend.

A history of breakage

Every step below was a genuine attempt to fix the previous one. The pattern is universal: any signal cheap to produce gets produced at scale by people with something to gain.

1 · Public social vote1/5
What happened

Voting ran on LinkedIn reactions. Fake accounts flooded in and votes were openly bought. A reaction count is not an identity.

How Juryza answers it

Juryza never counts an off-platform reaction. Votes are cast against the API under a defined access mode; a like on a social post is not a vote and cannot be.

2 · Any channel member2/5
What happened

Voting moved to Discord; anyone in the channel could vote. Anyone could join the channel and vote, so it was spammed just as easily.

How Juryza answers it

Access modes gate who can vote: authenticated (accounts only), email (a one-time code, optional domain allowlist), or open (link, with per-network caps). The organizer chooses the strength.

3 · Manual “member before kickoff” check3/5
What happened

Only people who joined before the event started were counted. Enforced by hand, it did not scale and was still gamed at the edges.

How Juryza answers it

The electorate lock automates exactly this rule: set a cutoff and only accounts created on or before it can vote. Accounts made during the hackathon are refused by the server — no manual list.

4 · Voter role / tag4/5
What happened

Only members holding a special voting role could vote. Groups of 50+ organized to acquire the role and brigade a favourite.

How Juryza answers it

A role alone cannot stop coordinated blocs. Juryza raises the cost with quadratic voting — piling votes on one project is expensive — plus per-voter and per-network rate limits, duplicate keying, and an integrity dashboard that surfaces shared networks and burst minutes.

5 · Write-up quest, judges decide5/5
What happened

Open voting was removed; a public write-up challenge on the shortlist, with judges holding final authority. This is where the community landed — and it works because the crowd informs, but does not decide.

How Juryza answers it

Juryza ships this as a first-class mode. Write-up mode collects public input without a live tally to brigade, and the panel makes the final pick — combinable with a shortlist so only the top judged projects are ever in play.

The levers, and when to use them

An organizer configures voting per event. These compose — a strict event might shortlist the top 4, lock the electorate to accounts that existed before kickoff, and run write-up mode so judges decide.

Access mode
authenticated · email (one-time code + optional domain allowlist) · open (link, capped per network). Start strict; loosen only if you must.
Quadratic budget
Each voter has a credit budget; v votes on one project cost v². Intensity is expressible, concentration is expensive. Enforced under a per-voter lock so parallel requests can't overspend.
Electorate lock
Only accounts created on or before a cutoff may vote. Automates the “member before kickoff” rule that once needed a manual list.
Shortlist
Restrict votes to the top-N projects by judged rank. Mirrors the common practice of polling only the finalists — but enforced by the server.
Write-up mode
Collect public input with no live tally to brigade; the judging panel holds final authority over the pick. The crowd informs, judges decide.
Always on
No self-votes, duplicate keying (one row per voter per project), per-IP and per-voter rate limits, and an integrity dashboard (voters by kind, shared networks, burst minutes, full export).

Why judges, not the crowd, decide the top

The community's final answer — a write-up quest judged by the panel — is the right one, and it generalizes. A public vote is best as a signal (a Community Choice award, a tie-breaker among finalists), never as the arbiter of the overall result. Juryza keeps the judged pipeline — assignment scoping, cross-judge normalization, deadline enforcement, results secrecy — as the source of truth, and treats community voting as a bounded, auditable input on top of it. The maths behind the judged result is in the project doc.