Skip to main content

Local Governance Model

Locale Network provides templated governance frameworks that City Chains can adopt and customize. These are not built-in systems but rather flexible blueprints that communities configure to match their needs and local regulations.

Governance Templates

The governance structures described here are templates and frameworks. Each City Chain adopts, modifies, and implements governance according to their community's requirements. Nothing is mandatory—communities choose what works for them.

Governance Philosophy​

Local First​

City Chain governance prioritizes local stakeholders:

PrincipleImplementation
Geographic IdentityGovernance tied to local residency or stake
Community BenefitDecisions optimized for local outcomes
ParticipationLow barriers to civic engagement
TransparencyAll proposals and votes on-chain

What Can Be Governed?​

CategoryExamples
Protocol ParametersGas limits, block times, fee structures
TreasuryAllocation of community funds
UpgradesSmart contract changes, new features
IoT NetworkL{CORE} sensor policies, data access rules
Access ControlWho can deploy contracts, run nodes

Template Architecture​

Local Governance Model
GOVERNANCE STRUCTURE
Token Holders
Vote on proposals
Council
Execute decisions
Treasury
Manage funds
Decisions Flow
ProposalsDiscussionVotingExecution

Participation Models​

Token-Based Voting​

Standard governance token model where voting power equals token balance.

AspectDescription
Mechanism1 token = 1 vote
ProsSimple, proven, widely understood
ConsPlutocratic—wealthy holders dominate
Best ForCommunities with distributed token ownership

Quadratic Voting​

Voting power equals the square root of tokens held.

AspectDescription
MechanismVoting power = √(token balance)
ProsMore egalitarian, reduces whale dominance
ConsSybil attacks possible without identity verification
Best ForCommunities prioritizing broad participation

Identity-Verified Voting​

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

AspectDescription
MechanismVerified resident = 1 vote
ProsTrue democracy, prevents Sybil attacks
ConsRequires identity verification infrastructure
Best ForCommunities with strong local identity

How it works:

  1. Resident proves identity via L{CORE} attestation
  2. Attestation verifies residency without exposing PII
  3. One vote per verified resident

Hybrid Models​

Communities can combine approaches:

ModelDescription
Quadratic + Identity BonusResidents get 2x voting power
Tiered ThresholdsDifferent quorums for different proposal types
DelegationToken holders can delegate votes
Conviction VotingTime-weighted preference accumulation

Proposal Lifecycle​

Proposal Lifecycle
Draft
Review
Active
Queued
Executed

Configurable Parameters​

Communities configure these values when deploying governance:

ParameterTypical RangeCommunity Decides
Proposal Threshold0.1-1% of supplyMinimum tokens to propose
Quorum4-10% of supplyMinimum participation
Voting Period3-7 daysTime for voting
Timelock Delay24-72 hoursDelay before execution

Treasury Template​

Revenue Sources​

City Chain treasuries can accumulate funds from:

SourceDescription
Transaction FeesPortion of gas fees
L{CORE} Attestation FeesIoT data submission charges
Lending ProtocolInterest spread from Locale Lending
Data MarketplaceCommission on sensor data sales

Spending Categories​

CategoryTypical Allocation
InfrastructureNode operators, sequencer costs
DevelopmentProtocol improvements, new features
CommunityGrants, events, education
EmergencyReserve fund for security incidents

IoT Governance via L{CORE}​

City Chain governance can extend to the IoT network:

Sensor Network Policies​

Governance can update L{CORE} parameters:

ParameterGovernance Control
Submission IntervalMinimum time between attestations
Device LimitsMaximum devices per operator
Location RestrictionsAllowed geographic areas
Data TypesPermitted sensor categories

Data Access Rules​

Governance controls who can access community IoT data:

Access LevelPermissions
PublicAggregate data, anonymized metrics
Verified ResidentsDetailed local data (via L{CORE} attestation)
Approved ResearchersHistorical data with privacy protections
Emergency ServicesReal-time access during incidents

Guardian Role​

For early-stage City Chains, a Guardian (multi-sig) provides safety:

CapabilityPurpose
Emergency PauseHalt contracts during security incidents
Fast-Track PatchesExpedite critical security fixes
Gradual DecentralizationTransfer power to community over time
Time-Limited AuthorityGuardian powers expire automatically

Decentralization Path​

PhaseGuardian PowersCommunity Powers
LaunchFull emergency controlProposal and voting
GrowthEmergency onlyParameter changes
MatureNone (expired)Full governance

Implementation Guide​

For City Chain Operators​

  1. Choose Models — Select voting mechanism that fits community values
  2. Configure Parameters — Set thresholds, periods, and requirements
  3. Deploy Contracts — Use provided deployment scripts
  4. Initialize — Set up initial council and guardian multi-sig
  5. Test — Run through governance scenarios on testnet
  6. Launch — Enable community governance on mainnet

For Community Members​

  1. Understand the Model — Learn how your City Chain's governance works
  2. Get Verified — Complete identity verification if required
  3. Participate — Vote on proposals, join discussions
  4. Propose — Submit ideas for community consideration

Example Configurations​

Conservative Configuration​

For communities prioritizing security:

ParameterValue
Voting ModelToken-weighted
Proposal Threshold1% of supply
Quorum10% of supply
Voting Period7 days
Timelock72 hours
Guardian4-of-7 multi-sig

Progressive Configuration​

For communities prioritizing participation:

ParameterValue
Voting ModelQuadratic + Identity bonus
Proposal Threshold0.1% of supply
Quorum4% of supply
Voting Period3 days
Timelock24 hours
Guardian3-of-5 multi-sig (expires in 6 months)

Next Steps​