PIVX decentralised voting: CDG proposal review, SHIELD privacy and test results
I’m sharing an AI-assisted technical review of the four proposals in the PIVX CDG repository, assessed against today’s PIVX code.
The attached document asks what would actually be required to build permissionless voting that includes SHIELD holders, allows anyone to verify the outcome, and executes approved treasury payments without a privileged governance gate.
It compares Tango, Weighted Voting, Votes-For-All and Pivmetheus, identifies implementation gaps, and sets out a development sequence, estimated effort and consensus requirements.
What was reviewed and tested
The source review covered governance eligibility, ballot serialization, budget finalisation, treasury payment validation, Sapling proofs and nullifiers, wallet witnesses, staking authority and spork controls.
Core source revision bd8a672 was inspected. Runtime testing used the official PIVX v5.6.1 release, with tests from its matching source revision, on an isolated regtest network using dummy funds.
The completed runs included 40 selected unit cases and seven multi-node functional tests, all passing:
An additional two-wallet exercise successfully shielded funds, transferred shielded funds to another wallet, and confirmed that an ordinary wallet was rejected by the existing masternode-only voting command.
These were tests of existing PIVX behaviour. CDG contains proposal documents; no new CDG voting implementation or private voting circuit was built or tested. A source-build attempt stopped because required development dependencies were unavailable, so the execution results apply to the official release binary.
The main privacy finding
SHIELD payment privacy does not automatically provide private voting.
A voting protocol must prove that someone controls eligible funds that were unspent at a particular snapshot, assign the correct weight, and prevent duplicate voting without exposing their ordinary payment nullifier.
Proving that a note exists in the Sapling commitment tree is insufficient: spent notes remain in that tree. Publishing exact voting weights can also reveal information about holdings, even if the owner’s identity is hidden.
None of the four proposals supplies a complete solution to those requirements.
How the proposals compare
What should happen next
The first funded milestone should be an 8–12 week specification and cryptographic prototype demonstrating eligibility, historical unspentness, conserved weight and duplicate prevention, with measured performance and adversarial tests.
After that come chain-state integration, wallet support, tallying, treasury execution, removal of legacy governance overrides, independent reviews and public testnet cycles.
The report estimates 12–18 months for private eligibility with anonymous public choices. Permanently secret ballots without a special decryption committee remain a research-dependent requirement, with a provisional 18–30+ month horizon.
Binding treasury execution would require a coordinated consensus upgrade, likely a hard fork. A development funding vote would not itself activate the protocol.
This is a feasibility and architecture assessment supported by selected execution tests, rather than a complete security certification. Equal-per-PIV voting also remains wealth-weighted; custody, lending and underlying consensus assumptions still matter.
Feedback is particularly welcome on eligibility rules, the required level of ballot secrecy, and whether the proposed first milestone is a useful basis for community discussion.
I’m sharing an AI-assisted technical review of the four proposals in the PIVX CDG repository, assessed against today’s PIVX code.
The attached document asks what would actually be required to build permissionless voting that includes SHIELD holders, allows anyone to verify the outcome, and executes approved treasury payments without a privileged governance gate.
It compares Tango, Weighted Voting, Votes-For-All and Pivmetheus, identifies implementation gaps, and sets out a development sequence, estimated effort and consensus requirements.
What was reviewed and tested
The source review covered governance eligibility, ballot serialization, budget finalisation, treasury payment validation, Sapling proofs and nullifiers, wallet witnesses, staking authority and spork controls.
Core source revision bd8a672 was inspected. Runtime testing used the official PIVX v5.6.1 release, with tests from its matching source revision, on an isolated regtest network using dummy funds.
The completed runs included 40 selected unit cases and seven multi-node functional tests, all passing:
| Functional test | Area exercised |
|---|---|
| rpc_budget.py | Existing budget RPC behaviour |
| sapling_wallet_nullifiers.py | Shielded wallet nullifier handling |
| sapling_malleable_sigs.py | Shielded signature validation |
| sapling_wallet_anchorfork.py | Sapling anchors and fork handling |
| tiertwo_governance_reorg.py | Governance behaviour across reorganisations |
| tiertwo_governance_invalid_budget.py | Rejection of invalid budget finalisation |
| mining_pos_coldStaking.py | Cold-staking authority, spending restrictions and block validation |
These were tests of existing PIVX behaviour. CDG contains proposal documents; no new CDG voting implementation or private voting circuit was built or tested. A source-build attempt stopped because required development dependencies were unavailable, so the execution results apply to the official release binary.
The main privacy finding
SHIELD payment privacy does not automatically provide private voting.
A voting protocol must prove that someone controls eligible funds that were unspent at a particular snapshot, assign the correct weight, and prevent duplicate voting without exposing their ordinary payment nullifier.
Proving that a note exists in the Sapling commitment tree is insufficient: spent notes remain in that tree. Publishing exact voting weights can also reveal information about holdings, even if the owner’s identity is hidden.
None of the four proposals supplies a complete solution to those requirements.
How the proposals compare
- Tango offers relatively simple, reward-derived entitlement. However, it excludes passive holders and entirely shielded holdings under current staking rules. It also needs careful separation of actual rewards from returned staking principal.
- Weighted Voting broadens participation but deliberately gives different influence per coin. Private classification and grouping add considerable complexity, and some constitutional conditions require external information or interpretation.
- Votes-For-All provides the strongest starting principle: equal weight per PIV. Its proposed separate voting chain introduces additional security and result-verification requirements.
- Pivmetheus gives serious attention to minority protection and concentration, but its interacting layers, historical weights and account-splitting incentives need substantial modelling and validation.
What should happen next
The first funded milestone should be an 8–12 week specification and cryptographic prototype demonstrating eligibility, historical unspentness, conserved weight and duplicate prevention, with measured performance and adversarial tests.
After that come chain-state integration, wallet support, tallying, treasury execution, removal of legacy governance overrides, independent reviews and public testnet cycles.
The report estimates 12–18 months for private eligibility with anonymous public choices. Permanently secret ballots without a special decryption committee remain a research-dependent requirement, with a provisional 18–30+ month horizon.
Binding treasury execution would require a coordinated consensus upgrade, likely a hard fork. A development funding vote would not itself activate the protocol.
This is a feasibility and architecture assessment supported by selected execution tests, rather than a complete security certification. Equal-per-PIV voting also remains wealth-weighted; custody, lending and underlying consensus assumptions still matter.
Feedback is particularly welcome on eligibility rules, the required level of ballot secrecy, and whether the proposed first milestone is a useful basis for community discussion.
