Description: To increase user engagement in the voting process and familiarize them with proposals, a mini-test must be added before allowing them to vote.
Functional Requirements:
Mini-Test:
Before voting, the user takes a test related to the proposal content.
The number of questions in the test ranges from 1 to 10 (depending on the complexity of the proposal).
Error Handling:
The user has a limited number of allowed errors.
If the number of errors exceeds the allowed limit, access to voting is blocked for a period ranging from 15 minutes to 1 hour.
The user should not be aware of the number of mistakes until the test is completed.
Result Display:
After completing the test, the user sees only the number of correct answers.
The result is displayed in the format “Passed” / “Not Passed.”
Error details (where exactly mistakes were made) are not shown.
This proposal introduces barriers to participation that undermine decentralisation and inclusivity in Jup DAO governance. By requiring voters to pass a mini-test before participating, it limits access to decision-making and could discourage community members, especially newer or less-experienced ones, from engaging in governance.
Additionally, power is concentrated in the hands of those who design the test, as they effectively control who gets to vote by setting the difficulty level and determining what knowledge is necessary. This creates a risk of bias and manipulation, even if unintentional.
The error-handling mechanism further reduces governance efficiency by delaying participation through lockout periods. Not allowing users to see their mistakes makes the process even more opaque, leading to frustration rather than genuine learning.
I believe your goal/aim in this proposal is to increase engagement and understanding but I strongly believe it could have the opposite effect by reducing participation, creating unnecessary friction, and centralising influence over voting eligibility.