Voting Mechanisms

Locale Network provides voting mechanism templates that City Chains can adopt and customize. These are not built-in systems—each community selects and configures voting mechanisms according to their values and needs.

Voting Templates

The voting mechanisms described here are templates. Each City Chain chooses which mechanisms to implement and how to configure them. Communities may combine multiple approaches or create custom variations.

Available Voting Models

Token-Weighted Voting

The standard model where voting power equals token holdings.

Parameter	Description	Typical Range
Weight Calculation	1 token = 1 vote	Fixed
Delegation	Optional	Enabled/Disabled
Snapshot Block	When to capture balances	Proposal creation

Best For:

• Communities with broad token distribution
• Simple, well-understood governance needs
• Integration with existing DeFi ecosystems

Considerations:

• Wealthy holders have more influence
• Can lead to voter apathy among smaller holders
• Susceptible to vote-buying through token acquisition

Quadratic Voting

Voting power equals the square root of tokens held.

Parameter	Description	Typical Range
Weight Calculation	√(token balance)	Fixed formula
Minimum Balance	Tokens required to vote	1-100 tokens
Maximum Power	Cap on individual influence	Optional

Best For:

• Communities prioritizing broad participation
• Reducing plutocracy while maintaining skin-in-the-game
• Balancing small and large stakeholders

Considerations:

• Vulnerable to Sybil attacks without identity verification
• More complex for users to understand
• Requires careful parameter tuning

Identity-Verified Voting

One verified person, one vote using L{CORE} attestations.

Parameter	Description	Typical Range
Verification Type	L{CORE} attestation required	Residency, membership
Vote Weight	Fixed per verified identity	1 vote
Credential Expiry	How long verification lasts	6-12 months

Best For:

• Communities with strong local identity
• Maximum democratic participation
• Preventing Sybil attacks

Considerations:

• Requires identity verification infrastructure
• Privacy considerations for participants
• May exclude transient community members

Conviction Voting

Voting power increases the longer tokens are locked for a proposal.

Parameter	Description	Typical Range
Decay Rate	How conviction builds over time	1-7 days to max
Max Conviction	Maximum multiplier	2-10x
Threshold	Required conviction to pass	Per proposal type

Best For:

• Continuous funding decisions
• Reducing proposal spam
• Encouraging long-term thinking

Considerations:

• Slower decision-making
• Complex to understand and implement
• May disadvantage urgent proposals

Hybrid Approaches

Quadratic + Identity Bonus

Combines quadratic voting with residency verification:

Component	Calculation
Base Votes	√(token balance)
Identity Bonus	+100% for verified residents
Final Power	Base × (1 + bonus)

Example:

• 100 tokens + unverified = √100 = 10 votes
• 100 tokens + verified = √100 × 2 = 20 votes

Tiered Governance

Different voting rules for different proposal types:

Proposal Type	Voting Model	Quorum	Threshold
Parameter Change	Token-weighted	4%	50%
Treasury Spend	Quadratic	6%	60%
Protocol Upgrade	Identity-verified	10%	66%
Emergency Action	Guardian multi-sig	N/A	4-of-7

Delegated Voting

Token holders can delegate their voting power:

Delegation Type	Description
Full Delegation	Delegate receives all voting power
Proposal-Specific	Delegate only for certain proposals
Partial Delegation	Delegate portion of voting power
Liquid Delegation	Can be revoked at any time

Voting Parameters

Quorum Requirements

Minimum participation needed for a valid vote:

Quorum Type	Description	Typical Value
Absolute	Fixed number of votes	100,000 votes
Relative	Percentage of supply	4-10%
Participation	Percentage of eligible	20-40%
Tiered	Different by proposal type	Varies

Approval Thresholds

Votes needed to pass a proposal:

Threshold Type	Description	Typical Value
Simple Majority	> 50% approval	Standard proposals
Supermajority	≥ 66% approval	Major changes
Qualified Majority	≥ 75% approval	Constitutional changes
Unanimous	100% approval	Guardian actions

Voting Periods

Time allowed for voting:

Proposal Type	Voting Period	Reasoning
Standard	5-7 days	Adequate review time
Minor	3 days	Quick decisions
Major	14 days	Thorough consideration
Emergency	24-48 hours	Urgent response

Anti-Manipulation Measures

Snapshot Voting

Measure	Description
Block Snapshot	Balance captured at proposal creation
Prevents	Last-minute token acquisition
Trade-off	Tokens acquired after snapshot don't count

Vote Locking

Measure	Description
Lock Period	Tokens locked during voting
Prevents	Vote-and-sell attacks
Trade-off	Reduced liquidity for voters

Timelock Delays

Measure	Description
Execution Delay	Wait period after vote passes
Prevents	Malicious proposals executing immediately
Trade-off	Slower governance execution

Implementation Guide

Choosing a Voting Model

Consider these factors:

Factor	Token-Weighted	Quadratic	Identity-Verified
Simplicity	High	Medium	Low
Sybil Resistance	Built-in	Requires identity	Built-in
Equality	Low	Medium	High
Engagement	Lower	Higher	Highest
Infrastructure	Minimal	Minimal	Identity system

Configuration Checklist

1. Select primary voting model — Based on community values
2. Set quorum requirements — Balance participation and efficiency
3. Configure thresholds — Match to proposal importance
4. Define voting periods — Allow adequate deliberation
5. Implement safeguards — Snapshots, timelocks, limits
6. Test extensively — Simulate various scenarios

Learn More

• Local Governance Model — Overall governance framework
• Treasury Management — Fund allocation governance
• Upgrade Process — Protocol change governance
• L{CORE} for Identity — Attestation-based voting