hhh01398 / hud

A Decentralized Autonomous Organization running a semi-direct democracy on a sybil-proof list of humans generated with Proof of Humanity

Humanity Unchained DAO

Humanity Unchained DAO is a Decentralized Autonomous Organization running a semi-direct democracy algorithm by which the citizens of the DAO can, either through a direct or a delegated vote, collectively interact with any smart contract. This allows the DAO to, for example, trade its own assets or upgrade its own smart contracts. The only prerequisite to join the DAO is proving to be a human. For that, citizens and delegates must first register in Proof of Humanity. This is in contrast to other tokens, cryptocurrency protocols or fiat currencies, which are based on some form of tokencracy or Proof of Wealth.

In addition, the DAO owns a reserve of its native token (HUD), of which the DAO has full control so that the community can, for example, vote to forcibly transfer or lock HUD.

The DAO uses the HUD reserve to pay for the services that the DAO needs to function or for any other purpose the DAO approves so. These services are:

1. Delegation: Delegates are rewarded with HUD for casting their vote on transation proposals. Anyone can become a delegate. Citizens can optionally choose what delegate they trust their vote to, but citizens can always cast their own vote which overrides the delegates' or appoint another delegate at anytime.

2. Execution: The proposals are blockchain transactions to be executed if approved by the DAO. The DAO rewards with HUD to whoever is willing to pay the gas fees needed for the transaction's execution.

Usage

A web frontend is deployed on https://app.humanityunchained.org. To use it, you need a Web3 wallet such as Metamask installed on your browser.

It is also possible to interact with the DAO by running the frontend on your machine or through the command line.

Humanity Unchained DAO's smart contracts currently run on the Polygon blockchain, mainnet for production, testnet Mumbai for test. For a technical description, please check the smart contract documentation.

Voting

We now describe Humanity Unchained DAO voting workflow from a user perspective.

Step 1: A transaction proposal is submitted for review

Any member of the DAO can submit a proposal to the DAO. This is done by submitting a transaction proposal to the Wallet contract. After that, members of the DAO can cast their votes on the proposal.

Currently, transaction proposals can only be submitted through the command line.

Step 2: The community votes on the transaction proposal

The DAO has a limited number of seats, which are occupied by the delegates who have been appointed by the largest number of citizens. The votes from delegates without a seat are not counted. The voting power of a seated delegate is proportional to the number of citizens that appointed him/her. For simplicity, the rule 1-citizen-1-vote is applied.

The voting process is divided into two phases: deliberation and revocation. Delegates cannot cast votes during the revocation period, only citizens. This guarantees citizens the chance to push back any decision from the delegates.

A delegate vote is always positive, that is, a no-vote is equivalent to vote against, whereas a citizen vote can be either positive or negative. The negative vote allows citizens to reject a proposal that was approved by the delegates during the deliberation phase.

Let us take the following example of a voting:

Citizens	c1,c2,c3,c4,c5,c6,c7,c8
Delegates	d1,d2,d3
Total citizen population	8
Number of seats	2
Delegate appointments	d1:c1,c2,c3,c4; d2:c4,c5; d3:c8
Delegates with seat	d1,d2
Delegate votes	d1,d2
Citizen votes	c1,c2,c4,c4,c5:nay; c6,c7,c8:yay
Voting threshold	50%

The number of delegated votes is:

4 (d1) + 2 (d2) = 6 votes

Since the total number of delegated votes compared to the citizen population surpasses the threshold, i.e. 6 / 8 > 50%, the delegate voting result is yay.

Now, the numbers of citizen votes are:

nay: 5 votes (c1,c2,c4,c4,c5)

yay: 3 votes (c6,c7,c8)

Since the voting threshold has been surpassed (i.e. 5 / 8 > 50%) and more citizens have voted nay than yay (i.e. 5 > 3), then the citizen voting result is nay.

Since the citizen vote result always overrides the delegate vote result, the final voting result is nay, and therefore the proposal's final status will be NotApproved. If not enough citizens had voted nay to surpass the voting threshold, the proposal's final status would have been Approved.

After the tally is ended, the final counting of votes and the execution of the transaction proposal (if approved), has to be triggered externally via a call to the smart contract. Anyone, not only DAO members, can do that call. The elapsed time between the tally end time and final counting should be, in theory, short as there is an economic incentive in HUD tokens for anyone to call the contract accordingly (see the smart contract documentation for more details). Therefore, it is important to note, even though DAO members cannot cast or change their votes after the tally end, citizens can change their delegation appointments at any time, which could affect the delegate voting result and thus the proposal's status during the period between the tally end time and the final counting.

Seated delegates are paid a number of tokens proportional to their voting power. This creates an incentive for delegates to compete for citizens’ trust.

Example:

Number of citizens	10
Number of delegates	3
Number of seats	2
Delegates with seat	A, B
Number of appointments of delegate A	5
Number of appointments of delegate B	3
Number of appointments of delegate C	2
Total delegation reward token rate	100 HUD/sec
Delegate A reward	100*5/10 = 50 HUD/sec
Delegate B reward	100*3/10 = 30 HUD/sec

Step 3: The transaction is approved and executed

If the final result of the voting is Approved, the transaction can now be executed. The Assembly contract implements an automatic pricing algorithm that pays an increasing number of HUD tokens over time to anyone willing to bear the transaction costs. The number of HUD is determined by the formula 2^(number of seconds passed since approval).

Example:

Number of blocks passed since approval	30
Average block duration	2 sec
Number of seconds passed since approval	30*2 = 60 sec
Reward	1.15292150460685E+018 ~= 1.15 HUD

