A verifiable, time-constrained, frictionless mechanism for Proof of Humanity renewals

A verifiable time-constrained, frictionless mechanism for Proof of Humanity renewals

NOTE 1: I am not an expert in blockchain technology, nor in cryptographic security. All the ideas described on this post are from what I have been learning from a Senior Programmer perspective. Feel free to double check and send any corrections that might need fixing.

NOTE 2: I will refer by Human(s) as the submitter of the evidence (whether its in the registration or the renewal process)


Proof of Humanity is slowly proving to be the solution for a sybil-resistant Identity protocol. I also believe that it solves the task that most governments fail of giving an Identity, which is a human right.

One task that has been tabled for months as the project moved forward, is the mechanism for renewing profiles.

There is yet not a well defined framework about how this process should be. On this post I intend to propose such mechanism to achieve this in a frictionless UX for Humans and Curators.

The proposal includes definitions on what counts as a valid renewal submission for Curators and Jurors, and some UI changes to align with this guidelines.

Before diving into the proposal, we need to better understand what we are trying to solve, and there are some ongoing discussions around several topics that need to be taken into consideration for a good mechanism; some are related to the Humans, some on the Curators/Challengers but in the end, it’s all about user experience on both ends.

What makes a good renewal process?

After several discussions with the community, some of the topics that need to be taken into consideration for achieving consensus on this matter are the following:

1. The human on the renewal video should be the same as the one on the registration video

It should be a no brainer that one of the most obvious things that the Curators should verify, is that the human on the renewal video is the same as the one on the registration submission. If this is not defined anywhere, it SHOULD be.

2. The phrase that should be said on the new renewal video

Achieving consensus on a single phrase should be relatively easy to define and can be further discussed.
Some suggested phrases can be seen on this HIP-32. Most of them make sense and its a matter for voting on a single one (or maybe even allow for multiple).

As a side note, not related to this post: Besides the proposals in english, there is this HIP related to using an alternate neutral language such as Esperanto

3. Enforce a verifiable and auditable Evidence on the time that the video was recorded

The video recording is currently the best evidence that a human uses to produce a valid registration and, their renewal.

This is what this post is all about and will tries to solve for.

Failure on implementing the right solution for this problem could allow for bad actors to take advantage.

One possible attack could be a case where a bad-actor records multiple videos of the same person at the same time, and then renew the registration, by using a different video every time, even if the human on the video has passed.

4. Curators/Challengers should have an easy way of verifying a renewal

The way Proof of Humanity deals with fake profiles is through “Curators” or “Challengers”. Anyone can participate on the task of curating the registry.
To do so, a Curator mines the entire registry looking for invalid profiles. Invalid meaning: The registration doesn’t follow the rules established by the DAO to be considered a legitimate registration, or includes some issues to be considered an invalid one.

For these Curators, the task is not easy, and the process of validating a profile should be as frictionless as possible.

5. Renewal process should be as similar as possible to the registration process (or easier if possible)

We’ve all been there. We’ve all put our ETH deposit to register the first time on Proof of Humanity, scared of losing our deposit.

To reduce friction,we should make the process of renewing a profile, as similar as possible to the registration, so that registrants know what to expect from the process, and how to act (since they’ve had a first experience with it).

It is not the objective of this post to expand on this, but I think some improvement can and should be done on this

The proposal

This post is not meant to be taken as an HIP (feel free to use as reference if it makes sense), but rather as an explanation on a possible mechanism that could solves 3 of the 5 definitions:

    1. Enforce a verifiable and auditable Evidence on the time the video was recorded
    1. Curators/Challengers should have an easy way of verifying a renewal
    1. Renewal process should be as similar as possible to the registration process

Cryptographic security

The underlying technology on which Proof of Humanity is built, a decentralized blockchain, has enough cryptographic mecanisms that can be securely used to generate auditable evidence.

We can take advantage of those mechanisms to play in our favor (our: us, humans).

The Validation Block

To make things short, the easiest way to do time validations with blockchain technology is by making use of the blocks’ timestamps.

