[Phase 3] HIP-72: Grant to fund a PoH airdrop solution

HIP: 72
title: Grant to fund a PoH airdrop solution
author: green
status: Phase-3
created: 2022-06-29
conflicts with: None
languages: EN

Simple summary

Launch a grant to build an app to ease the process of airdropping to humans registered in PoH.

Abstract

Airdrops are the currently most used feature of PoH and it would be in the general interest of the DAO to provide an easy way for philanthropists to airdrop tokens to its humans. This HIP sets up a grant to incentivize building such a tool.

Motivation

On making KIP-51 , we came to realization that there is no such thing as a tool to airdrop to humans registered in PoH. Since the most interested party in the existence of such a tool is PoH DAO, and not Kleros DAO, it makes sense for PoH DAO to be the one that spends the resources needed for it to exist.

Other DAOs that are interested in performing sybil resistant airdrops could use it as an easy default allocation. Then, in the future we might see projects such as Optimism liberally drop tokens to PoH.

Specification

Upon completion of the PoH airdrop tool, send 3 ETH from the PoH treasury to the grantee, forer.eth. If PoH treasury does not contain enough funds but they are deposited in vaults generating yield (such as the UBI Burner ), then this amount will be withdrawn from the vaults and then sent to forer.eth.

The tool will work in the following way:

Contract

• Anyone can create an airdrop. They pass a token, an amount for the whole airdrop, the merkle root, a JSON file uploaded to ipfs with info to allow for redemptions.

Subgraph

• Keeps track of airdrops and redemptions. Allows fetching information quickly from the frontend.

Frontend

• If the user connects with a wallet with pending airdrops, they’ll be notified and will be able to trigger the transactions needed to withdraw them.
• It provides a way for donors to create an airdrop to humans easily. Donors can create airdrops just by going through a form, and sending ERC20 tokens to the contract. The frontend will then fetch all eligible recipients, create a merkle tree, upload it to IPFS and then finally create the airdrop in the contract.

Completion

Completion (the criteria for delivering the grant) is defined as:

• supporting these features described above.
• open source project.
• deploying it publicly, at the latest, 60 days after this HIP is accepted.
• accessible through a frontend, that will be accessible through a domain. (either web2 or ENS are fine).
• will require low, or no maintenance in regards to the features described above.
• contains, in the frontend, a mention of proof of humanity that reads “Commissioned by Proof of Humanity”.

Rationale

Why is there no maintenance requirement?

Originally, maintenance was part of the grant, and the bill of costs was greater. But there were a few edge cases around it:

• If everything is delivered at once upon completion, you’re trusting on the grantee to deliver on the maintenance.
• If the grant is delivered after the maintenance period, then the grantee will probably be less interested.

Also, the grant amount would also had been higher. So, instead, the project will just be built with low or no-maintenance requirements.

Why not support NFTs

It would increase the complexity severely to handle both ERC20 and NFT in the same tool. Merkle airdrop tools benefit from fungibility. To reduce the time needed to ship the tool, reducing features was chosen as the approach.

Why self-select as grantee

Since I made the proposal in June 29 (3 months ago), no one offered to take the grant. So, to avoid the proposal from getting stale, I advanced it to Phase 2 through selecting myself.

Why 3 ETH

It was approximated through the following bill of costs:

• 0.5 ETH: ideation, design of the tool and stack.
• 1 ETH: smart contract
• 0.5 ETH: subgraph
• 1 ETH: frontend