Banning members

The DAO can, partially o completely, remove a member (commonly known as banning). This is done through the following 2 methods:

Distrust

Distrusted members can no longer apply for citizenship or delegation. Once an address is distrusted, it cannot be trusted back again.

Expel

The member is completely removed from the DAO, meaning he/she will be removed the status of citizenship and delegation, if applicable. Requirements to be expelled are either no longer having valid humanity proof or becoming distrusted first.

Creator role

By default, the address from which the Assembly contract is deployed is called the creator address. This creator role has the following two differences from the rest of members:

1. Registration in the PoH oracle is not mandatory. This allows the DAO creator to optionally be anonymous.

2. It is the only address allowed to execute transactions until a quorum of citizens is reached. This is intended to avoid the risk of centralization during the initial stages of the DAO, when the number of members is still small and there is a larger probability of critical votings being controled by a small minority with a common goal against the general purpose of the DAO. This limitation is no longer active once the quorum is reached (by default, 100 citizens).

The creator address can be changed by the creator itself. This can be used to, for example, disclose the real identity of the creator address owner or to effectively abandon the DAO.

Token

The total supply of HUD is fixed. The DAO owns a reserve of HUD tokens which are initially not in circulation. As time passes, the DAO will be spending the tokens from the reserve to pay for delegation, execution and referral rewards, or for any other purposes the DAO decides so.

Community

Discourse: https://forum.humanityunchained.org

Telegram: https://t.me/humanityunchaineddao

Twitter: https://twitter.com/UnchainedDAO

License

Humanity Unchained DAO is released under the MIT License.

Disclaimers

1. This project is for experimental purposes only. In no event shall the creators or members of the DAO be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, our of or in connection with this project.

2. Nothing contained in this project should be considered financial or investment advice.

3. HUD token holders must be warned that their HUD tokens can be locked or confiscated if the DAO approves so through a democratic voting.

hud's Issues

Emblems NFT

Emblems are a special type of NFT for the DAO to democratically assign roles to citizens and create task forces.

The characteristics of emblems are:

• Only the DAO can mint, burn and transfer the token.
• Only citizens of the DAO can receive the token.
• The receivers cannot transfer the token to anyone else but they can always refuse it by returning it to the DAO.
• The DAO can take back the token from the holder.

Wrong seat number on empty seat button

The button to seat on the next available seat does not show the correct number (in the screenshot, it should be #10, not #18, or show the rest of 8 seats which are missing).

Add button to update delegate appointment count and seat distribution

Improve delegate user experience adding a button that calls distributeDelegationReward
as explained in https://github.com/hhh01398/hud/blob/62a9c7bbcbe43ada103248b00a0fa82d888c8eb5/smart_contracts/README.md#delegation

Show new creator avatar and tag

Show PoH avatar pictures and nickname

Currently, the delegate's Proof of Humanity's avatar and nickname are now shown in the delegate's table:

It should be possible to fetch the profile's data of the delegate address from Proof of Humanity and display it in HUD's frontend.

Wrong tally dates and times

HUD token price

Currently, HUD token's price is not fetched, thus showing "n/a" both for the price and the market cap:

• Create a market for HUD/DAI pair in a DEX supporting Polygon.
• Fetch the price from the frontend using the DEX's API.

Add delegate page link

Add a link to a default's delegate website (e.g. https://forum.humanityunchained.org/t/<ETH_ADDRESS>).

Create PoH Oracle transaction proposals

Add favicon

Frontend ENS support

It should be possible for the frontend to support ENS names. For example:

• Look up for a member using his/her ENS, instead of the address.
• When referring other citizens.
• Translating the delegate's addresses into their ENS names.

Link to exchange is broken

Clicking on the icon to open a new browser window to the exchange site does not show the corresponding currency pair directly. User needs to manually input the token contract address, which is undesired.

Governed Non-Fungible Token

Use ENS to address the contracts and the front end

HUD's contracts should be addressable via ENS.
Also, it should be possible to load the dapp via https://humanityunchained.dao

Improving voting documentation

Fix responsive layout glitches

Fix visual glitches (e.g. button overflows) when transitioning from desktop to mobile views.

Support multiple transactions in a single voting

It should be possible for the DAO to create a proposal containing multiple transactions. After voting, if the proposal is approved, the transactions execute sequentially.

For example:

1. Create proposal containing [transaction1, transaction2, transaction3].
2. Create tally to vote proposal.
3. If tally is Approved, then execute the transactions in order (i.e. First transaction1, wait to be included in a block. Then transaction2, etc.)

This will avoid the DAO the hassle to vote on every transaction for a single purpose. E.g. deployment of a new feature involving more than one contract, update the state of many addresses in the oracle, create/transfer tokens to multiple addresses, etc.

Delegate Search panel does not work

In the Delegate Search panel, nothing happens after entering a valid delegate address and clicking on the button.

Smart contract audit

Add contract versioning

It should be possible for a contract to return the version number so other contracts can know. This is needed to manage codes updates in a more efficient way.

Prevent proposals not being approved due to lack of citizenship engagement

Problem:
In order for a proposal to be approved through delegated voting, the total number of positive delegated votes needs to be larger than a threshold percentage (by default, 50%) of the total citizen population. This may often not be the case because not enough citizens appoint seated delegates due to lack of engagement.

Solution:
To alleviate the problem, we propose to change the Assembly smart contract code so that, in order for a proposal to be approved through delegated voting, the total number of positive delegated votes needs to be larger than a threshold percentage of the citizen population represented by the seated delegates, instead of the total citizen population.

Add Odysee to social media logos

Staking contract