**MEJORAS POLICY PoH**

**Proof of Humanity Registry Policy**

The “Proof of Humanity” curated registry of humans is a system combining social verification
with video submission to create a Sybil-proof list of humans.
A common problem on the internet and in the crypto-ecosystem is the fact that users can
generally create multiple accounts using different pseudonyms or addresses to receive rewards
multiple times, bias votes, write multiple fake reviews, etc… This issue can be solved through
the use of a Sybil-resistant identity system such as “Proof of Humanity”.
This policy serves one main purpose:
Ensuring each entry in this registry represents a unique, living, existing human being.
Acceptance Criteria
The criteria to be met for a submission to be accepted in this registry are the following:
● The submitter must not be already registered in the curated list.
○ For example, a submitter cannot register himself a second time in the list by
using another name.
● The submitter must be an existing human being.
○ For example, a submitter cannot be registered if it is a computer-generated
person or avatar as it would not enable the submitter to prove it is not already
registered in the list.
● The submitter must be alive.
○ For example, a submitter cannot be registered if he is deceased.
● The submitter must provide all the elements required for the submission.
○ For example, a submitter cannot be registered if his video submission does not
display his Ethereum address.
Elements Required for Submission
Any submitter registering to the list has to provide evidence that he is compliant with the
acceptance criteria. The required evidence is to be decided through Kleros governance and can
be updated to take into account technological evolutions and the evolution of attack vectors.
List of current required/optional elements and submission rules
1. Submitter Name - Required
The submitter is composed of:
a. Name under which the submitter is known (any UTF8 characters) - Required
b. First Name (basic latin) - Optional
c. Last Name (basic latin) - Optional
- Field a. information: The submitter can choose any name he is usually
referred by. This can be an official name (Federico Ast), a use name
(Satoshi Nakamoto), a religious/monarch name (Benedict XVI), a name
with the original non-latin characters (小明), a name with anglicised
characters (Xiao Ming), a name with an initialized middle name (George
P. Burdell), a stage name (Bob Dylan), a political name (Nicolas Sarkozy).
- Fields b. and c. may be void if the submitter does not have it. Note that
middle names are not required.
- Fields b. and c. using characters other than basic latin must be
transcribed to basic latin.
2. Front-facing Submitter Picture - Required
- The picture should include the face of the submitter facing the camera and the
facial features must be visible.
- Face should not be covered under heavy make-up, large piercings or
masks hindering the visibility of facial features. Headcover not covering
the internal region of the face is acceptable (For example, a hijab is
acceptable for a submitter but a niqab is not).
- It can include items worn daily (ex: headscarf, turban, wig, light makeup,
etc) provided they do not violate the previous point. It cannot include
special items worn only on special occasions that can, voluntarily or
involuntarily, distract humans or algorithms from being able to detect
identical faces.
3. Short bio - Optional
- A set of words describing the submitter (For example: “Cypherpunk”, “Painting
Enthusiast”, “Solidity Developer”, etc…)
- This field may be left empty.
4. Video of the submitter displaying a sign with his Ethereum address - Required
- The sign should display in a readable manner the full Ethereum address of the
submitter (No ENS; no ellipsis). The sign can be a screen. The submitter must
show the sign in the right orientation to be read on the video. A single one of the
following errors occurring once will be tolerated in the displayed address:
- omitted character: a character is omitted from the address (e.g. “abcd” →
“abd”).
- mistaken character: a different character has been written in place of the
one expected in that position (e.g. “abcd” → “ab9d”).
- swapped adjacent characters: two characters adjacent to each other have
been swapped (e.g. “abcd” → “acbd”, but not “adcb”).
- additional character: an additional character has been inserted anywhere
in the address (e.g. “abcd” → “abc0d”).
- The submitter must say « I certify that I am a real human and that I am not
already registered in this registry ». Submitters should speak in their normal voice
and should not attempt mimicking someone else’s voice. Speaking before or after
the required sentence is acceptable. Poor English accents, mispronunciations,
and the switch or oversight of words in that sentence are not grounds for
rejections.
- Video submissions must follow all of the following requirements:
* at most 2 minutes long,
* in the video/webm, video/MP4, video/avi or video/mov format,
* vertical (portrait), horizontal (landscape) or square,
and follow these minimum size requirements:
* Minimum height: equal to or higher than 352 pixels
* Minimum width: equal to or higher than 352 pixels
- Lighting conditions and recording device quality should be sufficient to discern
facial features and characters composing the Ethereum address displayed.
- The quality of the audio should be high enough such that the speaker can be
understood clearly. Small background noises are acceptable as long as they
don’t prevent a clear understanding of the speaker.
- The face of the submitter should follow the requirements of section 2.
None of the provided information should be purposely offensive or hateful (ex: a painted Hindu
swastika is acceptable for picture 2., even if it can be offensive to some people unfamiliar with
its meaning, but « I hate Jews » as a bio is not).
Challenge Types
In order to curate this registry, any user can challenge submissions in “Pending Registration”
state that they deem non-compliant with the above-cited acceptance criteria. A user challenging
a pending submission needs to specify a challenge type. A challenge can be rejected if the
challenge type specified is incorrect.
The challenges types are the following:
● Duplicate: The submitter is already registered in the list.
○ The challenger has to point to the identity already registered or to a duplicate
submission. If someone tries to register multiple times simultaneously, all
submissions are to be rejected.
● Does not exist: The submitter does not exist.
○ The challenger can demonstrate that the submitter is not an existing human
being.
● Incorrect submission: The elements required for the submission are incorrect.
○ This kind of challenge does not claim that the submitter is trying an attack, but
just that the submission does not comply with the submission rules.
● Deceased: The submitter has existed but does not exist anymore.
○ The challenger can provide evidence that the submitter is dead such as a death
certificate, an obituary, or public records.
○ The challenged submitter can provide a video of himself reading a recent block
hash. Submitters not able to give recent proof of life are to be considered
deceased.
Removal Request
A request to remove a submission in “Registered” state from the list can be made at any time by
anyone submitting a deposit.
The removal requester has to either:
● Provide evidence that the above-cited acceptance criteria are not fulfilled by the
submission.
○ Example: Send the following removal request
Evidence name: This user video is a deep-fake
Evidence description: You will find in the attached file an analysis report
proving that this video is deep-faked.
● Or provide evidence that he is the submitter and wants to voluntarily remove his
submission.
○ Example 1: Send a removal request from the same address as the submitter.
■ Evidence Name: Self-removal of submission
■ Evidence Description: I am the submitter as proven by my address and I
want to remove this submission.
○ Example 2: Send a removal request from a different address than the submitter.
■ Evidence Name: Self-removal of submission
■ Evidence Description: I am the submitter and I want to remove this
submission. The video attached is a recording of myself saying the
sentence “I want to remove my own submission from the Proof of
Humanity registry.”

