Decentralized Hive Fund (DHF) Vote Weighting System

Overview

This post explains the enhanced DHF vote weighting system that introduces economic rationality to proposal voting by limiting vote power based on voting commitment relative to daily inflows(10% of inflation) and apathy. hive-disregardfiat/dhf-vote-weighting

This post aims to encourage discussion, critique, and improvements to HIVE. I fully expect if this or any other derivative gets implemented it will be through thorough and lengthy discussion and testing.

Background

The original DHF system allowed accounts to vote for unlimited proposals without consequence, leading to potential economic irrationality where voters could support far more funding than the treasury could provide. The enhanced system addresses this by weighing votes based on the voter's total daily funding commitment versus the actual daily DHF inflows. Due to the nature of a good portion of our HIVE DHF being from the Ninja Mine. I also propose capping the weight penalty at the percentage of voting stake(simply calculated here as raw support for the most popular proposal divided by total Hive Power).

Key Concepts

Large Proposal Mechanism (Including Return Proposals)

The system recognizes that any proposal requesting more than the sustainable daily rate (fund/100) effectively acts as a threshold-setting mechanism:
- Traditional Return Proposal: Has the treasury (hive.fund) as receiver, funds return to treasury
- Alternative Large Proposals: Could go to automated market makers, burn mechanisms, or other destinations
- Sustainable Rate: Treasury fund size ÷ 100 = maximum sustainable daily spending (1% of treasury per day)
- Commitment Capping: For vote weighting, large proposals are capped at sustainable daily rate (fund/100)
- One Large Proposal Rule: Each voter's commitment calculation only includes one large proposal. This allows voters to support multiple large ideas, knowing they are only "on the hook" for one, preventing excessive vote weight reduction.
- Economic Reality: Voting for more than sustainable rate has same economic effect regardless of destination
- Threshold Setting: Community can set funding thresholds via any large proposal, not just treasury returns

Vote Weighting Formula

proportional_weight = min(1.0, daily_dhf_inflow / total_daily_commitment)
minimum_weight = highest_raw_vote_total / total_vesting_shares
final_vote_weight = max(proportional_weight, minimum_weight) * base_vote_power

daily_dhf_inflow: running average of the 10% inflation that goes into the DHF
total_daily_commitment: Proposals an account votes for
highest_raw_vote_total: Highest unweighted proposal(highest consensus spending)

Consensus-Driven Minimum Weight Floor

The system implements a dynamic minimum weight floor that automatically adjusts based on voting participation:
- Highest Raw Vote Tracking: During Phase 1, the system tracks the highest raw vote total across all proposals
- Minimum Weight Calculation: minimum_weight = (highest_raw_vote_total / total_vesting_shares) * 100%
- Automatic Threshold Adjustment: High consensus participation raises the minimum weight, effectively increasing the return threshold
- Participation Reward: Widespread voting prevents individual vote weights from falling too low

Current Personal Example:
- Daily DHF inflow: 1750 HBD (~10% inflation at $0.20 Hive)
- Treasury fund size: 23,500,000 HBD (Larger due to HBD Stabilizer return and Ninja Mine allocation)
- Sustainable daily rate: 23,500,000 ÷ 100 = 235,000 HBD/day
- Total vesting shares: 309,871,159,288 VESTS
- Highest raw vote total: ~120,000,000,000 VESTS (on VSC proposal)
- Voter(personal) commits to: 9 proposals for 4,000 HBD total
- Proportional weight: min(1.0, 1750/4,000) = 0.4375
- Minimum weight: 120,000,000,000 / 309,871,159,288 = 0.387 (38.7%)
- Final weight multiplier: max(0.4375, 0.387) = 0.4375
- All their votes carry 43.75% weight

Basic Example:
- Daily DHF inflow: 1000 HBD
- Treasury fund size: 150,000 HBD
- Sustainable daily rate: 150,000 ÷ 100 = 1,500 HBD/day
- Total vesting shares: 1,000,000,000 VESTS
- Highest raw vote total: 50,000,000 VESTS (on most popular proposal)
- Voter commits to: Large proposal (2000 HBD/day, capped at 1500) + Proposal A (300 HBD) + Proposal B (200 HBD) = 2,000 HBD total
- Proportional weight: min(1.0, 1000/2000) = 0.5
- Minimum weight: 50,000,000 / 1,000,000,000 = 0.05 (5%)
- Final weight multiplier: max(0.5, 0.05) = 0.5
- All their votes carry 50% weight

