Skip to content

VOTING_SYSTEM.md

CeloHT edited this page Aug 10, 2026 · 1 revision

CeloHT Voting System

Document Type: Governance Voting Framework Project: CeloHT Status: Active / Evolving Last Updated: August 2026 Authors: Johnny Dubic & CeloHT Community


1. Overview

The CeloHT Voting System defines how eligible community participants may express their preferences on governance proposals.

The system is designed to support:

  • Transparent decision-making
  • Community participation
  • Accountable governance
  • Structured proposals
  • Verifiable outcomes
  • Responsible delegation of authority

Voting should support the CeloHT mission rather than become a mechanism for concentrating power.


2. Governance Philosophy

CeloHT is community-oriented.

The voting system exists to help the community make important collective decisions while maintaining appropriate technical, legal, security, and operational safeguards.

Voting does not eliminate the need for expertise, evidence, or responsible review.


3. Voting Principles

CeloHT voting follows these principles:

  1. Transparency
  2. Fair participation
  3. Clear eligibility
  4. Verifiable results
  5. Conflict-of-interest disclosure
  6. Security
  7. Accountability
  8. Respect for minority viewpoints

4. What Can Be Voted On?

Depending on governance authority, proposals may concern:

  • Strategic priorities
  • Programs
  • Community initiatives
  • Working groups
  • Treasury allocations
  • Partnerships
  • Governance rules
  • Documentation policies
  • Major project decisions
  • Ecosystem development

Not every operational decision requires a community vote.


5. What Should Not Be Voted On?

Some matters may require specialized authority or immediate action.

Examples include:

  • Emergency security responses
  • Private credentials
  • Confidential personal information
  • Active vulnerability details
  • Routine technical maintenance
  • Individual user support cases

Such decisions should follow the appropriate operational or security procedures.


6. Voting Eligibility

Voting eligibility should be determined by the applicable governance rules.

Eligibility may depend on factors such as:

  • Community participation
  • Verified membership
  • Governance role
  • Contribution status
  • Program participation

CeloHT should avoid creating arbitrary voting rights without a documented governance basis.


7. One Person, One Vote

Where a governance process is designed around individual community participation, the default principle should be:

One eligible participant = one vote.

This reduces the risk that financial resources alone determine community governance.


8. Alternative Voting Models

Certain technical or specialized decisions may use other models when justified.

Possible models include:

  • One-person-one-vote
  • Delegated voting
  • Weighted voting
  • Multisignature approval
  • Council voting
  • Working-group approval

The applicable model should be explicitly stated in the proposal.


9. Proposal Lifecycle

A governance proposal generally follows:

Idea
 ↓
Draft
 ↓
Discussion
 ↓
Review
 ↓
Formal Proposal
 ↓
Voting
 ↓
Result
 ↓
Execution
 ↓
Reporting

10. Proposal Requirements

A formal proposal should include:

  • Title
  • Author
  • Problem
  • Proposed action
  • Rationale
  • Expected impact
  • Risks
  • Resources required
  • Implementation plan
  • Voting period
  • Decision threshold

11. Proposal Discussion

Before voting begins, participants should have an opportunity to review and discuss the proposal.

Discussion should focus on:

  • Evidence
  • Feasibility
  • Risks
  • Costs
  • Benefits
  • Alternatives

Personal attacks should not replace substantive discussion.


12. Proposal Revision

A proposal may be revised during the discussion period.

Material changes should be clearly identified.

If a change substantially alters the proposal, the voting period may need to restart.


13. Formal Voting Period

A formal proposal should specify:

  • Start date
  • End date
  • Eligible voters
  • Voting method
  • Required threshold

Participants should have sufficient time to understand the proposal.


14. Voting Options

Depending on the proposal, voting options may include:

  • Yes
  • No
  • Abstain

Additional options may be used when appropriate.


15. Abstention

An abstention indicates that an eligible participant chooses not to support either side.

Abstentions should be reported separately.

The effect of abstentions on the final result should be defined before voting begins.


16. Quorum

Quorum is the minimum participation required for a vote to be considered valid.

A quorum may be defined as:

Number of Valid Votes
        ≥
Required Participation Threshold

The applicable quorum should be published with the proposal.


17. Approval Threshold

A proposal may require a defined percentage of valid votes to pass.

For example:

YES votes / (YES + NO votes) ≥ Required Threshold

