Implement Ballot Access Control Layers

[Just-Bamford]

��# Issue 13: Implement Ballot Access Control Layers

Problem

All methods require admin, but system needs role-based access (operators, verifiers, read-only).

Solution

• Add AccessControl enum: Admin, BallotOperator, ResultVerifier, ReadOnly
• Implement grant_role() and revoke_role() functions
• Modify method authorization to check roles instead of just admin
• Operators can record tokens/votes; verifiers can publish results; read-only users query only

Implementation Tasks

• Define AccessControl enum in lib.rs
• Add role mapping: address �! Vec<Role> in storage
• Implement grant_role(address, role) (admin only)
• Implement revoke_role(address, role) (admin only)
• Update method guards to check roles: require_role(BallotOperator) etc.
• Unit tests: role-based access control enforced
• Test: revoked roles are properly denied

Note for Contributors

Complete Issue #7 (admin rotation) first to ensure admin control is solid. Role-based access enables separation of duties: only Admin can manage roles, BallotOperators can record ballots/tokens/votes, ResultVerifiers can publish results, ReadOnly users query audit data. One address can hold multiple roles. Use a map from Address to Vec for efficient lookup. Ensure revoked roles take effect immediately. Admin role is immutable and always has full privileges. Test permission inheritance and privilege escalation vulnerabilities. Consider that ReadOnly access might need read-only calls to be free (no transaction cost).

[Mrwicks00]

Please assign this issue to me, I will do the best job and deliver very quickly

[grantfox-oss]

🦊 GrantFox — @Mrwicks00 has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #31)
2. Your PR will be reviewed by the AnonVote maintainers

Good luck! Track your progress on GrantFox.