Cómo Polygon devolvería 70 millones de POL robados a carteras de recuperación

Dos robos dejaron millones de POL en cinco direcciones bloqueadas. Una propuesta de Polygon trasladaría esos saldos a carteras de recuperación cambiando las reglas de la red en un bloque específico. Llevar los tokens allí resolvería una parte de la recuperación. Devolvérselos a los clientes es un trabajo aparte.

Una propuesta de mejora de Polygon ha identificado 70,49 millones de POL en cinco direcciones bloqueadas que una bifurcación dura coordinada podría trasladar a carteras de recuperación designadas para Binance y Polymarket.

La propuesta describe un cambio en los saldos de POL nativo en un bloque fijo. El software pondría a cero los cinco saldos listados y acreditaría las cantidades correspondientes a direcciones de recuperación verificadas.

La distinción está entre un saldo que la red ha impedido mover y uno que un equipo de recuperación puede controlar. Para los clientes, existe una distinción adicional entre que los tokens lleguen a una cartera de recuperación y que una plataforma reconozca y pague una reclamación.

Cómo se suman los dos incidentes

La propuesta asigna 46,63 millones de POL en una dirección a el incidente de Binance y 23,86 millones en cuatro direcciones a el incidente de Polymarket. Sumando esas cifras redondeadas se obtienen 70,49 millones de POL. Dividiendo cada una por ese total, la participación de Binance es de aproximadamente el 66,2% y la de Polymarket del 33,8%.

Esas son participaciones de la recuperación propuesta, no medidas de las pérdidas totales de los dos incidentes. Una estimación en dólares también depende de la marca temporal y el precio utilizados. Las cantidades en la propuesta están denominadas en POL.

Las direcciones importan más que la cifra titular en dólares

Los saldos de referencia de la propuesta suman 70.489.329,34 POL. La dirección de Binance representa 46.626.593,27 POL, mientras que las cuatro direcciones de Polymarket representan 23.862.736,07 POL. Esos son saldos en bloques de referencia elegidos por los autores. La transferencia anterior desde una cartera caliente de Binance fue ligeramente menor que el saldo registrado posteriormente en la dirección receptora.

Una diferencia de cuatro tokens en una transferencia de más de 46 millones apenas cambiaría la cifra titular. Importa a un implementador porque hay dos números posibles que codificar: la cantidad rastreada desde el remitente y el saldo completo en el destino. La propuesta describe este último como la cantidad a leer del estado inmediatamente antes de la activación, con una instantánea previa que se publicará para que los cambios sean visibles. Por lo tanto, el borrador debe leerse como un procedimiento para determinar la cantidad final, junto con una tabla que establece la cantidad aproximada en discusión.

La cifra de Polymarket presenta un problema de medición distinto. La propuesta sitúa el incidente en aproximadamente 28 millones de POL y los cuatro saldos seleccionados en alrededor de 23,86 millones de POL. Frente a esa estimación redondeada del incidente, el monto seleccionado representa aproximadamente el 85%, dejando una diferencia de aproximadamente 4,14 millones de POL. Esa resta mide la brecha entre la estimación del incidente y los saldos seleccionados. No puede establecer dónde terminaron los tokens restantes ni si algunos podrían recuperarse mediante otra vía.

La conversión a dólares añade otra variable. A $0,092 por POL, el saldo de referencia valdría aproximadamente $6,49 millones. A $0,096, los mismos tokens valdrían aproximadamente $6,77 millones. El cálculo multiplica la cantidad de referencia de la propuesta por dos precios ilustrativos. Explica cómo las cifras en dólares cercanas a $6,5 millones y $6,8 millones podrían describir casi la misma transferencia propuesta. La cobertura inicial situó el valor en torno a $6,5 millones. Una decisión de pago necesitaría una fecha de valoración y una fuente de precio explícitas.

Lo que la bifurcación propuesta dejaría atrás

La recuperación propuesta cubre aproximadamente el 85% de los aproximadamente 28 millones de POL atribuidos al incidente de Polymarket en la publicación del foro. Es tentador describir el 15% restante como un monto que la bifurcación no lograría recuperar. La comparación más precisa es entre una cifra aproximada del incidente y los saldos que los autores dicen que aún se mantienen en cuatro direcciones. Se necesitaría un ejercicio de rastreo separado para dar cuenta de la diferencia.

