Practical Implementation of One UTXO/One Vote Governance Voting in Crypto Asset Systems

Introduction

Dynamo is a proposed crypto asset system which allows for autonomous , on chain governance via a 1 UTXO/1 Vote mechanism. Here I propose a method to track UTXO voting on a per proposal basis with minimal impact to system security and performance.

Design Objectives

• Only allow a UTXO to vote once per proposal
• A UTXO created after the proposal voting period has started cannot vote
• A UTXO which has been transferred after voting cannot vote
• A UTXO should be able to vote on more than one active proposal
• System performance and security should not be impacted
• Miners/stakers should be incentivized to process UTXO votes

Smart Contract Design

Each proposal shall consist of N smart contracts, each representing a vote choice. For example, a proposal may be a YES/NO choice, e.g. “Proposal #37: Change the coin logo from green to red”. Contracts would then be created for “Change #37 — YES” and “Change #37 — NO”. Holders of UTXO would then send their UTXO to one of the two contracts to indicate their choice. Any number of choice contracts may be created for any given proposal.

In order to vote, each holder “spends” their UTXO to the chosen contract. The contract validates that the UTXO has not previously been spent on this proposal(by searching the UTXO hash history) and validates that the UTXO was created before the contract was created. This ensures that a UTXO cannot be split after vote initiation and then voted twice.

Once the UTXO input has passed validation, the smart contract records the vote by simple addition to a counter of the number of UTXO spent. The contract then creates a new UTXO, payable to the senders public hash, in the same amount that was input.

Miners and stakers are rewarded from coinbase transactions for the mining/staking of blocks containing execution of the smart contracts and the underlying transactions. The cost of the contract execution is born by the community developer fund, such that there is no explicit “charge” to the UTXO sender for voting. This is done at the time of mining/staking by reallocation of the developer coinbase UTXO allotment to miners and stakers.

This design requires two important components. First, the contract must have an embedded identifier that links it to the proposal. Second the contract must have the ability to search the history of the blockchain for all UTXO transactions which have been paid to any contract with the proposal ID. For performance reasons, this must be kept in memory in the full node. Only active proposals need to be maintained, so the memory footprint can be minimized. I propose a B+ tree of order 16 for this purpose, although this will be subject to revision based on performance testing.

The entire process of smart contract validation is secured by my previously proposed hybrid POW/POS security model which makes both a 51% attack and a nothing at stake attack financially unfeasible.

One small drawback of this design is that if a holder intends to issue multiple votes for the same proposal, they must first “queue up” UTXO in the amounts they wish to split. For example, if Proposal #37 says “Change the coin logo to (pick one or more): green, yellow, red, blue”. If a holder wants to vote 10 coins to green and 5 coins to blue they must create those UTXO amounts before the vote period because UTXO created after the vote period cannot be used to vote. Likewise, any holder that wishes to vote their coins must do so before transferring them to someone else, for the same reason. Finally, coins mined after the vote period begins cannot vote.

Conclusion

This discussion presents a practical implementation for a 1 UTXO / 1 vote mechanism which can be created such that security and performance are not impacted. Further the design guarantees that users cannot cheat the system by voting more than once per proposal. A concrete implementation of this procedure will be created in the Dynamo asset system.