ESPAÑOL

Política de Registro de Prueba de Humanidad
El registro curado de humanos "Prueba de humanidad" es un sistema que combina la verificación social
con envío de video para crear una lista de humanos a prueba de Sybil.
Un problema común en Internet y en el criptoecosistema es el hecho de que los usuarios pueden
generalmente crea múltiples cuentas usando diferentes seudónimos o direcciones para recibir recompensas
varias veces, sesgar votos, escribir múltiples críticas falsas, etc. Este problema se puede resolver a través de
el uso de un sistema de identidad resistente a Sybil como "Prueba de humanidad".
Esta política tiene un propósito principal:
Garantizar que cada entrada en este registro represente a un ser humano único, vivo y existente.
Criterios de aceptación
Los criterios que se deben cumplir para que una presentación sea aceptada en este registro son los siguientes:
● El remitente no debe estar ya registrado en la lista seleccionada.
○ Por ejemplo, un remitente no puede registrarse por segunda vez en la lista
utilizando otro nombre.
● El remitente debe ser un ser humano existente.
○ Por ejemplo, un remitente no se puede registrar si es un mensaje generado por computadora.
persona o avatar, ya que no permitiría que el remitente demuestre que aún no lo es
registrado en la lista.
● El remitente debe estar vivo.
○ Por ejemplo, un remitente no puede registrarse si ha fallecido.
● El remitente debe proporcionar todos los elementos necesarios para la presentación.
○ Por ejemplo, un remitente no puede registrarse si su envío de video no
mostrar su dirección de Ethereum.
Elementos necesarios para la presentación
Cualquier remitente que se registre en la lista debe proporcionar evidencia de que cumple con los
criterios de aceptación. La evidencia requerida se decidirá a través del gobierno de Kleros y puede
actualizarse para tener en cuenta la evolución tecnológica y la evolución de los vectores de ataque.
Lista de elementos requeridos/opcionales actuales y reglas de presentación
Nombre del remitente: obligatorio
El remitente está compuesto por:
una. Nombre con el que se conoce al remitente (cualquier carácter UTF8): obligatorio
b. Nombre (latín básico) - Opcional
C. Apellido (latín básico) - Opcional
Campo A. información: El remitente puede elegir cualquier nombre que normalmente
referido por. Puede ser un nombre oficial (Federico Ast), un nombre de uso
(Satoshi Nakamoto), un nombre religioso/monarca (Benedicto XVI), un nombre
con los caracteres no latinos originales (小明), un nombre con
caracteres (Xiao Ming), un nombre con un segundo nombre inicializado (George
P. Burdell), un nombre artístico (Bob Dylan), un nombre político (Nicolas Sarkozy).
Campos B. y C. puede ser nulo si el remitente no lo tiene. Tenga en cuenta que
los segundos nombres no son obligatorios.
Campos B. y C. el uso de caracteres distintos al latín básico debe ser
transcrito al latín básico.
Foto de remitente de frente - Obligatorio
La imagen debe incluir la cara del remitente frente a la cámara y el
los rasgos faciales deben ser visibles.
La cara no debe estar cubierta con mucho maquillaje, perforaciones grandes o
máscaras que dificultan la visibilidad de los rasgos faciales. Cubrecabezas que no cubre
la región interna de la cara es aceptable (por ejemplo, un hiyab es
aceptable para un remitente, pero un niqab no lo es).
Puede incluir prendas que se usan a diario (p. ej., pañuelo para la cabeza, turbante, peluca, maquillaje ligero,
etc) siempre que no infrinjan el punto anterior. no puede incluir
artículos especiales usados ​​sólo en ocasiones especiales que pueden, voluntaria o
involuntariamente, distraer a los humanos o a los algoritmos para que no puedan detectar
caras idénticas.
Breve biografía - Opcional
Un conjunto de palabras que describen al remitente (por ejemplo: "Cypherpunk", "Painting
Entusiasta”, “Desarrollador de Solidez”, etc…)
Este campo puede dejarse vacío.
Video del remitente que muestra un cartel con su dirección de Ethereum - Obligatorio
El letrero debe mostrar de manera legible la dirección completa de Ethereum del
remitente (sin ENS; sin puntos suspensivos). El signo puede ser una pantalla. El remitente debe
muestre el letrero en la orientación correcta para que se lea en el video. Uno solo de los
Los siguientes errores que ocurran una vez serán tolerados en la dirección mostrada:
carácter omitido: se omite un carácter de la dirección (por ejemplo, “abcd” →
“abd”).
carácter erróneo: se ha escrito un carácter diferente en lugar del
uno esperado en esa posición (por ejemplo, "abcd" → "ab9d").
personajes adyacentes intercambiados: dos personajes adyacentes entre sí tienen
intercambiado (por ejemplo, “abcd” → “acbd”, pero no “adcb”).
carácter adicional: se ha insertado un carácter adicional en cualquier lugar
en la dirección (por ejemplo, “abcd” → “abc0d”).
El remitente debe decir «Certifico que soy un ser humano real y que no lo soy
ya inscrito en este registro». Los remitentes deben hablar con su voz normal.
y no debe intentar imitar la voz de otra persona. Hablar antes o después
la oración requerida es aceptable. Pobres acentos ingleses, malas pronunciaciones,
y el cambio o el descuido de las palabras en esa oración no son motivo para
rechazos
Las presentaciones de video deben cumplir con todos los siguientes requisitos:
como máximo 2 minutos de duración,
en formato video/webm, video/MP4, video/avi o video/mov,
vertical (retrato), horizontal (paisaje) o cuadrado,
y siga estos requisitos de tamaño mínimo:
Altura mínima: igual o superior a 352 píxeles
Ancho mínimo: igual o superior a 352 píxeles
Las condiciones de iluminación y la calidad del dispositivo de grabación deben ser suficientes para discernir
rasgos faciales y personajes que componen la dirección de Ethereum que se muestra.
La calidad del audio debe ser lo suficientemente alta como para que el altavoz pueda ser
entendido claramente. Los pequeños ruidos de fondo son aceptables siempre que
no impida una comprensión clara del hablante.
El rostro del remitente debe seguir los requisitos del apartado 2.
Ninguna de la información proporcionada debe ser deliberadamente ofensiva u odiosa (por ejemplo, un hindú pintado
la esvástica es aceptable para la imagen 2, incluso si puede ser ofensivo para algunas personas que no están familiarizadas con
su significado, pero "Odio a los judíos" como una biografía no lo es).
Tipos de desafíos
Para curar este registro, cualquier usuario puede cuestionar los envíos en "Registro pendiente"declaran que consideran que no cumplen con los criterios de aceptación antes citados. Un usuario desafiante
un envío pendiente debe especificar un tipo de desafío. Una recusación puede ser rechazada si el
el tipo de desafío especificado es incorrecto.
Los tipos de desafíos son los siguientes:
● Duplicado: El remitente ya está registrado en la lista.
○ El retador tiene que señalar la identidad ya registrada o un duplicado
envío. Si alguien intenta registrarse varias veces al mismo tiempo, todos
las presentaciones deben ser rechazadas.
● No existe: el remitente no existe.
○ El retador puede demostrar que el remitente no es un humano existente
siendo.
● Envío incorrecto: Los elementos requeridos para el envío son incorrectos.
○ Este tipo de desafío no afirma que el remitente está intentando un ataque, pero
solo que la presentación no cumple con las reglas de presentación.
● Fallecido: el remitente ha existido pero ya no existe.
○ El retador puede proporcionar evidencia de que el remitente está muerto, como una muerte
certificado, un obituario o registros públicos.
○ El remitente desafiado puede proporcionar un video de sí mismo leyendo un bloque reciente
picadillo. Los remitentes que no puedan dar una prueba de vida reciente deben ser considerados
fallecido.
Solicitud de eliminación
Una solicitud para eliminar un envío en estado "Registrado" de la lista se puede hacer en cualquier momento por
cualquier persona que envíe un depósito.
El solicitante de eliminación tiene que:
● Proporcionar evidencia de que los criterios de aceptación mencionados anteriormente no se cumplen por parte del
envío.
○ Ejemplo: enviar la siguiente solicitud de eliminación
Nombre de la evidencia: Este video de usuario es un deep-fake
Descripción de la evidencia: En el archivo adjunto encontrará un informe de análisis
demostrando que este video es profundamente falso.
● O proporcionar evidencia de que él es el remitente y quiere eliminar voluntariamente su
envío.
○ Ejemplo 1: envíe una solicitud de eliminación desde la misma dirección que el remitente.
■ Nombre de la prueba: autoeliminación de la presentación
■ Descripción de la evidencia: Soy el remitente como lo demuestra mi dirección y
desea eliminar este envío.
○ Ejemplo 2: enviar una solicitud de eliminación desde una dirección diferente a la del remitente.
■ Nombre de la prueba: autoeliminación de la presentación
■ Descripción de la evidencia: soy el remitente y quiero eliminar esta
envío. El video adjunto es una grabación de mí mismo diciendo el
oración "Quiero eliminar mi propia presentación de la Prueba de
registro de la humanidad.”

**PROPUESTAS:**

1. Agregar que los jurados no deben decidir en vacíos legales (por ahora el general court policy dicen que tienen que votar con el espiritu de la ley, excepto que la subcorte o el documento diga lo contrario)

2. Agregar que ante la duda, la disputa debe resolverse para el lado del submitter

3. Agregar que debe haber presunción de inocencia antes de todo

4. Agregar que el "burden of proof" debe estar siempre del lado del remover/challenger

5. Agregar que x personas deben tener sus pedidos de removal denegados

6. Agregar que el objetivo del registro no es mantener el 1person 1vote

7. Agregar que es aceptable / no es aceptable compartir cuentas

8. Proteger personas que tienen custodia compartida de cuentas

9. Formalizar una definicion de farmer / sockpuppet, y agregarlo como challenge criteria bajo alguno de los criterios existente