Proof Of Humanity

HIP: 74
Title: A Peaceful Fork 🕊
Authors: clesaege.eth & santi.eth & Andrei
Status: Phase 3
Created: 2022-09-12

Simple Summary

This HIP sets the route to do a peaceful fork on the Proof of Humanity DAO and the protocol itself. The forks will be named:

• Open Proof of Humanity (Open-PoH): Developed and maintained by independent developers from the Proof of Humanity DAO and UBI.
• Proof of Humanity Origin (PoH-Origin): Developed and maintained by developers from the Proof of Humanity DAO and Cooperative Kleros as the original developers of the protocol.

This way the communities of Open-PoH and PoH-Origin respectively can part their ways amicably, each working on their own vision of how the protocol should evolve.

Abstract

The Proof of Humanity DAO consists of multiple resources that constitute its organization, governance methods, treasury and the protocol itself.

As the project prepares for the launch of Proof of Humanity v2 (PoHv2) in order to reduce costs and help onboard more users, this is also an opportunity for the community to fork the protocol and engage each side of the DAO to support their preferred version of the project.

In that regard, rather than having only one deployment of PoHv2, we will instead have two versions of the protocol each running on their own chains of preference moving forward while still recognizing as valid the list of humans verified before the fork on Proof of Humanity v1.

Since the community already began the development of some of the resources required for each side of the fork, we recommend to use those existing resources already created and if possible simply clarify to which side they belong.

Specification

The resources corresponding to v1 of Proof of Humanity will remain connected to that smart contract and project. These consist of the following list of resources and will not be modified in any way for the purposes of the fork.

Feature	Legacy Proof of Humanity
Protocol	Mainnet
Governor	0x327…CfdF
Snapshot	Require approval of both forks
Treasury	0x327…CfdF & MultiSig
Arbitrator	Requests frozen

Moving forward, two deployments of PoH v2 will be executed that will have backwards compatibility with the list of humans available on PoH v1.

Each side on PoH v2 will be able to make decisions without impacting the votes on the other fork respectively. The users verified on these new PoH v2 will have voting rights over the Snapshot page corresponding to each fork.

The forks will consist of the following resources:

Resource	PoH-Origin (Kleros Coop)	Open-PoH (UBI 💧)	Status
Landing	proofofhumanity.id	ubi.eth.limo	✅
PoH v2	🚨 Pending (multiplatform starting with Ethereum and Gnosis)	🚨 Pending (on Polygon)	👷‍♀️ *
User Interface	app.proofofhumanity.id	proofofhumanity.org	✅
Governor v2	🚨 Pending	🚨 Pending	👷‍
Snapshot v2	🚨 Pending	🚨 Pending	👷‍
Treasury v2	Same as Governor v2	Same as Governor v2	✅
Forum	gov.proofofhumanity.id	ubidao.social	✅
Twitter	@proofofhumanity	@pohdao	✅
Telegram	t.me/proofhumanity	t.me/proofofhumanityDAOen	✅
Github	Proof-Of-Humanity	OpenProofOfHumanity	✅

* 👷‍ Being Built.

Each side will focus on building a PoH ecosystem on a leading side-chain or Layer 2 rollup in order to complement the efforts of each other when it comes to onboarding new users.

Inheritance

Each fork will inherit the laws and approved proposals from the decisions voted on the Snapshot of v1. From the date of the fork onwards, their legal bodies will drift apart.

Each side is free to make and approve a constitution or a new legal body of which it would apply strictly to their fork. A constitution or new set of HIPs may override the impact of legacy HIPs on each fork but won’t modify the status quo of legislation on legacy PoH v1.

If this proposal is accepted, a transpartisan proposal to approve the constitutions will need to take place. It will consist of a unique snapshot vote where humans will be able to approve or reject only one constitution (so that one side cannot reject the constitution of the other). The fork will happen if both constitutions receive more approvals than rejections.

The funds held on the Governor and Gitcoin Multisig of PoH v1 will be split in half and allocated on each new Governor contract that will be used by each fork implementing PoH v2. Liabilities such as grant payment will also be split in half between both forks.

The funds currently available on the Gitcoin Multisig will be sent to the Governor on 0x327…CfdF before the fork happens in order to reduce the quantity of required transactions.

Implementation

Kleros will assist with the deployment of all the corresponding Proof of Humanity v2 smart contracts on each chain providing they don’t require any changes and the developers will be responsible for setting up all of the infrastructure that is necessary to interact with their side of fork.

All of the assets remaining on the Gitcoin Multisig will be transferred to the Governor of v1 available on 0x327…CfdF before sending funds to each fork.

Each fork will implement a Kleros Governor contract for their v2 on Mainnet. Each Governor will receive 50% of the funds coming from the Governor of v1 on 0x327…CfdF.

The new Governors for each v2 will be configured with the same parameters and settings currently set on the Governor of v1 but they will receive MetaEvidence that will connect each Governor of v2 to their respective Snapshot page.

The Snapshot pages of each fork will allow voting from humans that are considered registered from their side of the fork. It’s up to each fork to decide if they will consider the humans from v1 or the other fork.

On the main contract side, for mainnet, the v1 registrations requests will be frozen. Removals would be frozen too to solve the case of disagreement between forks about a removal of the profile (say one fork desires removal for a profile in the registry because of a different interpretation of sybil), at the expense of UX (in case user wants to deregister from both PoH). Freezing of both registration and removal requests is possible by making the arbitration fee an unpayable amount (by making the number of jurors the maximum number).

To facilitate a removal on a particular fork, either because of a request or bad vouching, the corresponding profile data must have been copied to the storage of that particular fork’s v2 contract (at the start of interaction with the profile) and somehow marked as removed.

This functionality has not been implemented yet as the current v2 contract does not copy storage of v1 contract (it only checks its data when needed). On agreement, the feature will be implemented. 👷‍

Once the fork is initiated, the v1 contract will be frozen and the v2 contracts of each fork need to be deployed with the corresponding parameters set (including the common address of v1 contract). There might be profiles that are in the pending state at the moment of fork (so it might take some days after the fork event for them to have a resolved state - None/Registered). The process of registration of these profiles should be finalized based on the old rules. Profiles in vouching state at the moment of fork will have to withdraw. At this point, the fork is agreed at the contract level.

Let there be peace and BUIDL 💪