Consensus Raises Threshold Example:
- Daily DHF inflow: 1000 HBD
- Treasury fund size: 150,000 HBD
- Sustainable daily rate: 1,500 HBD/day
- Total vesting shares: 1,000,000,000 VESTS
- High Participation Scenario: Highest raw vote total: 200,000,000 VESTS (20% of all VESTS voting)
- Voter commits to:
- Large Proposal A (2000 HBD/day, capped at 1500)
- Large Proposal B (1800 HBD/day, commitment is 0 due to "one large" rule)
- Small proposal (200 HBD)
- Total Commitment: 1500 + 0 + 200 = 1,700 HBD
- Proportional weight: min(1.0, 1000/1700) = 0.59
- Minimum weight (consensus floor): 200,000,000 / 1,000,000,000 = 0.20 (20%)
- Final weight multiplier: max(0.59, 0.20) = 0.59
- Result: Normal proportional reduction applies

High Consensus Scenario:
- Same setup, but 40% participation: Highest raw vote total: 400,000,000 VESTS
- Heavily over-committed voter: Total commitment = 5,000 HBD (5× daily inflow)
- Proportional weight: min(1.0, 1000/5000) = 0.20
- Minimum weight (consensus floor): 400,000,000 / 1,000,000,000 = 0.40 (40%)
- Final weight multiplier: max(0.20, 0.40) = 0.40
- Result: Consensus participation prevents vote weight from falling below 40%, effectively raising the return threshold

Implementation Details

Data Structure Changes

Global Properties (dynamic_global_property_object)

// DHF daily inflow tracking for vote weighting
fc::array< asset, 24 > dhf_hourly_inflows = fc::array< asset, 24 >(); ///< Rolling 24-hour window of hourly DHF inflows
uint8_t dhf_current_hour_index = 0; ///< Current index in the rolling window
asset dhf_cached_daily_total = asset( 0, HBD_SYMBOL ); ///< Cached sum of all 24 hourly inflows
time_point_sec dhf_inflow_last_update = HIVE_GENESIS_TIME; ///< Last time inflow tracking was updated

Account Object (account_object)

// DHF voting commitment tracking for vote weighting
HBD_asset dhf_total_daily_commitment = HBD_asset( 0 ); ///< Total HBD/day this account is committed to via active proposal votes
time_point_sec dhf_commitment_last_update = fc::time_point_sec::maximum(); ///< Last time DHF commitment was recalculated
uint16_t dhf_active_proposal_count = 0; ///< Number of active proposals this account is voting for

Core Algorithm Implementation

Daily Inflow Tracking

• Hourly Recording: Every hour during maintenance, the dhf_interval_ledger amount is recorded in the rolling 24-hour window
• Efficient Caching: The daily total is maintained as a cached sum, updated incrementally
• Memory Efficient: Only stores 24 hourly values (24 × 8 bytes = 192 bytes per global state)

Vote Calculation Process

Phase 1: Raw Calculation + Commitment Tracking

sustainable_rate = treasury_fund / 100
highest_raw_vote_total = 0

for each proposal:
    raw_total_votes = 0
    for each voter on proposal:
        raw_total_votes += voter.governance_vote_power

        commitment = (proposal.daily_pay > sustainable_rate) ? sustainable_rate : proposal.daily_pay
        voter_commitments[voter] += commitment

        if voter_commitments[voter] > daily_inflow:
            flagged_voters.insert(voter)

    // Track highest raw vote total for minimum weight calculation
    highest_raw_vote_total = max(highest_raw_vote_total, raw_total_votes)

Minimum Weight Calculation (Between Phases)

minimum_weight = 0
if flagged_voters.size() > 0 && highest_raw_vote_total > 0:
    total_vesting_shares = dynamic_global_properties.get_total_vesting_shares()
    if total_vesting_shares > 0:
        minimum_weight = (highest_raw_vote_total * HIVE_100_PERCENT) / total_vesting_shares

Phase 2: Reweighting (Only if Flagged Voters Exist)

if flagged_voters not empty:
    for each proposal:
        adjusted_total_votes = 0
        for each voter on proposal:
            if voter in flagged_voters:
                proportional_weight = min(1.0, daily_inflow / voter_commitment[voter])
                weight_multiplier = max(proportional_weight, minimum_weight)
                adjusted_total_votes += base_vote_power * weight_multiplier
            else:
                adjusted_total_votes += base_vote_power  // Full weight

Time Complexity Analysis

Current System

• Hourly Payment Cycle: O(V + P log P) where V = votes, P = proposals
• Per Vote Update: O(1)

Enhanced System

• Hourly Payment Cycle: O(V + U + P log P) where U = unique voters
• Per Vote Update: O(1) for normal cases, O(A) for commitment recalculation where A = voter's active proposals
• Best Case: No flagged voters → ~15% overhead
• Worst Case: All voters flagged → ~100% overhead (2× processing)

Key Optimization: Only voters exceeding daily inflow get reweighted, minimizing computational overhead for typical scenarios.

User Experience Impact

For Voters

