Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quadratic Voting: Burning DEV #28

Open
defi-er opened this issue Oct 23, 2020 · 3 comments
Open

Quadratic Voting: Burning DEV #28

defi-er opened this issue Oct 23, 2020 · 3 comments
Labels
core Core features of Dev Protocol policy

Comments

@defi-er
Copy link

defi-er commented Oct 23, 2020

Proposal

Allow voters in Dev Protocol's Quadratic voting process to buy additional votes by sending DEV to a smart contract which then returns votes and burns received DEV.

image

Overview

Dev Protocol currently uses Quadratic voting for governance. Under Quadratic voting individuals buy votes for their preferred alternative, paying the square of the number of votes purchased. Quadratic cost uniquely makes the marginal cost proportional to votes purchased, encouraging voting proportional to the value and thus maximizing welfare.

Incentives

  1. Large DEV holders will burn DEV to receive additional votes which should encourage them to maximize the protocol's value in order to receive a return on investment of their burned DEV. This will diminish attacks through governance.

  2. Dev Protocol creates another token sink which reduces the effects of inflation.

Technical Implementation

Escrow contract that holds non-transferrable voting rights. Users transfer DEV to receive voting rights. Escrow then burns DEV received. Interface shows user how many additional votes they'll receive for DEV sent.

@defi-er defi-er added the core Core features of Dev Protocol label Oct 23, 2020
@aggre
Copy link
Member

aggre commented Oct 28, 2020

@defi-er Great proposals. I will share my ideas here.


Stake Voting Rights(Normal/Traditional Voting): A voting right proportional to the number of stakes, with each Property getting a different vote so that a staker can participate in a secondary vote by staking to more than one Property. iTokens(#12, #12 (comment)) can replace these rights in the future.

Preferred Voting Rights: Voting rights are enhanced by burning tokens. That is a unique voting right per user account, and multiple preferred voting rights cannot be exercised. The priority rate increases proportionally to the number of staking rewards. This is because it should always have more impact than Stake Voting Rights. The number of staking rewards dependent is referenced by multiplying the number of rewards earnable per block by 10^18. Technically, no conversion is required, as the tokens' unit is always multiplied by 10^18 in smart contracts. If the number of rewards is 0.000000000000000001 per block per staking, the priority rate is 100x. For your information, the ratio is 1,676,850x at the current rate.

@defi-er
Copy link
Author

defi-er commented Oct 28, 2020

Preferred voting rights seems like an overly complicated solution to tackle governance. This would also entail changing the governance model away from Quadratic voting.

I'm much more inclined to favor voting rights being tied to a wallet address. Quadratic voting is preferable. Each user has same amount of votes, but can buy votes. If a users' DEV is locked up on Stakes Social, and there's no DEV in their wallet, then UI will ask for tx confirmation to withdraw the staked DEV and burn it.

@aggre
Copy link
Member

aggre commented Oct 29, 2020

@defi-er Can I rephrase your proposal as follows?

Alice is staking 100 DEV. Bob is staking 300 DEV.
Alice and Bob both have 1 voting right. That rights are the same universal voting rights for all stakers; one voting right is lost with one vote.
Alice gains an additional 30 voting rights by burning 30 DEV.

@aggre aggre added the policy label Oct 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core features of Dev Protocol policy
Projects
None yet
Development

No branches or pull requests

2 participants