Se pide a los validadores de Polygon que aprueben un hard fork que reasignaría unos 70.49 millones de $POL desde cinco direcciones bloqueadas hacia billeteras de recuperación de Polymarket y Binance.
La Propuesta de Mejora de Polygon, publicada el 4 de noviembre, identifica las direcciones como controladas por un atacante tras incidentes de seguridad independientes ocurridos del 29 al 30 de octubre. El borrador está pendiente de aprobación, sin bloque de activación ni versión de cliente definida.
Según la propuesta, los productores de bloques de Polygon PoS ya añadieron las direcciones a la lista de bloqueo de transacciones de Bor, a petición de las empresas afectadas. Eso ha mantenido los $POL inmovilizados, pero no ofrece forma de devolverlos. El fork reasignaría los saldos sin las firmas de los titulares, en lugar de deshacer transacciones anteriores.
Los saldos en PolygonScan verificados alrededor de las 12:23 p. m. ET del 4 de noviembre sumaban unos 70.49 millones de $POL nativos, según el cálculo de The Defiant: 23.86 millones repartidos entre cuatro direcciones vinculadas a Polymarket y 46.63 millones en la dirección vinculada a Binance. Usando el precio de CoinGecko alrededor de las 12:24 p. m. ET, The Defiant calcula un valor indicativo de 6.8 millones de dólares.
El informe posterior al incidente de Polymarket indicó que un script de terceros comprometido utilizó sesiones activas para vender las posiciones de los usuarios y vaciar las billeteras el 29 de octubre. Binance dijo en su informe de incidente por separado que un atacante explotó un acceso no autorizado a un servicio interno de firma de billeteras.
De bloquear transferencias a reasignar saldos
Al inicio de un bloque designado, el borrador leería el saldo de cada dirección incluida desde el bloque anterior, lo reduciría a cero y acreditaría la misma cantidad a la billetera de recuperación correspondiente. Solo se cubre el $POL nativo; otros tokens quedan excluidos, y el suministro total no cambiaría.
El borrador enumera ambas billeteras de recuperación, pero exige que cada empresa demuestre el control y confirme la titularidad por escrito antes de la activación. El diseño de saldo completo aún necesita la confirmación de los ingenieros de Bor.
Un fork de una sola vez, con riesgo de precedente
La propuesta califica esto como una “acción extrema” que “no debería reproducirse con frecuencia”. Rechaza un poder permanente de congelar y recuperar, y sostiene que la intervención se justifica por un robo reconocido públicamente, fondos rastreables, una solicitud de la víctima, el bloqueo por parte de todos los productores y un monto lo bastante grande como para justificar un fork.
Antes de la activación, la Sección 5 exige aprobación de la gobernanza, informes posteriores publicados que sean coherentes con el registro en cadena, bloqueo continuo por parte de todos los productores y una nueva captura de saldos con cualquier cambio publicado. Los nodos que no se actualicen seguirían una cadena distinta.
La propuesta está programada para presentarse en la llamada de gobernanza de protocolo de Polygon el 5 de noviembre a las 9:30 a. m. ET. El borrador considera que unas dos semanas después de la aprobación son viables para el desarrollo del cliente y un ensayo en la testnet Amoy; no fija una fecha de activación en mainnet.