La comparación con Binance es diferente. La propuesta identifica una transferencia de 46.626.589,6 POL desde una billetera caliente y un saldo de 46.626.593,27 POL en el destinatario cuando se tomó la instantánea de referencia. El saldo de destino era aproximadamente 3,67 POL mayor que esa transferencia. La diferencia es lo suficientemente pequeña como para desaparecer en cualquier titular redondeado, pero ayuda a explicar por qué una instantánea tomada en un bloque especificado es más útil que citar un monto de la transacción original.

Una segunda lección reside en las unidades. La tabla de referencia utiliza POL nativo, mientras que la transferencia anterior de Binance también incluía 6.185.900,1 USDT. Un total en dólares que incluya ambos cubriría un conjunto de activos diferente al de la bifurcación propuesta. Un informe sobre dinero bloqueado podría razonablemente tratar ambos, siempre que deje claro qué organización tomó cada acción y si los fondos se movieron posteriormente.

Los dos casos también comparten un mecanismo de activación sin compartir una sola cuenta. El software de Polygon acreditaría direcciones de recuperación separadas, preservando la distinción entre los saldos asignados a cada incidente. Los destinatarios podrían, por lo tanto, conciliar lo que recibieron con sus propias reclamaciones y registros de compensación. La publicación del foro no combina las reclamaciones derivadas de los dos incidentes ni otorga a una plataforma autoridad sobre los ingresos de la otra.

Qué nos puede decir un saldo bloqueado

Un bloqueo puede impedir que una dirección listada transfiera fondos mientras el saldo sigue apareciendo en la cadena. Un observador puede ver cuánto queda en una dirección sin poder determinar cuánto se le debe a ningún cliente individual.

Los cinco saldos definen el alcance de esta propuesta. Un activo involucrado en cualquiera de los dos incidentes pero fuera de esos saldos necesitaría su propia vía de recuperación.

Qué puede establecer el registro de transferencias

La propuesta describe dos transferencias nativas a las 18:30:34 y 18:35:59 UTC del 29 de octubre. Juntas movieron 3.282.275,71 POL de una dirección a otra. Dos marcas de tiempo importan porque ayudan a establecer la secuencia en la que los saldos se distribuyeron entre billeteras. El historial de transacciones puede mostrar movimientos y montos incluso cuando las personas que controlan las claves son más difíciles de identificar.

La propuesta vincula las direcciones listadas con los incidentes. Para una verificación independiente, un revisor necesitaría seguir los registros de transacciones nombrados y comparar las direcciones de origen con las cuentas identificadas por las plataformas afectadas. Eso es más específico que ver varias billeteras mover dinero el mismo día. También es distinto de probar una reclamación legal sobre cada moneda que aún está en una cuenta.

Una dirección que contenía POL nativo y una stablecoin puede ilustrar los límites del lenguaje a nivel de billetera. El emisor de la stablecoin puede actuar a través del contrato de la stablecoin. El POL nativo es parte de la contabilidad de saldos de la red. Los dos activos comparten una dirección, pero las personas que pueden impedir transferencias, y el mecanismo que pueden usar, dependen de qué es el activo.

La propuesta describe otras direcciones proporcionadas por Binance como Clase B. Pertenecen a la discusión de bloqueo, mientras que los cambios de estado del borrador se limitan a las direcciones de Clase A especificadas para la recuperación. Contar cada dirección bloqueada como una billetera que sería vaciada exageraría el alcance. También oscurecería una cuestión de gobernanza importante: bloquear una transacción es una acción, mientras que decidir que un saldo específico debe ir a un destinatario designado es otra.

Por qué dos activos requirieron respuestas diferentes

La cronología de la propuesta de Polygon rastrea 46.626.589,6 POL nativos y 6.185.900,1 USDT desde una billetera caliente de Binance hasta el mismo destinatario en el bloque 96.406.484. Tether congeló los USDT. El POL siguió siendo objeto de la intervención de red propuesta.

La transferencia propuesta aborda los diferentes controles disponibles sobre esos dos activos. Un emisor puede imponer restricciones a través del sistema que opera para su token. En este caso, los productores de bloques de Polygon utilizaron en su lugar un filtro de transacciones Bor para el POL nativo, y la propuesta describe ese filtro como una solución provisional.

