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_ledgeramount 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_commitmentfield 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
- Inflow Tracking: Verify 24-hour rolling window accuracy
- Weight Calculation: Test various commitment/inflow ratios
- Edge Cases: Zero inflow, single large voter, return proposal dynamics
- Performance: Ensure acceptable overhead in worst-case scenarios
Integration Tests
- End-to-End: Vote changes → commitment updates → payment calculations
- Hardfork Transition: Legacy to enhanced system migration
Stress Tests
- Large Voter Sets: Performance with thousands of voters
- 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:
- High Participation → Higher minimum weight floors
- Protected Vote Weights → Maintained democratic legitimacy
- Adaptive Thresholds → System responds to community engagement levels
- 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.