The exact threshold should depend on the proposal category.


18. Simple Majority

For appropriate ordinary proposals, approval may require more than 50% of valid votes.

Example:

YES: 60
NO: 40

Result: APPROVED

19. Supermajority

More important decisions may require a higher threshold.

Examples may include:

  • Governance changes
  • Major treasury commitments
  • Fundamental policy changes
  • Structural changes

A supermajority requirement should be specified before voting begins.


20. Special Governance Decisions

Some decisions may require additional safeguards.

Examples:

  • Changing governance rules
  • Changing treasury controls
  • Changing security policies
  • Changing the no-token policy
  • Authorizing major strategic commitments

Such decisions should have clearly documented requirements.


21. Treasury Votes

Treasury proposals should include:

  • Amount
  • Asset
  • Purpose
  • Recipient
  • Expected outcome
  • Risk
  • Funding source

See:

TREASURY.md


22. Conflicts of Interest

Participants should disclose material conflicts of interest.

A participant with a significant conflict may be required to abstain depending on the applicable governance rules.


23. Founder Participation

The founder may participate in governance where eligible.

Founder status should not automatically mean that one person's vote overrides the established governance process.


24. Governance Council

If CeloHT maintains a Governance Council, its voting authority should be clearly defined.

The Council should not exercise powers that have not been granted through the applicable governance framework.

See:

GOVERNANCE.md


25. Working Groups

Working groups may use internal voting procedures for operational decisions.

Working-group votes should remain within the group's delegated authority.

See:

WORKING_GROUPS.md


26. Delegated Voting

If delegation is supported, an eligible participant may authorize another participant to vote on their behalf.

Delegation rules should specify:

  • How delegation is created
  • How it can be revoked
  • Whether it is proposal-specific
  • Whether delegated power expires

27. Vote Privacy

Depending on the voting system, votes may be:

  • Public
  • Privately recorded
  • Cryptographically verifiable
  • Anonymous

The system should balance transparency with protection against coercion or retaliation.


28. On-Chain Voting

If CeloHT uses blockchain-based governance, votes may be recorded through smart contracts.

Benefits can include:

  • Public verification
  • Tamper resistance
  • Automated counting
  • Transparent execution

Blockchain voting also introduces technical and smart-contract risks.


29. Off-Chain Voting

Community votes may also occur through approved off-chain systems.

Examples include:

  • Governance platforms
  • Community forums
  • Structured polling systems

The chosen system should provide an appropriate audit trail.


30. Vote Verification

After voting ends, results should be independently verifiable where technically possible.

Verification may include:

  • Total votes
  • Vote distribution
  • Eligibility
  • Quorum
  • Approval threshold
  • Final result

31. Duplicate Voting

The voting system should prevent unauthorized duplicate votes where possible.

Controls may include:

  • Account-based identity
  • Cryptographic signatures
  • Verified membership
  • Governance credentials

32. Sybil Resistance

A governance system must consider the possibility of fake identities attempting to obtain disproportionate influence.

Potential safeguards include:

  • Verified membership
  • Contribution-based eligibility
  • Identity mechanisms
  • Community verification

No system provides perfect Sybil resistance.


33. Vote Manipulation

The following are prohibited:

  • Fake votes
  • Account impersonation
  • Vote buying
  • Credential theft
  • Unauthorized access
  • Technical manipulation
  • Deliberate misinformation

Suspected manipulation should be investigated.


34. Vote Buying

Participants should not exchange money or unauthorized benefits for votes.

Any attempt to purchase governance influence should be treated as a serious governance-integrity issue.


35. Voter Coercion

Participants should be free to vote without threats or intimidation.

Where vote privacy is available, it should be used to reduce coercion risks.


36. Campaigning

Participants may advocate for proposals through legitimate discussion.

Campaigning should remain:

  • Factual
  • Respectful
  • Transparent

False claims and impersonation are not acceptable.


37. Governance Information

Before voting, participants should have access to enough information to make an informed decision.

A proposal should not intentionally hide material risks or costs.


38. Voting Deadline

Voting should close at the published deadline.

Extensions should only occur under documented governance rules.

If a vote is extended, the reason should be communicated publicly where appropriate.


39. Invalid Votes

Votes may be invalidated when they result from:

  • Ineligible participants
  • Technical manipulation
  • Duplicate unauthorized submissions
  • Fraud
  • Other violations of the applicable voting rules

