本文件的ä¸ć–‡çż»čŻ‘ | TraducciĂłn de este documento al español
The source code and technical documentation is in the app directory.
We are Humanity Unchained DAO (or HUD for short), a Decentralized Autonomous Organization (DAO) and alternative to the governance monopoly imposed globally through states, transnational institutions and technolgy overlords that enslaves humanity.
We are building a new civilization based on the principle of unconditional respect for the consent of human beings. Under this principle, any system of government, such as constitutions and laws, monetary policies, justice systems, electoral systems, supranational treaties, religious organizations, etc. is ilegitimate as long as the human beings under the mandate of the system had not given their consent to abide by the rules of the system.
In contrast, HUD members voluntarily promise to uphold the Constitution and the Additional Rules (this very document). These two documents lay the foundation to build a new framework for coexistence that allows human beings to create and choose the systems of government, in the form of a federation of DAOs, that they want to live under. These DAOs may be diverse in purpose, internal rules, and in the way they are organized socially, economically, etc. They may also share resources in the physical world, such as territories.
In the case of dispute among members and/or DAOs, a trial by jury may be held by all HUD members or, optionally, their appointed delegates, whose ruling must be abode, esentially functioning as a semi-direct democracy on the blockchain. In addition, this voting system allows HUD to interact with other smart contracts on-chain to, for example, collectively manage the DAO's finances or to update its smart contract code according to the latest version of the Additional Rules approved democratically by the DAO.
To ensure the 1-human-1-vote principle, HUD uses the identity registration system Proof of Humanitythat proves that all members are living human beings and that there are no duplicate identities. Optionally, members can create an anonymous identity derived from their non-anonymous Proof of Humanity identity using the zero-knowledge proof cryptography from SISMO.
The jury's ruling may be enforced through fines, revoking roles or banning members. HUD has two types of tokens: a fungible token (the HUD token), which is used to fuel HUD's economy, and a special type of Non-Fungible Token called emblem, which is used to appoint roles. Emblems whose usage is linked to one or more territories are called clusters. HUD has full control over these tokens, and may even confiscate them if the jury determines so.
HUD's Constitution cannot be changed, which allows individuals and DAOs joining HUD benefit from HUD's perpetual constitutional guarantee of the unconditional respect for the consent of human beings and the ability to request a trial by jury in the case of a dispute. Individuals can join HUD by simply registering their identity and signing a promise to uphold the Constitution and the Additional Rules with the digital wallet associated to their identity. DAOs can integrate with HUD by assigning emblems to their users and making them required to be held to belong to the community or to perform internal roles. For critical roles that require placing trust in a third party, the emblem holder must deposit HUD tokens as collateral.
The DAO shall be called Humanity Unchained DAO.
The DAO's logo will be a simplified figure of two human forms embracing.
The primary official language of the DAO shall be English.
The secondary official languages of the DAO shall be Mandarin Chinese and Spanish.
Translations of the original sources in the primary language to the secondary languages may be used for the Constitution, the Additional Rules and the user interface of the application, to the extent possible. In the event of any discrepancy between the different language versions, the primary official language version shall always prevail.
Jury's judgments shall prevail over specifications. Specifications shall prevail over the code.
There shall be an app which implements the requirements established in the Constitution and the Additional Rules.
The app should be implemented using a technology that is publicly accesible, secure, verifiable and tamper-proof. The DAO may decide whether or not to upgrade the app to use more advanced technologies as the state-of-the-art of decentralized technologies evolves.
The app shall be distributed under the MIT license.
The app shall be a Web3 app built on Ethereum smart contracts and be deployed on the Polygon blockchain.
The smart contracts shall be modifiable only by the DAO.
The smart contract addresses shall be resolved from the Ethereum Name Service.
The app shall provide a way for members to create and manage their digital identity through an Identity Management System.
The Identity Management System shall be sybil attack resistant.
It shall be possible to integrate other identity systems with the app.
Members may register one non-anonymous HUD identity and one anonymous HUD identity, and freely choose which one to use anytime.
The app shall support Proof of Humanity as non-anonymous identity system. A system shall be created to sync the Proof of Humanity smart contract on the Ethereum mainnet to Polygon chain.
The app shall support SISMO's Proof of Humanity badge as anonymous identity system.
Identity's metadata shall be stored on IPFS.
The default IPFS gateway shall be nftstorage.link.
All members of the DAO must possess a valid registered identity on the Identity Management System.
In order to become a member, applicants shall sign with their wallets a promise to uphold the constitution and the current and future versions of the Additional Rules for the duration of their membership.
Members may cancel their membership at anytime.
Members may appoint a delegate, who shall cast votes on behalf of the members.
Delegates shall not require being members.
There shall be 20 seats.
Delegates with the most number of appointed members may take a seat.
The way to count votes shall be 1-human-1-vote.
There shall be two types of votes: member votes and delegate votes.
The vote sign can be "Yes", "No" and "Blank".
Votings on proposals that require on-chain transactions shall be done on-chain. The rest of proposals may be voted off-chain.
Distrusted addresses shall not be allowed to vote.
It shall be possible to carry out votings off-chain on Snapshot.
The app shall implement an on-chain voting system that allows members of the DAO to collectively interact with any smart contract running on the same chain. The system shall support the submission of proposals containing transactions which shall be executed if a majority of the members so approve.
Anyone except for distrusted addresses may submit proposals.
Proposals may contain any number of transactions.
It shall be possible to attach metadata to proposals and transactions.
Only members may initiate votings on the submitted proposals.
The creation of votings shall be free of charge.
Every voting shall be divided into two: a voting by the delegates and a voting by the members. If the results of votings are in conflict (e.g. the delegates approve the proposal and members do not approve, or vice versa), then the member's always overrides the delegate's. Furthermore, the voting by the members shall always finish after the voting by the delegates.
Voting by the delegates: The proposal shall be approved by the delegates of the DAO if the sum of all delegate votes of seated delegates who voted "yes" is greater than the total number of members who appointed a seated delegated multiplied by a certain threshold.
Example:
Delegate D1 (seated) represents members M1 and M2. Delegate D2 (seated) represents members M3 and M4. Delegate D3 (seated) represents member M5. Delegate D4 (non-seated) represents member M6. Threshold: 50%.
D1 and D4 vote "no". D2 and D3 vote "yes".
Total number of members who appointed a seated delegated: 5. Delegated "yes" votes: 2 + 1 = 3.
3 > 5 * 50% => The proposal is approved by the delegates.
Voting by the members: The proposal shall be approved or rejected by the members of the DAO if the number of members who voted "yes" or the number of members votes who voted "no", respectively, is larger than the total number of members multiplied by a certain theshold.
Example:
Members: M1, M2, M3, M4, M5 and M6.
M1, M2, M3 and M4 vote "no". M5 votes "sĂ". M6 votes "blank". Threshold: 50%.
4 > 6 * 50% => The proposal is rejected by the members.
The DAO can set the value of the voting thresholds, or otherwise it shall be 50% by default.
The transactions of approved proposals may be executed by anyone.
Transaction executors may be rewarded with HUD tokens.
Seated delegates who have abstained from voting on the last voting shall be distrusted. Members who have abstained from voting on the last two votings and have not appointed a delegate shall be distrusted.
Votings shall start on Monday 00:00 CET and shall end on Saturday 23:59 CET of the same week.
A minimum number of registered members (also known as Member Quorum) is needed for a proposal to executed if approved. Until the Quorum is reached, only the Guidemother shall be able to execute approved proposals.
The quorum shall be at least 1000 members.
Until the quorum has been reached, the guidemother may be able modify or re-deploy the smart contracts, but for the sole purposes of fixing bugs or to lower the number of quorum members required.
The guidemother shall be removed automatically once the quorum has been reached.
The DAO shall own a wallet to store any kind of token on the chain.
Transfers out of the wallet may be possible only through an on-chain voting approved by the DAO.
DAO shall have a fungible token, which will be called HUD token.
The token shall implement the ERC-777 standard.
The token shall have the following features:
Symbol: HUD Name: Humanity Unchained DAO Decimals: 18
The DAO shall have full control of the token, such as the ability to mint, destroy, seize and forcibly transfer tokens, and to prevent specific addresses to receive or send tokens.
The total token supply shall be 21 million.
The DAO shall own an initial reserve of 1 million HUD tokens. The DAO shall decide what to do with the reserve through on-chain votings.
Every new member who has been referred by another member shall be eligible for a reward in HUD tokens. Members may only be referred once.
Members who refer new members shall be eligible for a reward in HUD tokens per each new referred member. Members may refer to an unlimited amount of new members.
The sum of the HUD tokens to be rewarded to the referrer member and to the referred member shall not surpass the amount given by the following formula:
50 / (2 ^ floor(memberCount / 200000))
that is:
| Member range | Number of HUD tokens |
|---|---|
| x < 200000 | 50 |
| 200000 <= x < 400000 | 25 |
| 400000 <= x < 600000 | 12.5 |
| 600000 <= x < 800000 | 6.25 |
| ... | ... |
and so on until the total limit of tokens rewarded is reached.
The total number of rewarded HUD tokens shall no surpass 20 million.
Note: In this section, the term "DAO" is used to refer either to the organization in general or to any smart contract of to the app.
The app shall implement a special type of non-fungible token, called Emblem, that provides the DAO with a flexible way to build and manage organizational structures.
The Emblems implementation shall follow the ERC-1155 Multi Token Standard.
Anyone shall be able to create an emblem and to do it for free, unless the DAO assigns a fee for the creation of new emblems or for the minting of tokens of a particular emblem. Such fee shall be charged in HUD tokens.
The emblem's creator shall have the emblem's admin role by default. Such role mat be transferred to another address by the DAO and the admin itself.
The emblem's URI, where the token's metadata is stored, shall be changed by the DAO only. Should the emblem's admin or holders want to change the URI, a proposal shall be submitted to the DAO for on-chain voting.
The DAO or the emblem's admin may set a mandatory deposit in HUD tokens required to hold the emblem. Addresses who do not deposit the amount shall not be able to receive emblem's tokens. If the address already holds tokens, the holder shall not be able to make use of the tokens until the full required amount is deposited.
Emblems may be non-transferable (also known as soulbound), meaning that the owner cannot transfer them out to another address, unless the owner is the emblem's admin or the DAO. This feature is set upon the emblem's creation and only the DAO can change it.
Accounts may or may not own more than one token of a specific emblem unless the owner is the emblem's admin or the DAO. This feature is set upon the emblem's creation and only the DAO can change it.
The DAO and the admin can forcefully transfer emblem tokens from any address except from a DAO's. This includes destroying tokens (which effectively is equivalent to transfer them to the zero address).
Emblems may be verified, which means that they are legitimized by the DAO. The DAO may curate an emblem through on-chain voting. Emblems created by the DAO shall be curated by default.
The DAO's members, delegates and seats shall be emblems, whose admin is the DAO, they shall be non-transferable and each address may only own one token.
The membership emblem's minting fee and deposit required shall be zero.
The delegate's emblem minting fee shall be zero. The deposit required shall be 100 HUD tokens.
The seat's emblem minting fee shall be zero. The deposit required shall be 200 HUD tokens.
The DAO shall have full control of the emblem tokens, such as the ability to mint, destroy and forcibly transfer tokens, and to prevent specific addresses to receive or send tokens.
It shall be possible to integrate emblems in other DAOs, such as e.g. those created using Aragon.
A special type of emblem that is linked to one or more territories shall be called a "cluster". The spatial coordinates of the territories will be stored as part of the token metadata.
Clusters' territories shall be represented graphically in a map on the app.
The DAO shall appoint members to be responsible for managing off-chain services through the creation and transfer of emblems created for such purpose. Such emblems shall be referred as admin emblems.
An admin emblem shall be created for each of the following external services:
| Service | URI |
|---|---|
| Web domain and server | https://humanityunchained.org |
| Subgraph | https://api.thegraph.com/subgraphs/name/hhh01398/hud-subgraph-test-1 |
| ENS | humanityunchaineddao.eth |
| Github | https://github.com/hhh01398/hud2 |
| https://twitter.com/UnchainedDAO | |
| Telegram | https://t.me/humanityunchaineddao |
| Forum | https://forum.humanityunchained.org |
Admin emblems shall be transferable only by the DAO.
A member may only hold one admin emblem for each off-chain service.
A deposit of 5000 HUD tokens is needed to hold an admin emblem.
The emblem holders shall not be distrusted members.
The Guidemother shall handover the credentials of any off-chain service in her possesion to the corresponding emblem holders before the Quorum is reached.
The App shall provide a way for the DAO to keep a record of expelled members.
The App shall provide a way for the DAO to keep a record of addresses who have been reprimanded for breaching any rules. Such addresses shall be referred as distrusted.
The DAO may set what addresses are distrust through an on-chain voting for any reason the DAO deems appropriate.
Distrusted members may be expelled.
Distrusted addresses may be trusted back by the DAO through an on-chain voting.
Distrusted addresses shall be unable to receive or send HUD tokens or emblems.
Distrusted addresses or ex-members may not become members or delegates.
Distrusted delegates cannot claim a seat. Distrusted seated delegates can keep their seats.
Distrusted addresses shall not be able to submit proposals or start votings.
Seated delegates shall be automatically distrusted if they abstain to vote in the latest on-chain voting.
Members shall be automatically distrusted if they abstain in the two latest on-chain votings and have no appointed delegate.
Distrusted addresses may not be emblem administrators.
The Additional Rules document shall be version-controlled.
New versions of the Additional Rules document shall effectively come into force once the DAO smart contract is updated through an on-chain voting with the reference (e.g. an URI to a specific Git commit) to the new Additional Rules document.