HIP: 57
title: Harberger Taxes Seat Bicameral Governance
author: @greenlucid
status: Phase 1
created: 2022-07-26
conflicts with: None
languages: EN
Simple Summary
Change governance to a bicameral system. Each chamber has 50% voting power. The Humanity Chamber uses 1-person-1-vote, the Stake Chamber uses 1-seat-1-vote, where each seat is an NFT allocated by means of Harberger Taxes.
Abstract
Harberger Taxes are an experimental pricing mechanism that involves price discovery and is ideal for limited, public resources, such as real estate. Due to its public goods funding applications, it can serve as a solution to both bring skin-in-the-game governance, and income for the DAO simultaneously. This proposal introduces a bicameral governance system that features a Humanity Chamber, with 1p1v, and a Stake Chamber, where each seat is allocated through Harberger Taxes.
Motivation
Pure 1p1v systems require no skin in the game. The registrants of a sybil resistant registry are not necesarily the consumers of the registry. One HIP, HIP-54 âDemocratic Heroesâ was an omen of the dangers that a DAO with voters with no skin in the game: bribing schemes to steal the treasury.
There are three ways to obtain new users:
- The registry is used by other applications, so it has use.
- Users are economically incentivized to register (UBI, airdropsâŚ).
- People are persuaded to register (family, friends, crypto-influencers and politics)
As the two main reasons to enter are not strong (UBI presents a, still decaying, 70$ yearly income, airdrops canât realistically occur without sybil resistance and the registry doesnât have enough attention), then the main way into the registry is getting told about it by its users. This encourages influence and popularity as the way to do governance. Popularity does not relate to good decisions. Technical issues cannot be understood by the majority of the voters, yet their criteria is what ultimately matters. Even if they trust technical people and delegate to them in those matters, then governance in technical matters is built on top of trust. This goes against the spirit of DAOs: for decentralization to be possible, trust should be minimized.
However, 1p1v does have benefits. First, it makes for an interesting political experiment to have 1p1v direct voting. It gives immediate, not negotiable utility to being a registered user. It encourages registered humans to participate and get informed about the protocol, knowing they donât need to be represented to play a role. Anyone can create HIPs, a mechanic that hasnât been abused so far. Lastly, it sets the grounds for a Network State.
Removing 1p1v entirely would remove these features and add barriers to participation. But, keeping the governance system purely 1p1v will result in the damaging results mentioned before. The best compromise is to reduce the voting power of 1p1v by half by creating a bichameral governance system, with a second chamber that features skin in the game.
The second issue is that the PoH DAO has a funding problem. All of the funds in its treasury were awarded by the Kleros Cooperative, and with current ETH prices, they barely cover the salary of a Product Manager and a Developer for one year. Governing is a privilege, not a burden, so having increased voting power should have a cost that ideally funds the DAO.
Regular skin-in-the-game governance solution comes in the form of token based governance. This tends to result in whales that, once they take control of the protocol, low liquidity makes for a very stale state of affairs in governance.
However, with the application of the recently created ERC-5320 Harberger Tax NFT, you could have a different type of skin-in-the-game governance. Make each seat in the chamber be an NFT subject to Harberger Taxes. For those unfamiliar with the concept, itâs a pricing mechanism that creates efficient allocation of limited resources. If Alice appraises a seat at 10, Bob can force her to sell it to him at 10. Also, Alice has to pay taxes on the seat, and they are dependant on the appraisal Alice makes. So she cannot appraise it too low or Bob will buy it from her, and she canât appraise it too high or she will have to pay too many taxes.
The reason this mechanism is interesting for governance experiments is, these taxes will be sent to the PoH treasury, and then they can be repurposed into funding the different needs of the DAO, mainly, offering good rewards for contributors, and supporting the currently main use case of the DAO, which is, the UBI token. Unlike regular token based governance, here, the âseat whalesâ will be providing a healthy source of income to the DAO, and thus, will have vested interests in making the DAO succeed while benefiting the users of the registry.
So, taking into account this desire to give skin in the game to governance, and being this potentially huge source of steady income, it can be reasonably concluded that this is a good idea.
Specification
Bichameral Governance
Deploy a new strategy that follows the following bichameral scheme:
There are two chambers, the Humanity Chamber and the Stake Chamber.
The total voting power of each Chamber is 50% of the total. Within each chamber, votes can dissent, and their different weights are translated onto the full result without removing minority options. To complete this definition, here are a few examples:
Humanity Chamber: 1 for A. Resolves as (A=50%, B=0%).
Stake Chamber: 1 for A, 3 for B. Resolves as (A=12.5%, B=37.5%).
Result: (A=62.5%, B=37.5%), A wins.
Humanity Chamber: 99 for A, 1 for B. Resolves as (A=49.5%, B=0.5%).
Stake Chamber: 1 for B. Resolves as (A=0%, B=50%).
Result: (A=49.5%, B=50.5%), B wins.
Humanity Chamber: 20 for A, 80 for B. Resolves as (A=10%, B=40%).
Stake Chamber: 7 for A, 3 for B. Resolves as (A=35%, B=15%).
Result: (A=45%, B=55%), B wins.
Note, for both chambers, the inactive population does not matter.
This is a TypeScript piece of code to convey the definition more clearly, for n Chambers:
/**
* @param chamberVotes: Matrix where each row is a chamber,
* and each chamber has the count of votes towards each option.
* @returns: weight of each option after the voting.
*/
const getWeights = (chamberVotes: number[][]): number[] => {
const chamberSums = chamberVotes
.map(row => row.reduce((sum, votes) => sum + votes, 0))
let optionWeights: number[] = []
const rows = chamberVotes.length
const optionCount = chamberVotes[0].length
for (let i = 0; i < optionCount; i++) {
let weightSum = 0
for (let j = 0; j < rows; j++) {
weightSum += (1 / rows) * chamberVotes[j][i] / chamberSums[j]
}
optionWeights.push(weightSum)
}
return optionWeights
}
Stake Chamber Contract
The Stake Chamber contract must be implemented in a secure way. It extends ERC-5320. The tax rate is a flat ratio of the valuation paid per year. Decreasing the valuation must be only be realized after a commit period, decreasing the valuation must not be allowed while buying. Excluding collect, interactions must revert if the funds available to pay for the taxes on the seat are not enough to go over the cooldown period. If there are not enough taxes to support the seat, the seat is then revoked. Specifically, these interactions are: buy, defund, changeValuation.
The contract must use a neutral and valuable ERC-20 currency, to buy the seats and pay taxes with.
More seats can be minted by the PoH Governor. Also, the PoH Governor can change the tokenURI of each seat, to customize them and give them an artsy, vanity aspect.
These are the parameters proposed for the contract:
currency: WETH
yearly tax rate: 20%
commit period: 3 months
number of seats: 10
This project is large scale:
- Ideally, would have the ERC-5320 to be set and accepted first.
- Making a secure, well tested Stake Chamber contract.
- Investigate Snapshot. Is it possible to make a strategy that implements the weights as described in the specification? Or would two different strategies be required?
- Adding future cosmetical value to the seats.
- Make a frontend to interact with it.
As such, it would require, at the very least, a dedicated developer to put in 1 or 2 months of work. So, this should ideally be funded through a grant. This can be discussed throrough this HIP.
Rationale
Why give each chamber equal voting weight?
Simplicity.
Doesnât this create plutocratic voting?
Every governance system is âplutocraticâ. Pure democracy is already plutocratic in itâs own right, as the biggest capital still holds great control over the organization. In this case, the capital is âsocial capitalâ, or the ability to organize and rally crowds around an option.
This governance system mixes both economical, skin-in-the-game voting, and social voting at the same time. Both ways of governance hold equal weight. Also, this Stake Chamber model creates a rent for the whole DAO to utilize, so, even if a whale sector took ahold of the protocol, they would also be forced to steadily fund the DAO.
Why use those parameters for the Stake Chamber contract?
Having the valuation be paid as taxes in 5 years, and committing 3 months of taxes (5%) at a minimum seem reasonable defaults. They provide good rate of income to the DAO, while not being extractive enough to be attractive to investors.
Why give cosmetics to the seat NFTs?
PoH is one of the largest active DAOs there are, and the NFTs are already valuable on their own right. Giving them cosmetic and vanity value can attract newcomers, build a culture around each seat, and give them visually pleasing content for ERC-721 compliant explorers. Example: label them as âIron Throneâ, âSilver Throneâ, etc.
Those cosmetics donât necessarily need to be launched along this HIP, as this is already a large scale project. So, giving the PoH Governor a way to edit the tokenURI in the future is desirable.
Isnât this too complicated development wise, can the DAO spare the resources needed to fund this?
Thatâs hard to tell, we can discuss it in this thread. I believe this would take 2-8 weeks of work for a single developer. If thereâs interest on this idea, the DAO should look for a developer to implement it.
As the discussion may reject the idea, or change the requirements, itâs not easy to make an estimate of the cost of the grant, but, assuming the cost is equal to 2 months of dev time (worst case), ~15k USD. If this proposal arrives at Phase 2, a grantee should be proposed.