Cada productor de bloques lee la lista al iniciarse, según la propuesta. Los cambios requieren despliegue y un reinicio o rotación, y el filtro cubre a los remitentes externos y a las autoridades EIP-7702. La propuesta dice que la instantánea se releerá antes de la activación, por lo que su tabla publicada es una referencia y no una garantía de los montos finales de débito.

Por qué un filtro de transacciones puede mantenerse durante días y aun así ser temporal

La lista de los productores de bloques se basa en la configuración del software. La propuesta dice que la lista se lee al iniciarse. Por lo tanto, una nueva entrada necesita un cambio operativo, y los operadores deben aplicar la misma configuración si se quiere que las restricciones funcionen según lo previsto. El esfuerzo involucrado puede justificarse durante un incidente en vivo, cuando cada hora le da a una persona que posee las claves otra oportunidad de mover fondos.

Una restricción en la capa del productor también tiene que coincidir con la forma en que se puede autorizar una transacción. La propuesta dice que el filtro cubre a los remitentes externos y a las autoridades EIP-7702. Esa es una afirmación más limitada que decir que los fondos se han vuelto imposibles de mover bajo cualquier ruta de transacción concebible. Lo que los autores informan es que los fondos fueron detenidos y que no habían encontrado una forma de elusión. Identifican limitaciones en el enfoque como parte de su argumento a favor de un cambio más duradero.

Los autores describen una transacción pendiente que lleva una tarifa propuesta inusualmente grande e intentos de obtener asistencia de los validadores. Una transacción intentada es evidencia de un esfuerzo por cambiar el estado del saldo. Tiene un peso probatorio diferente al de una transferencia ejecutada. La propuesta también describe un canal de recuperación en cadena sin respuesta. Una devolución negociada habría dependido de la respuesta de una parte capaz de autorizar el pago, mientras que la propuesta de bifurcación funcionaría mediante la adopción de nuevas reglas por parte de los participantes.

Una lista indefinida tiene consecuencias prácticas para las personas que la administran. Necesitarían saber qué entradas siguen teniendo un propósito, cómo los nuevos operadores obtienen la configuración correcta y quién es responsable de revisar las entradas antiguas. La propuesta del foro prevé una revisión después de la recuperación, incluido un manejo distinto para las direcciones adicionales. Eso significa que la propuesta concierne tanto a un cambio de saldo único como a lo que sucede con los controles temporales que lo rodean.

Qué cambia en el bloque de bifurcación

Normalmente, una transferencia cambia los saldos de las cuentas después de que se acepta una transacción válida según las reglas de la red. La propuesta, en cambio, pide al software que sigue las reglas actualizadas que aplique los débitos y créditos enumerados como parte del procesamiento de un bloque especificado.

Los créditos correspondientes importan. La operación, tal como se describe, toma la misma cantidad de tokens nativos de las direcciones enumeradas que la que otorga a las direcciones de recuperación designadas. El alcance no se extiende a tokens arbitrarios en las billeteras.

El bloque que registraría la recuperación

El cambio de estado propuesto está ordenado en torno al bloque de activación, que el borrador llama F. El monto relevante es el saldo después de F menos uno. Los nodos actualizados aplicarían los ajustes de saldo prescritos antes de las transacciones ordinarias en F. Esa secuenciación importa porque identifica el límite exacto que un revisor usaría para verificar el resultado.

Una transferencia normal suele dar a un explorador una entrada de transacción para mostrar. Un cambio aplicado directamente bajo las reglas de la cadena puede, en cambio, ser visible al comparar los saldos entre bloques adyacentes. Alguien que solo mire la lista de transferencias ordinarias del destinatario podría pasarlo por alto. La publicación propuesta de un script de verificación ayudaría a conectar el estado anterior y posterior con la lista de destinatarios previstos.

La verificación debe cubrir ambos lados del libro mayor. Buscaría un débito y un crédito coincidentes para cada saldo. Si una dirección de recuperación también recibió transacciones ordinarias en el mismo bloque, la diferencia bruta entre dos instantáneas podría incluir esos movimientos. Un revisor tendría entonces que separarlos del cambio de estado especial en lugar de tratar cada incremento como fondos recuperados.

