feat(platform)!: masternode votes cost 80% less (PV14)

[QuantumExplorer]

Issue being fixed or feature implemented

Every masternode vote takes a fixed cost from the contest's prefunded balance, the fund the contenders pay when they apply. At 0.0001 Dash a vote, a DPNS contender's 0.1 Dash (protocol version 14) funds 1,000 votes. Each masternode may vote or change its vote up to 5 times per contest, so a well-attended contest can empty its fund; once it is empty, later votes are refused unpaid, and the outcome then depends partly on who voted first. This makes votes 80% cheaper at protocol version 14.

What was done?

contested_document_single_vote_cost is 2,000,000 credits (0.00002 Dash) in VOTE_RESOLUTION_FUND_FEES_VERSION2, the vote resolution fund schedule of FEE_VERSION3, which only protocol version 14 uses; it is amended in place, as the unreleased version's own schedule. Protocol versions 1 to 13 keep 10,000,000 credits (0.0001 Dash).

The cost still exceeds the masternode vote's minimum fee (100,000 credits), so the refusal of a vote on a fund below one vote's cost is unchanged. As before, the vote cost goes to the epoch's processing fee pool and whatever the votes leave of the fund is released as processing fees when the contest is cleaned up, so the contenders pay the same in total: only the split between vote time and clean-up moves.

Before (protocol version 14, a two-contender DPNS contest, each contender prefunding 0.1 Dash):

each vote: 10,000,000 credits from the fund
fund of 20,000,000,000 credits covers 2,000 votes; the 2,001st is refused unpaid

After:

each vote: 2,000,000 credits from the fund
the same fund covers 10,000 votes

In-place changes to shipped generations

None. VOTE_RESOLUTION_FUND_FEES_VERSION2 and FEE_VERSION3 are selected only by protocol version 14.

How Has This Been Tested?

• should_change_only_the_contested_document_and_once_per_identity_fees_at_protocol_14 (platform-version) now pins the new vote cost at 14 and the old one at every version from 1 to 13.
• The voting strategy test run_chain_with_voting_after_won_by_identity_with_specialized_funds_distribution pins the processing fees of an epoch with 5 votes plus the remainder of a 19-vote contest; it is re-pinned (19,972,000,000) and runs through a helper with a new _protocol_version_13 twin that keeps the old baseline (39,860,000,000: a 0.2 Dash fund per contender and 0.0001 Dash votes). Both runs cast the same votes.

Run locally:

• cargo test -p platform-version --lib: 22 passed.
• cargo test -p drive-abci --lib filtered to masternode_vote, contested, dpns, processor, execution_event, vote: 257 passed.
• cargo test -p drive-abci --test strategy_tests voting_tests: 8 passed (the 7 voting strategy tests and the new twin).
• cargo fmt --all; cargo clippy -p platform-version -p drive-abci --all-features --all-targets -- -D warnings: clean.

Breaking Changes

Consensus at protocol version 14 (unreleased): a masternode vote deducts 2,000,000 credits from the contest's fund instead of 10,000,000. Nothing changes for protocol versions 1 to 13.

Merging next to #4951: both edit VOTE_RESOLUTION_FUND_FEES_VERSION2 and the protocol version 14 fee test on adjacent lines, and #4951's new contest funds table in the fee overview gives the vote as 0.0001 Dash at 14; whichever merges second takes both amounts and updates that row to 0.00002 Dash.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed (no document states the vote cost on this branch)
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request (no structure change)

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · 9c7033f

• Bots — coderabbitai not yet · thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed once the bots are done
• Within your 5 open PRs
• Build running
• Approvals — you own every area touched; none needed

When every box is checked the PR Hygiene check passes and this can merge.

[coderabbitai]

Warning

Review limit reached

Next included review available in 28 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: dashpay/platform/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 55bace33-e5cc-48db-9948-a76d8fe44c13

📥 Commits

Reviewing files that changed from the base of the PR and between 458bebb and 9c7033f.

📒 Files selected for processing (3)

• packages/rs-drive-abci/tests/strategy_tests/test_cases/voting_tests.rs
• packages/rs-platform-version/src/version/fee/vote_resolution_fund_fees/v2.rs
• packages/rs-platform-version/src/version/v14.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

🕓 Queued for automated review — 8th in line, estimated start in ~1.5 h (commit 9c7033f)
Estimated review time once started: ~25 min (two-phase automated review; median of recent runs).

• Request priority review — click to move this review to the front of the queue.

[QuantumExplorer]

Approved