Polygon propone mover 70 millones de POL sin la firma de los titulares de las billeteras
Polygon propone recuperar 70 millones de POL de billeteras vinculadas a hackeos sin la firma de los titulares, cambiando los saldos a través de la autoridad de gobernanza y los validadores.
Propuesta de Recuperación de Polygon
La propuesta de recuperación de Polygon busca mover aproximadamente 70 millones de POL desde cinco billeteras vinculadas a hackeos, sin necesidad de que sus titulares firmen la transferencia. Este plan cambiaría los saldos a través de las reglas de la red, otorgando la autoridad para devolver los fondos robados a la gobernanza y a los validadores.
"La propuesta, presentada el 4 de noviembre, se centra en cinco direcciones asociadas a fondos robados en incidentes de seguridad que afectaron al mercado de predicciones Polymarket y al intercambio Binance."
Según las tablas de referencia, se atribuyen aproximadamente 24 millones de POL a cuatro direcciones vinculadas a Polymarket y 47 millones de POL a una dirección relacionada con Binance. Sin embargo, la recuperación real utilizaría los saldos en el momento de la activación, no las cantidades de referencia mencionadas.
Detalles de la Propuesta
Hasta el 9 de noviembre, la propuesta aún no ha decidido el nombre del fork de recuperación, la versión del cliente ni el bloque de activación. La agenda de gobernanza del 5 de noviembre incluye la propuesta para discusión, aunque no ha sido registrada para su aprobación.
La versión separada Bor v2.11.0 implementa los cambios de StateReceiver de Uburu, en lugar de esta recuperación propuesta. Bajo el diseño sugerido, el software actualizado leería el saldo de cada dirección listada inmediatamente antes de la activación, lo establecería en cero y acreditaría la misma cantidad a la dirección de recuperación designada. Este proceso se llevaría a cabo antes de que se ejecuten las transacciones en el bloque de activación.
El suministro total se mantendría igual y la historia anterior de la cadena permanecería intacta. La propuesta indica que la ingeniería de Bor aún debe confirmar el diseño. Esto colocaría la autoridad de recuperación en una combinación de aprobación de gobernanza, la lista de direcciones especificadas y la regla del software que adopten los validadores.
Verificación y Beneficiarios
Las empresas afectadas designarían a los beneficiarios, y Polygon Labs confirmaría la prueba propuesta del control del beneficiario. La barrida propuesta no requeriría una transacción firmada por las direcciones de origen, ya que esas son responsabilidades separadas. Rastrear monedas robadas a una dirección apoya el caso para incluirla; probar el control de una dirección de recuperación verifica a dónde irían las monedas.
La propuesta advierte que identificar erróneamente una dirección controlada por un atacante podría mover un saldo legítimo. Los requisitos de verificación de beneficiarios exigen prueba de control, como un mensaje firmado o una pequeña transferencia de prueba confirmada por Polygon Labs, además de una confirmación escrita de que la dirección pertenece al beneficiario.
La propuesta también excluye otros tokens y una categoría separada de direcciones bloqueadas, limitando la barrida propuesta a POL nativo en las cinco cuentas listadas. La regla de saldo completo plantea otra pregunta de propiedad: los depósitos posteriores también se moverían.
Implicaciones para Intercambios y Custodios
La propuesta requiere que los saldos se verifiquen nuevamente antes de la activación y que cualquier cambio se publique. Estas verificaciones revelarían qué monedas incluye la barrida, pero no establecerían que cada depósito posterior perteneciera a una víctima del incidente. Para intercambios y custodios, el movimiento propuesto generaría una discrepancia entre el saldo mostrado por un nodo actualizado y el saldo reconstruido únicamente a partir de transacciones ordinarias.
La propuesta señala explícitamente este problema para exploradores, indexadores y herramientas contables. Por lo tanto, una reconciliación necesitaría conectar cada dirección de origen afectada, su saldo antes de la activación, el beneficiario designado y el crédito correspondiente en el bloque de activación.
Para los custodios, la regla implica un ajuste de saldo separado, ya que no habría una transacción de transferencia ordinaria para compararla. Las verificaciones planificadas abordan parte de esa carga: un ensayo de Amoy probaría que el suministro se mantenga constante y que las cuentas no relacionadas permanezcan sin cambios, seguido de una repetición del fork de mainnet.
Reembolsos y Próximos Pasos
La propuesta también solicita publicar el cambio de saldo sin transacciones y un script de verificación después de la activación. Juntos, esos registros permitirían a los operadores comparar el cambio implementado con el alcance aprobado. El reembolso a los clientes es un proceso separado.
"En su postmortem del 30 de octubre, Polymarket informó que el 95% de las billeteras afectadas habían sido reembolsadas en su totalidad esa tarde y anunció que se estaban devolviendo 4 millones de dólares, incluidos 1 millón por pérdidas relacionadas con la pausa."
Estos reembolsos compensan a los comerciantes; el fork propuesto devolvería activos a direcciones de recuperación designadas por la empresa. El próximo hito de recuperación requerirá una decisión de gobernanza, una especificación final del software, beneficiarios verificados y un bloque de activación.