El bloque de activación es una fecha límite de coordinación. Un operador que ejecute software que calcule el estado antiguo y un operador que aplique la regla especial de saldo podrían calcular resultados diferentes a partir del mismo bloque. Por lo tanto, el trabajo práctico incluye publicar el cambio, dar a los operadores tiempo para revisarlo y dejar claro el punto de activación. La tabla de la propuesta todavía etiqueta el bloque como una decisión que debe tomarse una vez que la aprobación esté en vigor. Una discusión de gobernanza es una oportunidad para zanjar ese plan, mientras que el estado de la cadena establecería la ejecución.

Quién hace efectivo el cambio

La propuesta del foro describe el cambio solicitado. Un hito separado sería una versión que lo implemente e identifique el bloque de activación. Los operadores tendrían entonces que adoptar software compatible para que el cambio surta efecto en la cadena que utilizan.

Un usuario que siga la propuesta debería, por tanto, distinguir una publicación en el foro, una implementación y un bloque que refleje realmente los nuevos saldos. Cada uno responde a una pregunta diferente sobre la recuperación.

El trabajo detrás de elegir un bloque de activación

Un número de bloque puede parecer un detalle administrativo. En la práctica, es donde el nuevo software y el antiguo empiezan a discrepar sobre los saldos de las cuentas afectadas. Elegirlo da a los operadores una fecha límite compartida para instalar la actualización, y da a los exploradores, proveedores de infraestructura y las empresas afectadas un punto común desde el cual comprobar el resultado.

La preparación propuesta en la publicación del foro implica confirmar los destinos, mantener los arreglos de bloqueo en vigor hasta la activación y publicar una instantánea de saldo actualizada. Esos pasos abordan diferentes formas en que una recuperación podría salir mal. Una dirección registrada incorrectamente podría enviar activos a un lugar no deseado. Un cambio inexplicado en un saldo podría dejar a los lectores comparando el resultado con una cifra obsoleta. Una actualización retrasada podría dejar a un operador calculando el estado con las reglas antiguas.

Cada uno de esos problemas requiere una comprobación diferente. Para el destino, la evidencia importante es cómo el destinatario demuestra el control y cómo se revisa la dirección publicada. Para el importe, es el saldo en el punto de referencia final. Para la red, es qué versiones de software procesan realmente los bloques después del punto de activación. Una declaración de que los operadores apoyan la recuperación no respondería por sí sola a ninguna de esas preguntas de implementación.

También hay una comprobación útil después del evento. El cambio de estado afectaría directamente a los saldos nativos, mientras que un pago ordinario realizado en el mismo bloque podría afectar al mismo destinatario. Por lo tanto, una diferencia de saldo debe conciliarse con las transacciones ordinarias de ese bloque. Ahí es donde el script de verificación propuesto por los autores sería útil, especialmente si identifica tanto el débito como el crédito correspondiente para cada cuenta.

Dónde entran los clientes en el proceso

El destinatario de la transferencia propuesta es una dirección de recuperación, no una lista de cuentas de clientes. Una vez que un operador controla los fondos, la siguiente pregunta es cómo su propio proceso de recuperación y reembolso los contabiliza.

La evidencia relevante incluiría un calendario de reclamaciones, instrucciones para demostrar una pérdida y una política sobre la fecha de valoración. Una plataforma podría haber reembolsado ya a algunos usuarios con otros fondos. Su contabilidad tendría que establecer adónde va el POL recuperado en esos casos.

Qué cuenta como una devolución a los clientes

Una cartera receptora es donde la capacidad de la red para mover los fondos se encuentra con la responsabilidad de una organización de contabilizarlos. Si los clientes afectados ya han sido reembolsados con los propios recursos de un exchange, la recuperación podría reponer esos recursos según los términos aplicables. Si tienen reclamaciones pendientes, una distribución podría en cambio reducir la cantidad que se les debe. Ambos escenarios implican que el dinero llegue a una dirección de recuperación, con consecuencias diferentes para los usuarios.

También puede haber un desajuste entre el activo recuperado y el activo que perdió un cliente. Un usuario cuyo saldo original estaba denominado en dólares u otro token necesitaría saber si la compensación se calcula en unidades de ese activo original, en POL o en dinero a un precio declarado. Un token volátil puede producir resultados materialmente diferentes según cuándo se mida la conversión.

La distinción entre los saldos de los clientes y las pérdidas de la plataforma es especialmente importante cuando se combinan incidentes separados en una sola propuesta. La tabla de referencia asigna los saldos de Polygon por incidente. No contiene un fondo común de reclamaciones ni un cálculo de las cantidades adeudadas a usuarios individuales. Incluso si ambos conjuntos de saldos se mueven en el mismo bloque de activación, las plataformas pueden enfrentar obligaciones diferentes y pueden anunciar arreglos de pago diferentes.

