​

Governance

​

Overview

​

Validator-Only Governance

1. AfterProposalSubmission: Only authorized validators can submit proposals
2. AfterProposalDeposit: Only authorized validators can deposit on proposals
3. AfterProposalVote: Only authorized validators can vote

• Registered in PoA module
• Power > 0
• Has valid operator address

• If non-validator attempts governance action → transaction fails
• If validator has power = 0 → transaction fails
• Error: “voter X is not an active PoA validator”

​

Voting Power

1. Vote Collection: System iterates all votes on a proposal
2. Validator Check: For each vote, verify voter is active PoA validator
3. Weight Calculation: Use validator’s power as voting weight
4. Weighted Options: Supports split votes, exactly like x/staking in traditional POS governance (e.g., 70% Yes, 30% Abstain)
5. Tally Results: Sum weighted votes by option

​

Vote Tallying Algorithm

• $V_i$ = voting power of validator $i$
• $P_i$ = validator power (consensus weight)

• $W_{i,o}$ = vote weight from validator $i$ for option $o$
• $w_{i,o}$ = weight assigned to option $o$ by validator $i$ (where $\sum_{o} w_{i,o} = 1$)

• $T_o$ = total votes for option $o$
• Sum over all validators who voted

​

Example

• $W_{A,Yes} = 100 \times 1.0 = 100$

• $W_{B,Yes} = 50 \times 0.6 = 30$
• $W_{B,No} = 50 \times 0.4 = 20$

• $T_{Yes} = 130$
• $T_{No} = 20$

​

Proposal Lifecycle

​

1. Proposal Submission

1. Standard governance validates the proposal content
2. AfterProposalSubmission hook is called
3. PoA module checks if proposer is authorized validator:
   • Look up proposer by operator address
   • Verify validator exists and has $P > 0$
   • If not active, reject with error
4. If valid, proposal enters deposit period

​

2. Deposit Period

1. Standard governance processes the deposit
2. AfterProposalDeposit hook is called
3. PoA module checks if depositor is authorized validator
4. If deposit threshold reached, proposal moves to voting period

​

3. Voting Period

1. Standard governance records the vote
2. AfterProposalVote hook is called
3. PoA module validates voter is authorized validator
4. If invalid, transaction fails

• Yes: Support the proposal
• No: Oppose the proposal
• NoWithVeto: Oppose and veto (can burn deposits if threshold met)
• Abstain: Participate in quorum without taking a position

​

4. Vote Tallying

1. Iterate all votes on the proposal
2. For each vote, look up the validator by voter address
3. If validator is not active ($P \leq 0$), skip the vote
4. Otherwise, use validator power as voting weight
5. For weighted votes, distribute power across options
6. Sum all weighted votes by option
7. Apply standard governance thresholds:
   • Quorum: Minimum participation percentage
   • Threshold: Minimum “Yes” percentage to pass
   • Veto: Maximum “NoWithVeto” percentage before rejection

​

Implementation Details

​

Governance Hooks

type GovHooks interface {
    AfterProposalSubmission(ctx, proposalID, depositorAddr)
    AfterProposalDeposit(ctx, proposalID, depositorAddr)
    AfterProposalVote(ctx, proposalID, voterAddr)
    // ... other hooks
}

1. Extracts the operator address from the context
2. Looks up the validator by operator address
3. Checks if validator exists and has power > 0
4. Returns error if validation fails

​

Custom Tally Function

func NewPoACalculateVoteResultsAndVotingPowerFn(keeper) TallyFn {
    return func(ctx, proposal) (totalVotingPower, results) {
        // Iterate votes
        for vote in votes(proposal) {
            validator = keeper.GetValidatorByOperator(vote.voter)
            if validator == nil || validator.Power <= 0 {
                continue // Skip non-authorized validators
            }

            // Add validator power to total
            totalVotingPower += validator.Power

            // Apply vote weights
            for option, weight in vote.options {
                results[option] += validator.Power * weight
            }
        }
        return totalVotingPower, results
    }
}

​

Governance Parameters

• MinDeposit: Minimum tokens required to enter voting period
• MaxDepositPeriod: Time limit for reaching minimum deposit
• VotingPeriod: Duration of the voting period
• Quorum: Minimum participation rate (fraction of total power)
• Threshold: Minimum “Yes” rate to pass (fraction of non-abstain votes)
• VetoThreshold: Maximum “NoWithVeto” rate before rejection

​

Security Considerations

1. Validator Exclusivity:
   • Only authorized validators (power > 0) can participate
   • Prevents sybil attacks through unauthorized validator spam
   • Ensures governance represents actual consensus participants
2. Power-Based Voting:
   • Voting weight tied to consensus power
   • Admin controls power distribution, thus controls governance indirectly
3. Admin Governance Control:
   • Admin can change validator power at any time
   • Admin can effectively control governance by adjusting power
   • Consider multi-sig admin or governance-controlled admin changes
4. Proposal Spam Prevention:
   • Restricting submissions to authorized validators reduces spam
   • Deposit requirements still apply
   • Validators have reputational stake in proposal quality

​

Comparison to Standard Governance

​

Example Governance Flow

1. Submit Proposal:
   • Validator A (power = 40) submits MsgSubmitProposal
   • Hook verifies A is authorized validator
   • Proposal enters deposit period
2. Reach Deposit:
   • Validator B (power = 30) deposits
   • Validator C (power = 30) deposits
   • Deposit threshold reached → voting period starts
3. Voting:
   • Validator A: 100% Yes (40 power → 40 Yes votes)
   • Validator B: 60% Yes, 40% No (30 power → 18 Yes, 12 No)
   • Validator C: 100% Abstain (30 power → 30 Abstain)
   • Total power: 100 (all authorized validators)
4. Tally:
   • Total voting power: 100 (all voted)
   • Quorum: 100/100 = 100% ✓ (assuming 33% quorum)
   • Results: 58 Yes, 12 No, 30 Abstain (out of 70 non-abstain)
   • Threshold: 58/70 = 82.9% Yes ✓ (assuming 50% threshold)
   • Proposal passes