Muchos sistemas de lotería cripto dicen ser justos. Muchos menos pueden demostrarlo.

La diferencia importa. Si dinero, recompensas, NFTs o acceso dependen de la selección de ganadores, el sistema debe resistir manipulación oculta.

Un sorteo no es justo porque el operador diga que lo es. Es justo solo cuando reglas, lógica de premios, conjunto de participantes y proceso de selección pueden revisarse de forma independiente.

Ese es el estándar para una lotería verificablemente justa en Web3.

Una lotería justa es más que un generador de números aleatorios conectado a un premio.

El sistema también necesita reglas fijas, lógica de premios protegida, inclusión transparente de participantes y una fuente aleatoria que no pueda controlarse silenciosamente. Si alguna pieza es débil, la lotería puede verse justa desde fuera y seguir siendo manipulable por debajo.

Muchos equipos fallan aquí. Se concentran en la aleatoriedad e ignoran el resto de la arquitectura.

La mayoría de loterías injustas no fallan por problemas criptográficos exóticos. Fallan por errores de diseño comunes.

Los patrones más frecuentes son:

• selección de ganador off-chain, donde los resultados se eligen en un servidor y se publican después;
• sorteos controlados por admin, donde roles privilegiados deciden qué entradas cuentan o cuándo corre el sorteo;
• reglas de premio mutables, que pueden cambiar después de iniciar la participación;
• listas de participantes ocultas o editables, que impiden verificar inclusión;
• aleatoriedad débil, como block timestamp, block hash, backend RNG o lógica de seed predecible.

Una lotería cripto verificablemente justa no es "usamos aleatoriedad". Es una base que incluye:

• reglas fijadas antes del sorteo;
• condiciones de premio que no pueden cambiarse en secreto;
• participantes elegibles determinados de forma transparente;
• fuente aleatoria sin control unilateral del operador;
• selección de ganador verificable de forma independiente.

La justicia debe cubrir el flujo completo. Empieza antes de solicitar aleatoriedad y continúa después de producir el valor aleatorio. Si la lógica alrededor es mutable u opaca, el sistema no es realmente verificablemente justo.

Una arquitectura confiable de lotería necesita cinco elementos funcionando juntos.

### 1. Reglas de participación fijas

El sistema debe definir quién es elegible, qué cuenta como entrada válida, cuándo abre la entrada y cuándo cierra. Estas reglas no deberían cambiar a mitad del evento.

### 2. Lógica de premios bloqueada

Los premios no deberían cambiar de forma oculta una vez iniciada la participación. Los usuarios deben entender qué está bloqueado, qué es condicional y qué puede cambiar todavía.

### 3. Conjunto de participantes transparente

Los usuarios deben poder entender qué entradas fueron incluidas. Si el conjunto final de participantes puede editarse silenciosamente, la aleatoriedad pierde sentido.

### 4. Aleatoriedad verificable

Una lotería con aleatoriedad verificable necesita una fuente impredecible antes del sorteo y verificable después. Por eso VRF encaja bien en este caso.

Si quieres ver cómo luce la verificación en el producto, abre Verificar resultados de sorteos.

### 5. Mapeo determinista del ganador

Incluso después de verificar la aleatoriedad, el sistema necesita una regla fija para elegir al ganador. Esa regla debe ser estable, clara y auditable.

"Aleatorio" y "justo" no son lo mismo. Una buena lotería necesita aleatoriedad impredecible antes del sorteo y verificable después.

Un backend RNG puede producir un valor que parece aleatorio, pero los usuarios siguen teniendo que confiar en el backend. Block timestamp y block hash parecen neutrales, pero suelen ser inputs débiles. VRF es más fuerte porque liga el output a una prueba que otros pueden comprobar.

1. Los usuarios entran antes de una fecha límite definida.
2. El conjunto de participantes se cierra en esa fecha.
3. Las condiciones del premio quedan fijas y no pueden cambiarse en secreto.
4. El sistema solicita aleatoriedad.
5. La respuesta de aleatoriedad se verifica.
6. Una regla fija deriva el ganador desde el output verificado.
7. Cualquiera puede inspeccionar el proceso y entender cómo se obtuvo el resultado.

VRF no resuelve la justicia por sí solo.

Un operador todavía puede romperla antes del sorteo excluyendo participantes, cambiando reglas de elegibilidad o alterando cómo se registran entradas. Un sistema sigue pudiendo ser injusto si los roles privilegiados son demasiado amplios y permiten intervenir en puntos sensibles.

Si el mapeo de premio puede cambiar después de recibir aleatoriedad, la justicia vuelve a colapsar. Si la UI oculta estado crítico del sistema, los usuarios no pueden evaluar la justicia aunque la mecánica sea sólida.

Una checklist corta ayuda más que afirmaciones abstractas. Si evalúas una lotería, raffle o giveaway, pregunta:

• ¿Puedo ver las reglas antes de que empiece el sorteo?
• ¿Está claro el deadline de entrada?
• ¿Pueden cambiarse o filtrarse entradas después del deadline?
• ¿El pool de premios está fijado?
• ¿La aleatoriedad es verificable?
• ¿Puedo ver cómo se calcula el ganador desde el resultado aleatorio?
• ¿El operador mantiene puntos ocultos de control?

Si las respuestas son vagas o requieren confiar en el backend, el sistema probablemente es más débil de lo que afirma.

Los sistemas centrados en justicia verificable combinan lógica determinista de smart contracts, pools de premio protegidos, superficies de control acotadas y aleatoriedad verificable.

Un stack como Supra Move junto con Supra dVRF puede soportar ese modelo al conectar ejecución determinista y aleatoriedad verificable.

La marca no es la prueba. La disciplina sí: reglas, manejo de premios y selección de ganadores quedan limitados por sistemas que los usuarios pueden inspeccionar.

• Abre Verificar resultados de sorteos para la ruta de usuario que compara un resultado con el registro on-chain en SupraScan.
• Abre Smart contracts para el mapa de paquetes del protocolo y sus invariantes de seguridad.
• Abre Preguntas frecuentes para un resumen aplicado más corto, sin teoría larga.

Una lotería verificablemente justa en Web3 no aparece solo por añadir aleatoriedad al final.

Necesita reglas claras de participación, inclusión transparente, lógica de premios protegida, aleatoriedad verificable y mapeo determinista de ganadores.

Si alguna de esas piezas queda opaca o controlada por operador, la justicia es más débil de lo que parece.

El estándar es verificación independiente, no un resultado que solo parece justo.

• La mayoría de loterías Web3 no son realmente justas si los usuarios no pueden verificar cómo se eligió al ganador.
• La justicia depende de reglas fijas, premios bloqueados, entradas transparentes, aleatoriedad verificable y mapeo determinista de ganador.
• VRF ayuda porque hace que la aleatoriedad sea verificable, no solo "aleatoria a la vista".
• VRF no basta si operadores aún pueden editar entradas, cambiar lógica de premio o conservar privilegios ocultos amplios.
• Una lotería confiable debe poder explicarse paso a paso y ser auditable por usuarios.