La evidencia pública puede ordenarse según lo que cada paso demostraría. Una altura de liberación y activación mostraría que una implementación está lista. El estado del bloque mostraría si el libro mayor cambió. Los registros de la plataforma establecerían si los activos recuperados se distribuyeron, se retuvieron contra una compensación previa o se contabilizaron de otro modo. El borrador del foro hace específicos sus destinos previstos a nivel de cadena para cada incidente y prevé la verificación pública de los cambios de saldo.

¿Quién puede decidir cuánto vale un token recuperado?

Supongamos, a modo de ilustración, que una plataforma debe a un usuario el valor en efectivo de un saldo y recibe POL después de que el precio haya cambiado. Hay al menos tres fechas a las que la plataforma podría referirse: el momento del robo, el momento en que obtiene los tokens recuperados y el momento en que realiza una distribución. La cantidad de efectivo representada por la misma cantidad de POL puede diferir en cada punto.

Una política de reclamaciones podría, en cambio, prever el pago en unidades del activo que se perdió. Eso evita elegir un precio de mercado para una reclamación denominada en el mismo activo, pero aún deja preguntas sobre la elegibilidad y los reembolsos previos. Un cliente que ya había sido reembolsado podría tener una posición diferente de la de alguien cuya reclamación sigue pendiente. La red no tiene ningún papel en tomar esas determinaciones.

Lo que un cliente necesita es una declaración de lo que la plataforma debe, en qué unidad y cómo contabiliza cualquier cosa pagada anteriormente. La cadena puede establecer que una dirección de recuperación recibió un saldo, y la plataforma puede conciliarlo con sus registros. Ninguno de los dos documentos hace el trabajo del otro. Esta es una razón por la que una recuperación confirmada puede ser noticia incluso si todavía hay una espera separada para los detalles de una distribución.

Una comparación de informes puede mantener las cifras una al lado de la otra. La primera sería el POL nativo recuperado bajo el cambio de estado. La segunda sería la cantidad asignada a las reclamaciones de los clientes o a los reembolsos ya realizados. La tercera sería cualquier saldo que permanezca en custodia mientras la plataforma resuelve casos individuales. Un único número en dólares tomado de la primera etapa diría poco a los lectores sobre las otras dos.

Por qué importa el alcance limitado

Una bifurcación que cambia saldos plantea una pregunta que una actualización de software normal no plantea. ¿Qué hechos tendrían que estar presentes para que los participantes apoyen esta intervención nuevamente?

La propuesta misma describe la acción como extrema y la limita a los saldos de POL nativo enumerados. El caso a favor de la propuesta y la cuestión del precedente pueden evaluarse ambos contra los mismos detalles concretos: las direcciones identificadas, el destino propuesto y el bloque en el que cambiarían los saldos.

¿Qué haría que este caso fuera un precedente?

Otro proyecto podría señalar el enfoque de Polygon después de un robo, pero las circunstancias en este borrador son inusualmente específicas. Los autores identifican los incidentes, las cuentas enumeradas, los activos sujetos al cambio propuesto y adónde irían. También describen por qué la restricción ya en uso era solo una medida temporal. Una propuesta sin esos elementos presentaría un caso diferente para cambiar saldos.

El problema importante es a quién hay que persuadir y qué información recibe. Un exchange puede saber qué saldos de clientes se vieron afectados, mientras que los operadores necesitan evidencia sobre el cambio propuesto a la cadena. Un usuario cuyos fondos se recuperan está interesado en el resultado. Un operador que evalúa la propuesta también tiene que pensar en cómo evaluaría una solicitud futura de una parte diferente.

La comparación más segura es entre los hechos que otra solicitud podría demostrar. ¿Puede identificar el monto en un bloque determinado? ¿Puede vincular esos fondos con un incidente reconocido? ¿Puede verificar un destinatario y especificar qué sucede con las direcciones ya bloqueadas? Esas preguntas se derivan directamente del borrador publicado y son más útiles que describir cada cambio de estado inusual como equivalente.

