Zanzibar de IoTeX: ¿quién calcula la recompensa del votante?
Las transferencias de recompensas ya dejaban un registro en IoTeX. Zanzibar incorpora su cálculo y distribución a las reglas de la cadena, con instantáneas, condiciones de participación y trabajo repartido entre bloques.
Ilustración conceptual generada con IA: dos personas reproducen la misma asignación a partir de una referencia fija. Las fichas representan un cálculo compartido, no pagos reales ni recompensas iguales para todos.
Puntos clave
- IoTeXScan fecha el bloque de activación de Zanzibar, 53.533.081, a las 02:28:37 UTC del 19 de octubre de 2026. Las 02:00 anunciadas eran una estimación.
- IIP-59 incorpora a las reglas del protocolo el cálculo y la distribución de recompensas de los votantes de delegados participantes. Hermes ya registraba sus transferencias on-chain.
- La configuración publicada usa eras de 24 épocas y un presupuesto de 256 votantes por bloque. La migración, los porcentajes y los destinos de pago siguen sujetos a condiciones.
Cronología de los hechos
La nota oficial sustituye la estimación del 8 de octubre por el bloque 53.533.081 y una estimación para el 19 de octubre.
Se publica v2.5.1 sin cambiar la altura de Zanzibar ni añadir otra bifurcación.
IoTeXScan y los RPC públicos de la Fundación coinciden en el bloque 53.533.081 a las 02:28:37 UTC.
Antes de que la recompensa llegue al monedero
Una recompensa en el monedero es el resultado final de un cálculo más largo: qué participación contó, a qué delegado apoyó, qué porcentaje asignó ese delegado a los votantes y adónde debe ir el pago. El servicio Hermes de IoTeX automatizaba ese trabajo para los delegados participantes. Sus distribuciones ya usaban un contrato inteligente y dejaban registros on-chain. Presentar Zanzibar como la primera vez que esas recompensas se hicieron visibles en la cadena ocultaría el cambio real.[5]
Zanzibar incorpora al propio protocolo el cálculo y la distribución para los delegados participantes. Los validadores obtienen el resultado a partir del estado confirmado al procesar la cadena, sin depender de un servicio separado que calcule y envíe cada distribución. Esa es la idea central de IIP-59: incluir el trabajo previo al pago en las reglas que los nodos reproducen.[1][3]
La hora era una estimación; el bloque es un registro
El punto de activación en Mainnet era el bloque 53.533.081. IoTeXScan lo registra a las 02:28:37 UTC del 19 de octubre de 2026. El código publicado fija Zanzibar, Zanzibar Beta y Zanzibar Gamma en la misma altura. Ese registro respalda que se alcanzó el punto de activación; las 02:00 UTC anunciadas eran una estimación, no la hora observada del bloque.[2][4]
El calendario cambió durante el proceso. Un commit de documentación del 24 de septiembre trasladó el objetivo del bloque 53.155.801, estimado para el 8 de octubre, a la altura posterior. La versión de mantenimiento v2.5.1, publicada el 4 de octubre, mantuvo el nuevo calendario. Mainnet recibe las correcciones Beta y Gamma junto con Zanzibar, mientras que Testnet activó esas etapas por separado. La publicación del software, la hora estimada y el bloque de activación registrado corresponden a pasos distintos.[9][8][1]
Fijar los datos y repartir el trabajo
El proceso tiene una fase de acumulación y otra de liquidación. La parte del delegado se paga de inmediato; la de los votantes se acumula en un fondo asociado a ese delegado. En el límite de cada era de recompensas se fijan los datos necesarios para liquidar, entre ellos la configuración del delegado y el estado del staking. La configuración publicada establece eras de 24 épocas. No promete pagos a una hora fija del reloj.[3][4]
Después, los pagos se procesan en lotes acotados a lo largo de bloques posteriores. El valor predeterminado publicado limita cada lote a 256 votantes distintos: reparte el trabajo en vez de concentrar toda la distribución en un bloque. Una instantánea vincula el cálculo al estado anterior pertinente mientras el staking sigue cambiando. Puede imaginarse como una hoja de asignaciones fija que se procesa por tandas: una modificación posterior del registro activo no reescribe silenciosamente la hoja que ya se está liquidando.[3][4]
Una bifurcación no lleva a todos por la misma ruta
La migración automática de Hermes se ejecuta una sola vez, durante la activación. Selecciona candidatos cuya dirección de recompensa corresponde a las bóvedas Hermes configuradas y exige los dos campos de porcentajes para votantes en DelegateProfile. Un candidato sin esa configuración continúa por la ruta Hermes existente. Otros candidatos pueden incorporarse mediante una acción autorizada por su propietario. El recuento previo de candidatos en la nota de versión es una observación anterior a la bifurcación, no una auditoría de quienes migraron realmente el 19 de octubre.[1][6]
Las aportaciones calculadas para un votante desde varios delegados pueden reunirse en un solo pago. El código de destino puede abonar la cuenta configurada o añadir la cantidad a un depósito de staking nativo, denominado bucket, si cumple las condiciones de depósito automático. Son destinos diferentes de una recompensa asignada. Poseer IOTX por sí solo no establece participación, una cantidad de recompensa ni un derecho a reinversión automática.[3][7]
Qué demuestra la activación y qué queda por comprobar
El bloque de activación y las reglas publicadas establecen que se alcanzó el punto de transición previsto. No demuestran que todos los votantes elegibles ya hayan recibido su pago. Los límites entre eras, el procesamiento por etapas y la configuración del delegado siguen siendo relevantes. Este artículo verifica el registro de activación y explica el diseño publicado; no audita pagos individuales ni mide rendimientos obtenidos.[1][2][4]
Para comprobar un pago concreto, las preguntas útiles son precisas: ¿entró el delegado en el nuevo modo?, ¿qué configuración y participación se fijaron para esa liquidación?, ¿qué abono o depósito quedó registrado? Zanzibar incorpora esa cadena de cálculo a una ejecución compartida. El valor del cambio está en poder examinar, con reglas comunes, el recorrido desde la participación elegible hasta el pago registrado. Esas reglas y sus datos de entrada siguen determinando quién recibe qué.[3][6][7]
Historias para seguir leyendo
Explora el tema a través de otros casos y contextos.
Fuentes y referencias
- [1]Fuente 1: Nota de Zanzibar: revisión del 24 de septiembreIoTeX FoundationConsultado 2026-10-19
- [2]Fuente 2: Bloque de activación 53.533.081IoTeXScanConsultado 2026-10-19
- [3]Fuente 3: Diseño de IIP-59: distribución de recompensas nativa del protocolo (Draft)IoTeX Improvement ProposalsConsultado 2026-10-19
- [4]Fuente 4: Código génesis de v2.5.1: alturas y parámetros de recompensasIoTeX FoundationConsultado 2026-10-19
- [5]Fuente 5: Hermes: operación fuera de la cadena y distribución on-chainIoTeX DocumentationConsultado 2026-10-19
- [6]Fuente 6: Código v2.5.1: migración única de Hermes y filtro de perfilIoTeX FoundationConsultado 2026-10-19
- [7]Fuente 7: Código v2.5.1: pago combinado al votante y destinoIoTeX FoundationConsultado 2026-10-19
- [8]Fuente 8: Versión v2.5.1: calendario de Zanzibar sin cambiosIoTeX FoundationConsultado 2026-10-19
- [9]Fuente 9: Commit del 24 de septiembre que reprograma la activaciónIoTeX FoundationConsultado 2026-10-19