GMX ha anunciado que los contratos de staking tanto en Arbitrum como en Avalanche migrarán a un nuevo contrato inteligente el 28 de octubre. Se recomienda a los stakers de ambas redes seguir de cerca las comunicaciones oficiales de GMX antes de interactuar con cualquier nueva dirección de contrato. La transición afecta el mecanismo central de staking mediante el cual los poseedores de GMX y GLP acumulan comisiones del protocolo y recompensas en custodia, lo que la convierte en un evento relevante para los participantes activos del protocolo.

La migración programada reemplaza el despliegue de staking existente en ambas redes soportadas simultáneamente. GMX opera como un exchange descentralizado de perpetuos —una plataforma de trading basada en futuros perpetuos, contratos derivados sin fecha de vencimiento— desplegado en Arbitrum y Avalanche, con el staking en el centro de su modelo de distribución de comisiones. Los stakers que poseen GMX o esGMX, la forma en custodia del token que se convierte en GMX con el tiempo, reciben una parte de las comisiones de trading del protocolo junto con puntos multiplicadores, incentivos que se acumulan mientras más tiempo permanezcan los tokens en staking y aumentan el peso efectivo del staker en la distribución de comisiones, todo lo cual fluye a través de la capa de contratos de staking que ahora se reemplaza. GLP, el token de proveedores de liquidez que representa los activos depositados en los pools de trading de GMX, se encuentra junto al GMX en staking en el centro de la economía de comisiones del protocolo.

Las migraciones de este tipo crean una breve ventana en la que los stakers deben confirmar que interactúan con la dirección actualizada correcta. Cualquier usuario que apruebe transacciones contra el contrato antiguo después de completada la migración no estaría haciendo staking contra la lógica activa de distribución de comisiones. El propio anuncio de GMX es la única fuente autorizada para la nueva dirección de contrato y para cualquier acción requerida del usuario, como retirar y volver a depositar en staking o aprobar un nuevo gasto de contrato.

Lo que los stakers de Arbitrum y Avalanche necesitan saber

La migración cubre los despliegues de Arbitrum y Avalanche en una única actualización coordinada. Para los stakers, la pregunta práctica es si se requiere alguna acción manual para permanecer en el pool activo de staking después del 28 de octubre. Las migraciones de contratos en protocolos como GMX pueden estructurarse de dos maneras: como migraciones automáticas, donde las posiciones existentes en staking se transfieren mediante una transferencia a nivel de contrato, o como migraciones opcionales, donde los usuarios deben interactuar ellos mismos con el nuevo contrato.

La distinción importa porque la continuidad de las recompensas depende de ella. Si la migración es opcional y un staker pierde la ventana de transición, su vesting de esGMX, sus puntos multiplicadores y sus derechos a comisiones podrían verse interrumpidos hasta que vuelva a hacer staking contra el contrato actualizado. La documentación oficial de GMX y los foros de gobernanza son los lugares correctos para confirmar la mecánica exacta de la migración antes de que llegue el 28 de octubre.

El riesgo de phishing también aumenta durante cualquier migración de contrato publicitada. Los actores maliciosos frecuentemente despliegan contratos fraudulentos que imitan las convenciones de nombres o la apariencia de interfaz de actualizaciones legítimas del protocolo. Los stakers deben verificar las nuevas direcciones de contrato exclusivamente contra fuentes publicadas directamente por el equipo de GMX, incluida la app oficial de GMX, el foro de gobernanza de GMX y las cuentas sociales verificadas. Cualquier mensaje no solicitado que dirija a los usuarios a una página de migración o a un nuevo contrato debe tratarse con cautela.

Por qué ocurren las actualizaciones de contratos de staking en protocolos de perpetuos