La propuesta dejaría algunas de esas preguntas verificables en público. Una altura de activación permitiría a los observadores identificar la transición de estado exacta. Los destinos nombrados les permitirían rastrear lo que ocurrió después. Los autores también proponen revisar las entradas de la lista de bloqueo temporal después de la activación, incluido un tratamiento diferente para las direcciones adicionales relacionadas con Binance. Esa revisión final ayudaría a establecer qué restricciones de emergencia permanecen en uso una vez completada la recuperación.

Qué podría confirmar el libro mayor

Si se implementa la propuesta, la primera comprobación compararía los saldos de las direcciones enumeradas a ambos lados del bloque de bifurcación. Los créditos coincidentes mostrarían que el libro mayor aplicó la transferencia según lo especificado. Las distribuciones a clientes necesitarían evidencia de los operadores de recuperación.

La propuesta actual especifica cinco direcciones de origen y direcciones de recuperación designadas para los dos incidentes.

Qué registros responden a qué pregunta de recuperación

Un incidente puede avanzar por estas etapas a velocidades diferentes. La congelación de USDT, por ejemplo, concierne a un activo y un mecanismo diferentes de la bifurcación POL propuesta. Un anuncio posterior sobre fondos protegidos o recuperados tendría que especificar qué activo se contabilizó y qué le sucedió.

Los saldos también pueden cambiar entre las fechas utilizadas en los informes. Una propuesta que cita una instantánea anterior debería conservar el número de bloque para que los lectores puedan reproducir el monto incluso si el saldo actual cambia. Cuando se conozca el resultado, comparar el bloque de ejecución con la instantánea publicada establecería si el monto devuelto difiere del monto discutido en la propuesta.

La conciliación más importante para los lectores es entre el monto debitado y el monto acreditado. Publicar esa comprobación por separado para los dos incidentes permitiría comparar el relato posterior de cada plataforma sobre los ingresos con el monto sobre el que realmente obtuvo control. Un único total combinado dificultaría seguir qué ingresos estaban disponibles para atender qué reclamaciones.

Una recuperación limitada también da a las plataformas una forma de comunicar qué sucedió con los activos fuera de la bifurcación. La cifra de Polymarket en la publicación del foro incluye más POL que el enumerado en el cambio de estado propuesto. La transferencia de Binance incluyó USDT, que Tether gestionó por separado. Una actualización de recuperación que identifique el activo relevante, la dirección y la acción tomada permitiría a los lectores conciliar ambos incidentes sin suponer que todos los fondos robados siguieron una sola ruta.

La cronología ofrece tres fechas con significados diferentes. La fecha del incidente establece cuándo se movieron los fondos. El bloque de referencia establece qué se observó en las direcciones cuando los autores compilaron la propuesta. La fecha de activación, si se acuerda, establecería cuándo la red aplica la regla de recuperación. Un token puede estar protegido contra ciertas transferencias entre esas fechas sin haber sido devuelto mientras tanto.

Los registros de direcciones también pueden servir como control de las declaraciones que se hacen después de una actualización. Si un operador afirma que los fondos se enviaron al destino publicado, la cadena debería mostrar el cambio de saldo correspondiente en la altura de activación. Si dice que se ha reembolsado a los clientes, la evidencia más útil es un registro de distribución o una explicación clara de los reembolsos. Una es una declaración sobre la red, la otra sobre las obligaciones de la plataforma.

Por eso la evidencia del libro mayor es especialmente valiosa cuando la conversación pública gira en torno a si el fork funcionó. Ofrece a los observadores una pregunta concreta que pueden verificar sin esperar a que cada empresa afectada complete su propia contabilidad. La propuesta establece un procedimiento para publicar los saldos utilizados en el cambio de estado y para verificar los créditos de los destinatarios después. Esos registros también darían a los usuarios un punto de partida para rastrear lo que hizo cada plataforma una vez que tuvo el control del dinero.

Qué observar

• Propuesta de liberación: Las cantidades específicas del incidente, las direcciones de destinatarios propuestas y las instrucciones ejecutables presentadas a la gobernanza.
• Bloque de activación: La altura de bloque confirmada y la versión de software que los operadores de Polygon necesitarían instalar antes de ella.
• Créditos de recuperación: El POL nativo debitado de cada dirección bloqueada y el crédito correspondiente registrado en su destinatario designado.
• Reclamaciones de clientes: Las instrucciones de cada plataforma sobre elegibilidad, valoración y cómo contabilizará los reembolsos anteriores.

Preguntas frecuentes