Invalidation procedures should be documented.


40. Disputed Votes

If the validity of a vote is challenged:

  1. Record the dispute.
  2. Preserve relevant evidence.
  3. Review the applicable rules.
  4. Investigate objectively.
  5. Publish the outcome where appropriate.

41. Recounts

A recount may be performed when:

  • A technical error is identified.
  • Results are disputed.
  • The vote margin is affected by a verified issue.

The recount process should be reproducible.


42. Tie Votes

A tie should not automatically result in approval.

Possible procedures include:

  • Additional discussion
  • Revote
  • Mediation
  • Proposal modification
  • Escalation to an authorized governance body

The applicable procedure should be defined in advance where possible.


43. Failed Proposals

A failed proposal may be revised and resubmitted.

A new vote should clearly identify what has changed.


44. Successful Proposals

An approved proposal should move into an implementation phase.

The responsible party should communicate:

  • Implementation status
  • Major milestones
  • Delays
  • Completion

45. Execution Authority

Passing a vote does not automatically mean that every implementation detail is authorized.

Execution must remain within the authority granted by the proposal and applicable policies.


46. Governance Records

Important voting records should be preserved.

Records may include:

  • Proposal
  • Discussion
  • Voting period
  • Results
  • Implementation status
  • Final outcome

47. Transparency of Results

Final results should normally communicate:

Proposal
Voting Period
Eligible Participants
Votes
Quorum
Approval Threshold
Result
Implementation Status

48. Governance Analytics

CeloHT may publish aggregate governance metrics such as:

  • Number of proposals
  • Participation rate
  • Approval rate
  • Average voting participation
  • Proposal categories
  • Implementation rate

Metrics should be clearly defined.


49. Security of the Voting System

Voting infrastructure should be protected against:

  • Account takeover
  • Smart-contract vulnerabilities
  • Database manipulation
  • Authentication attacks
  • Denial-of-service attacks
  • Unauthorized administrative actions

See:

SECURITY.md


50. Emergency Governance

Some emergencies cannot wait for a standard voting cycle.

Emergency powers should be:

  • Narrowly defined
  • Time-limited
  • Documented
  • Reviewable

Emergency authority should not become a permanent substitute for normal governance.


51. Governance Abuse Prevention

No participant should use governance authority to:

  • Steal treasury resources
  • Suppress legitimate criticism
  • Manipulate records
  • Retaliate against voters
  • Obtain unauthorized personal benefits

52. Accessibility

Voting systems should be reasonably accessible to eligible participants.

Where possible, CeloHT should consider:

  • Mobile access
  • Clear language
  • Educational explanations
  • Accessible documentation
  • Reasonable voting periods

53. Education Before Participation

Participants should be encouraged to understand:

  • What they are voting on
  • What authority the proposal has
  • What risks exist
  • What resources are involved
  • What happens if the proposal passes

54. Governance Changes

Changes to the voting system itself should normally require a formal governance process.

A proposal to change voting rules should explain:

  • Current rule
  • Proposed rule
  • Reason for change
  • Expected effect
  • Risks

55. Relationship to Governance

This document should be read together with:

  • GOVERNANCE.md
  • WORKING_GROUPS.md
  • TREASURY.md
  • TRANSPARENCY.md
  • SECURITY.md

If another authoritative governance document establishes a specific requirement, the applicable hierarchy should be followed.


56. Continuous Improvement

The voting system should evolve as CeloHT grows.

Future improvements may include:

  • Better voter verification
  • Improved accessibility
  • On-chain governance
  • Delegation
  • Better analytics
  • Stronger Sybil resistance
  • Independent governance audits

57. Final Statement

Voting is a tool for collective decision-making, not a substitute for responsibility.

A healthy governance system requires informed participants, transparent rules, secure infrastructure, and respect for different viewpoints.

The guiding principle is:

Make governance understandable, make votes verifiable, protect participation, and ensure that decisions remain accountable to the community.


Document Status: Active / Evolving Maintained By: CeloHT Community Founder: Johnny Dubic Primary Principle: Transparent, secure, informed, and accountable community governance

CeloHT

Community-powered Web3 for real-world impact.

CeloHT is an open-source community initiative building practical solutions around Web3, financial inclusion, education, decentralized services, and environmental impact.

Learn. Build. Participate. Impact.

Clone this wiki locally