Completely gasless crowdfund

Would it be technically feasible to implement a completely gasless crowdfund?

Current behaviour:

  • A new human can choose crowdfund for 100% of the deposit.
  • But they still have to pay the gas for a transaction.

Proposed behaviour:

  • Any human can submit a profile and just sign the transaction (similar to gasless vouch), essentially costing them nothing
  • When a person paying the crowdfund deposit submits they include the signature from before (paying the gas to interact with the contract).


  • This change would allow people to join PoH and earn $UBI without any starting capital (through altruistic crowdfunders)
  • Without this someone must first obtain enough ETH to cover the profile submission. IMO this is unnecessary when dealing with something that should be a basic right.
  • We are in the unique opportunity to open crypto up to the world, through $UBI people can participate in the DeFi space as long as they are human - even if they don’t own a dollar.

How would you prevent a bot from applying for free and losing someone’s crowdfund? Wouldn’t it lower the barrier so anyone can make multiple submissions?

I don’t understand. If I was the crowdfunder I still choose who I want to fund. The only difference I propose is to remove the need for the first (gas) contract interaction.

It is true you could end with many more “spam” submissions. But because the reference to the data is not on-chain yet (its basically all on the centralized server), you could delete it after some determined time.


Adding on to this issue. I recently crowdfunded someone who needed it. They still had to pay the gas to submit, then I had to pay the gas to crowdfund. Seems it would have been better if they could upload to IPFS & sign, and then I could submit / crowdfund deposit in one contract interaction.


Yes. This would be a great improvement. When I have crowdfunded, I send 0.22 ETH to the person so him/her can pay the entire thing and have some extra for cashing out. But it is not efficient, nor scalable. I support that this needs to be implemented.

I like the idea, but it’s not possible with the current contract (which is not upgradeable).

1 Like

so a possible solution would be to fork the current contract code, and add that upgrade, then replace the current contract ?
or how this can be implemented ?

Love this porposal! An impotant detail related to this is that according to some research I did looking at etherscan of submitted profiles, it is much cheaper to submit a profile with 0% deposit than when people choose self fund 100%. So I think it evens out with the crowdfund gas fee.

You could fork the code, add the upgrade and deploy the new contract. The problem is that this newly deployed contract won’t have any profiles. Migrating the profiles using governance is possible, but at a huge cost. At current prices, migrating 5k profiles would cost ~150k usd (this is a very rough estimate with eth=4k and gas=100).

1 Like

There is a better way to do without forking or deploying a new PoH code. It works like this:

Registering to proof of humanity requires a vouch from a human already in the registry. But then, how did the first human ever make it into the list?

In the inception of of PoH, there was something called a seeding event, where the first humans were centrally added to the registry after a manual curation. This was possible via a function that bypass the normal protocol: addSubmissionManually. The caveat is that since the event, PoH became decentralized and so this function is “turned off” and the request-challenge protocol is the only way to enter the registry.


We can write an arbitrable governor to be the new governor of PoH. This contract will have the same request-challenge protocol built-in, except that when a submission resolves, it will use the governance-powered function of PoH to add and remove profiles.


  • This will allow someone with 0 ETH to make it into the list and start accruing UBI (i.e. crowfund everything inlcuding gas fees).
  • As ClĂ©ment pointed out elsewhere, this function can be used to enforce submissions that made it into the list in a L2 via merkle proofs.


  • Governance is a slippery slope and a very dangerous part of any project. Adding features to the governor means increasing the attack surface so we must tread carefully, not just to avoid code powered exploits but also populists leveraging the democratic nature of PoH governance and charisma to do bad things to the protocol.