Each block on the blockchain is created at a specific point in time, and that time gets registered on the blockchain.

This means that we can figure out at what time a specific block was created, just by fetching the block header (reading from the blockchain contract is gasless).

The block header contains specific structured information about each block INCLUDING the time it was created (See Block Header section on this post).

To refer to a block, we will use its ID which is a unique value representing the block on the blockchain.

I will refer to this as the “Validation Block” or “VB:slightly_smiling_face:

Building a cryptographic evidence for a moment in time

We need to make sure that a vide was recorder at most at a specific moment in time, but that “moment” needs to be correctly defined.

We will call it video expiration date.
Video expiration date is calculated from the moment that the validation block was generated, plus a time window.

Consensus should be reach on what the right time window should be. This is a key item since it could impact on the security of the registry. I will refer to this as “Time Window” or “TW:hourglass_flowing_sand:🪟

Renewal Video

When recording a registration video, we are required to show a sign with our wallet’s address (screen or paper).

If we asked the humans to do the same video, but now, besides displaying the address, to write down and display the ID of the Validation Block, we would impact on the UX for the Human by adding an extra step.

Display the signed hash

Cryptography to the rescue once again!

Using code on the FRONT END we can ask the user to sign the ID of the Validation Block. The signature, can later be used to infer the address of the signer and the integrity of the Validation Block ID without revealing their private key.

We then calculate the hash of the signature and use that as the value to display on the sign of the recorded video (screen or paper). All of this can be easily done through code, so there is no extra interaction from the Human rather than writing/copying/printing a specific value…

The hash could have the same length as the address which would mantain the amount of effort required by the Human, as when they registered.


The metadata for the renewal should be the same as the existing one for registration, but include 2 new fields called validation_block_id and validation_block_id_signature.

On these we will store the Validation Block ID and the signature that we can use later for validation of the data and the account.

Renewal Validation

With the updated metadata, anyone (including Curators) should have enough information to rebuild the hash of the signature and compare it to the one on the video.

Curators process

With this new implementation, Curators experience will be exactly the same as it is with registrations but in this case, the compared value will be hash of validation_block_signature, not the user address.
Curators shouldn’t care about the meaning, they should just care that the value is the same (as long as the UI is implemented to hold this mechanism).

Automated validations

*The remaining steps can AND SHOULD do the remaining validations by CODE on the FRONT END. Either to help curators or to warn submiters. *

Once the curator has done its job, we can automate the process of validating the cryptographic evidence, and finally check that the expiration date is greater than the submission date.

Since all the required data to make this validations are on the metadata, it can all be automated by code as follows:

Validate the signature from the metadata

We do this by infering the address of the signer using the validation_block_id and validation_block_signature fields. This is easily solvable by code since and address can be inferred from a signature.

If the resulting address is the same as the Human making the submission, we have crypotographic evidence that the wallet who signed the Validation Block is the same one making the submission on the video.

Since the hash on the video is valid, we can infer that the Block ID is the one used at the moment of recording the video.

If the resulting address is not the same as the submitter, the FRONT END should display a warning for challengers/curators. Not implementing this would require Curators to run the cryptographic proof manually, thus failing on the task of keeping UX the same

Time validation

Since all crypotographic evidence is validwe can now take care of looking to the time at which that block generated to make sure that the video was recorded within the expected time, from recording to submission.

We just search the block by it’s ID and make sure that the Expiration Date is greater than the Submission block date.

This also requires UI changes, or UX for Humans and Curators will be greatly impacted.


Most of the development details described are relativelly simple to implement thanks to libraries that implement all of cryptographic work (such as ethers.js).
A Curator or anyone could easily build a prototype and run validations on their own.

There is also some work to make some changes to the UI to display the values for Curators to compare and finally, some warnings that would automatically be shown if any or none of the automatic validations pass.

Who should do the UI Changes?

However easy it can be for a tech saavy to build a system that runs validations, the app.proofofhumanity.id webpage is the FRONT END application of the project as most humans and Curators use that.