Los reemplazos de contratos de staking en plataformas de perpetuos generalmente abordan deuda técnica acumulada, introducen soporte para nuevas mecánicas de tokens o ajustan la lógica de enrutamiento de comisiones para acomodar actualizaciones en otras partes del sistema. GMX ya ha desplegado actualizaciones a nivel de contrato junto con cambios de versión importantes, y la migración del 28 de octubre sigue un patrón común en protocolos que iteran sobre su arquitectura de distribución de recompensas sin un relanzamiento completo del protocolo.

El alcance de doble cadena de la migración, que cubre Arbitrum y Avalanche al mismo tiempo, apunta a una actualización coordinada en lugar de una corrección específica de una cadena. Las migraciones coordinadas reducen la ventana durante la cual los dos despliegues ejecutarían lógica de staking diferente, lo que puede crear oportunidades de arbitraje o inconsistencias en cómo se acumulan las recompensas entre cadenas. Mantener ambas redes en la misma versión de contrato preserva la consistencia interna del protocolo y simplifica la auditoría de la contabilidad de recompensas.

Una coordinación multichain comparable aparece en otras partes de la gobernanza DeFi. El marco de gobernanza de Aave, por ejemplo, ha perseguido una coordinación similar de parámetros de riesgo en múltiples despliegues a través de sus propuestas de risk stewards de V4, donde la consistencia multichain es un objetivo de diseño recurrente. Para GMX, la capa de staking funciona menos como un mecanismo de gobernanza y más como un conducto de enrutamiento de comisiones, pero la lógica de coordinación entre cadenas es comparable.

Detalles clave a confirmar antes del 28 de octubre

Con la fecha de migración a un día de distancia, los stakers deben verificar varios detalles directamente en los canales oficiales de GMX antes de realizar cualquier acción on-chain:

• Nueva dirección de contrato: Confirme las direcciones de contrato de Arbitrum y Avalanche publicadas por el equipo de GMX. No confíe en agregadores de terceros ni en publicaciones de redes sociales para esta información.
• Acción requerida del usuario: Confirme si la migración es automática o requiere retirar y volver a depositar manualmente en staking. La respuesta determina si los stakers deben actuar antes o después del 28 de octubre.
• Continuidad de recompensas y vesting: Confirme cómo se manejan a nivel de contrato los plazos de vesting de esGMX y los puntos multiplicadores durante la transición. Una interrupción del vesting podría restablecer los saldos de puntos multiplicadores acumulados de los usuarios afectados.
• Ventana de tiempo: Confirme si existe un período de gracia después del 28 de octubre durante el cual ambos contratos, el antiguo y el nuevo, permanezcan activos, o si el cambio es inmediato.
• Estado posterior a la migración: Después de que se ejecute la migración, verifique sus saldos en staking y sus derechos a recompensas contra el nuevo contrato antes de aprobar más transacciones.

La fecha del 28 de octubre es el único detalle de tiempo confirmado en el anuncio público de GMX. Todos los detalles operativos, incluida la mecánica de la migración, las aprobaciones requeridas y las direcciones de contrato, deben obtenerse de la interfaz oficial de GMX y de las comunicaciones de gobernanza a medida que se publiquen. Los stakers que esperen la guía completa de migración antes de actuar están menos expuestos al phishing y al error humano que aquellos que actúen con información incompleta antes del cambio.

Un evento discreto de riesgo de contrato inteligente

Para los participantes de DeFi que mantienen posiciones en múltiples protocolos, la migración de GMX es un evento discreto de riesgo de contrato inteligente: un momento en el que cambian los supuestos de confianza asociados a una dirección de contrato específica. Los riesgos de contrato a nivel de protocolo de este tipo, incluida la posibilidad de errores en nuevos despliegues, son distintos del riesgo de mercado continuo de mantener GMX o GLP. Las rutas de actualización auditadas reducen pero no eliminan el riesgo del nuevo contrato, y la migración será una señal relevante de cómo el equipo de desarrollo de GMX maneja la transparencia de la transición y el proceso de verificación posterior a la migración.