• Transparency: dhf_total_daily_commitment field shows exact HBD/day commitment
• Accountability: Other users can see voting commitment levels
• Strategy: Voters must consider budget constraints when voting
• Flexibility: Can still vote for return proposal + regular proposals strategically

For Proposals

• Threshold Effect: Return proposal creates dynamic funding threshold, ensuring quorum for spending
• Competition: Proposals must compete not just for votes but for "budget space"
• Predictability: Clear relationship between votes and funding likelihood

Economic Implications

Incentive Alignment

• Budget Consciousness: Voters can't just vote for everything
• Prioritization: Forces voters to prioritize proposals
• Threshold Flexibility: Community can set funding thresholds via any large proposal (return, burn, AMM, etc.)
• Economic Reality: System recognizes that voting for more than daily inflow has the same economic effect regardless of destination
• Consensus Rewards: Higher participation automatically raises the minimum weight floor, protecting engaged voters
• Self-Regulating Thresholds: Active communities naturally develop higher return thresholds through participation

Attack Resistance

• Sybil Resistance: Multiple accounts don't help if they all exceed budget individually
• Plutocracy Mitigation: Even large stakeholders must budget their voting power

Market Dynamics

• Price Discovery: Large proposal vote levels indicate community's desired spending threshold
• Dynamic Equilibrium: System self-balances between spending and saving
• Flexible Thresholds: Community can choose different large proposals for different economic effects
• Commitment Capping: Prevents infinite commitment scenarios while preserving threshold-setting function
• Strategic Voting: The "one large proposal" rule allows voters to support multiple ambitious projects without being unduly penalized
• Participation-Driven Thresholds: Higher voting participation automatically raises effective return thresholds
• Consensus Protection: Widespread engagement prevents individual vote weight collapse, maintaining democratic legitimacy
• Adaptive Governance: System becomes more permissive (higher minimum weights) when community shows strong engagement

Migration and Compatibility

Hardfork Activation

• System remains backward compatible until hardfork activation
• New fields initialize to safe defaults (zero commitments, no weighting)

Legacy Behavior

// Use weighted calculation if hardfork is active
if( false ) // TODO: Replace with actual hardfork constant
{
    calculate_votes_with_weighting( proposals );
}
else
{
    // Legacy calculation for backwards compatibility
    calculate_votes_legacy( proposals );
}

Technical Implementation Details

Key Methods

update_daily_inflow_tracker()

• Called hourly during DHF funding recording
• Maintains rolling 24-hour window efficiently
• Updates cached daily total incrementally

calculate_votes_with_weighting()

• Two-phase algorithm for efficiency
• Only reprocesses when flagged voters exist
• Updates voter commitment stats

update_voter_dhf_commitment()

• Recalculates voter's total commitment
• Handles return proposal special case
• Updates account statistics

Data Consistency

• Atomic Updates: All vote changes and commitment updates in single database transaction
• Lazy Computation: Commitment only recalculated when votes change or during payment cycles
• Cache Coherence: Daily inflow total always reflects current 24-hour window

Testing and Validation

Unit Tests Required

1. Inflow Tracking: Verify 24-hour rolling window accuracy
2. Weight Calculation: Test various commitment/inflow ratios
3. Edge Cases: Zero inflow, single large voter, return proposal dynamics
4. Performance: Ensure acceptable overhead in worst-case scenarios

Integration Tests

1. End-to-End: Vote changes → commitment updates → payment calculations
2. Hardfork Transition: Legacy to enhanced system migration

Stress Tests

1. Large Voter Sets: Performance with thousands of voters
2. High Commitment Ratios: Many voters exceeding daily inflow

Risk Assessment

Implementation Risks

• Complexity Increase: Additional code paths and data structures
• Performance Impact: Up to 2× processing time in worst case
• Migration Issues: Database schema changes require careful handling

Economic Risks

• Behavioral Changes: May change voting behaviors
• Market Shocks: Sudden inflow changes could dramatically affect vote weights

Conclusion

The DHF vote weighting system introduces economic rationality to proposal voting while maintaining the democratic nature of the DHF. By limiting vote power based on budget commitment, it creates incentives for thoughtful voting while preserving the ability for the community to control funding allocation through the return proposal mechanism.

The consensus-driven minimum weight floor adds a crucial democratic safeguard: when communities show high engagement (measured by highest raw vote totals), the system automatically becomes more permissive, preventing vote weight collapse and maintaining governance legitimacy. This creates a virtuous cycle where:

1. High Participation → Higher minimum weight floors
2. Protected Vote Weights → Maintained democratic legitimacy
3. Adaptive Thresholds → System responds to community engagement levels
4. Sustainable Governance → Balance between budget constraints and participation incentives

The implementation balances computational efficiency with economic effectiveness, providing a robust foundation for sustainable DHF governance that scales with the platform's growth while rewarding active community participation.