To make this mechanism viable while mantaining the UX for both Humans and Curators, it’s recommended that a developer is paid to make the required changes.

Humans should not expect that a developer will help putting together these solutions out ot love. (Although it could happen)

What needs to be done on the UI?

For the Human submission the user could use the same page of the Registration, with wording changes and a label that allows them to get the latest block ID, sign it, hash it and display the hash to the human to set up tyhe sign for the video.

It is recommended that the UI includes a counter that displays for how long the hash will be valid (or the Expiration Date).

ALso, some warning can easily be implemented to avoid Humans making mistakes. All the cryptographic evidence should be done at the moment of submission to help Humans avoid making honest mistakes

Thats all but

A possibility for using the same mechanism for registration

As an extra idea, this could be very well used on registration too:

Human farming is an issue that has been seen on the Proof of Humanity registry. Since being registered allows you to accrue $UBI (which at the time of this writing is worth about 0.2 USD), there is an economic incentive on having as much accounts as possible.

Time-constrained registration videos could be a way to reduce this kind of issues.
If a person wants to farm 100 people, it should take considerable time to use the video with the Validation Block not expiring. The Time Window parameter should be fine tuned so that its not a problem for honest registrants to submit their video with time, but at the same time make it hard for bad actors to take advantage of this time window.

By having cryptographic evidence of when a video was recorded, we can build more constraints around the protocol.

Bye Bye


Sorry for the long post and redaction/grammaticar issues. I will be editing this as I reread it or get feedback.

1 Like

What a wonderful post @juanu, I’m in favour and whatever i can do for help count me in


Hi @juanu, thanks a lot for taking the time to think and write about this. I see some cool ideas here, but I think we should and can reduce the complexity without compromising security.

This is what comes to my mind:

  • We can avoid requesting the user to sign anything. I don’t think that adding the address info into the sign adds security to this process (maybe I’m not considering something?)
  • Including the block id into the metadata is dangerous for the user, because they can mix up a block id displayed on the sign with the block id attached (similar to people writing an address on a sign and then submitting their profile from another one).
  • Too many things to change on the UI.

What if we do something like this:

  • Require to show a sign with block hash and block timestamp (the hash could even be truncated without compromising security I think). Including the block timestamp is important, because it’s much easier for curators to copy it and look it up on Etherscan than the block hash.
  • As you said, the UI can add the expiration date of the sign to prevent users from using one that is no longer valid.
  • In order to help curators, add to the UI the smallest valid timestamp in profiles going through the renewal process.
  • Add a feature to the UI to easily see previous registration/renewals videos. It’s easy to edit static text on screens in a video. People could try to use the same video over and over again in future renewals by simply editing the sign.

I’d say up to one month old blocks should be ok. Or allow any block within the renewal period to make things simpler.


At first I thought about it too, but then thought that it might be a requirement to include the Human’s address such as in registration. Instead of adding 2 values (VB hash and address) generating a signed message would be fine.

However, we coul go for a hash of both , the VB hash and the address, which would produce a unique hash without having to use signatures. Less friction.

That is, of course, as long as we want to somehow use the Human’s address on renewal.

The idea is that the UI includes the block ID on the metadata upload not the human. The frictionless part relies on putting effort on the development rather than the security (we rely on Cryptography for that).

1 Like

Could something like “the block of midnight of the first day of the month” work?

Using a fixed time would be bad UX for different timezones.
The time window would avoid that issue.

Instead of every first of month we give a whole month
Id recommend going for less. Maybe 2 weeks tops, but could even be lower


The address is required to prevent someone from frontrunning a registration by submitting it himself. For renewal there isn’t such a requirement as if someone were to use someone else video in his renewal, jurors would be able to verify that the person on the renewal video matches the person on the current video.

On the time of validity, it needs to be high enough such that it doesn’t impact UX or lead challenges due to users using low gas settings and low enough such that someone cannot make a video for 2 renewals at the same time. So 1 month sounds good.


Makes sense! Then block hash should be good enough!

I agree, although it would open the window to renewing farmed profiles, it does make sense for people leaving pending TXs.