Cuando un rollup deja de funcionar: explicación del cierre de Polygon zkEVM

3 de julio de 2026

10 minutos de lectura

Resumir con IA

Polygon zkEVM ha entrado oficialmente en su fase de retirada. El 1 de julio de 2026, Polygon Labs ha desactivado el secuenciador de la beta de la red principal de Polygon zkEVM, y los saldos de los monederos se han trasladado a Ethereum L1 mediante un proceso de reclamación. Hay que reconocer que el cierre se ha gestionado de forma impecable: los usuarios han tenido un año entero para prepararse, el puente permaneció abierto hasta el último día y las reclamaciones seguirán estando disponibles hasta finales de 2027.

El problema es que las cadenas de bloques no se limitan a almacenar monedas en carteras. Para cuando una red deja de funcionar, parte de la liquidez ya se encuentra enterrada a varias capas de profundidad: en fondos comunes, cajas fuertes, mercados de préstamos, posiciones de garantía y otros contratos que Polygon no controla. Trasladar eso de vuelta a L1 ya no es una simple tarea de puente.

Así que le hemos planteado a nuestro experto, Andrew Nalichaev, las preguntas que seguramente se están haciendo ahora mismo muchos en este ámbito: ¿Quién es el responsable de la liquidez bloqueada?, ¿qué ocurre con las stablecoins en una red en decadencia? y ¿qué deberían aprender otros rollups antes de enfrentarse al mismo problema?

Andrew Nalichaev

Experto en Blockchain y analista de DeFi

Andrew traduce conceptos descentralizados en herramientas financieras seguras y funcionales. Navega por el volátil panorama DeFi para construir infraestructuras de blockchain escalables que aborden la utilidad del mundo real, pasando de las palabras de moda para ofrecer valor técnico.

Ver perfil

- Si analizamos Polygon zkEVM como un caso práctico sobre el cierre de una red de capa 2, ¿qué se gestionó bien y qué se debería haber tenido en cuenta en el diseño desde el primer momento?

Lo mejor que hizo Polygon en este caso fue dar tiempo a los usuarios y ofrecerles un proceso claro. El cierre de zkEVM se anunció con aproximadamente un año de antelación, el puente permaneció abierto hasta el último día, se realizó una instantánea de los saldos y se ofreció a los usuarios una forma de reclamar sus fondos en Ethereum L1. En lo que respecta a los cierres, esa es una forma bastante ordenada de gestionarlo.

La parte que debería haberse tenido en cuenta desde el primer día es el plan de salida de DeFi. Trasladar los saldos de los monederos es una cosa, porque esos saldos se corresponden claramente con los activos depositados en la cuenta de garantía del puente. La DeFi es un tema aparte. Los tokens de LP, las participaciones en las cajas fuertes, las posiciones de garantía y los derechos de crédito necesitan sus propias vías de salida de emergencia a nivel de protocolo. Sin ello, una vez que el secuenciador se detenga, la liquidez depositada en contratos de terceros puede resultar muy difícil, o a veces imposible, de recuperar.

- ¿Hasta qué punto es realista cerrar “de forma ordenada” una red de capa 2 una vez que ya cuenta con protocolos DeFi, posiciones de LP, cajas fuertes, garantías y tokens derivados?

Es posible realizar un cierre ordenado, pero solo hasta cierto punto. Si hablamos de simples saldos de monederos o activos que se vinculan directamente al depósito en garantía del puente, entonces sí, se puede llevar a cabo el proceso de forma bastante ordenada. En cuanto entra en juego la composibilidad de DeFi, las cosas se complican mucho más.

Tomemos como ejemplo un pool básico de AMM. En teoría, se podría comprobar quién posee los tokens LP, calcular su participación en el pool y distribuir los activos subyacentes. Tiene que ser el titular actual, no quien los depositó originalmente; de lo contrario, se corre el riesgo de pagar dos veces a la misma persona. Pero la DeFi real rara vez es tan clara. Los tokens LP pueden depositarse en cajas fuertes, apostarse, utilizarse como garantía o integrarse en otro producto más. De repente, ya no se trata de un único derecho, sino de toda una cadena de ellos, y no existe una forma universal de saber quién es el “verdadero” propietario en todos los contratos posibles.

Así pues, la respuesta sincera es: una L2 solo puede cerrarse de forma ordenada si los protocolos que se ejecutan sobre ella han previsto ese escenario desde el principio. De lo contrario, aunque el cierre a nivel de red pueda parecer organizado, la capa DeFi puede seguir siendo un caos.

- ¿Cómo evaluarías el riesgo de doble gasto al intentar liquidar manualmente posiciones de DeFi tras una interrupción de la red? ¿Se trata principalmente de un problema técnico, jurídico o económico?

Es una combinación de los tres, pero, en el fondo, se trata de un problema económico.

El depósito en garantía del puente en L1 solo contiene los activos reales que se han incorporado al sistema. A partir de ahí, DeFi construye capas adicionales: tokens de LP, participaciones en la caja fuerte, posiciones de préstamo, tokens de deuda y otros derechos de crédito. En un mercado de préstamos, por ejemplo, se puede llegar rápidamente a tener más derechos de crédito que activos depositados en el depósito de garantía, al menos si se intenta satisfacer a todo el mundo al mismo tiempo.

Ahí es donde surge el problema del doble gasto. No se puede pagar al depositante, al prestatario y a todos los titulares de derivados con el mismo conjunto de activos subyacentes si dicho conjunto no es lo suficientemente grande como para cubrir todas esas reclamaciones.

También existe una trampa temporal. Algunas posiciones ni siquiera tienen un valor fijado en el momento en que se congelan: un préstamo “bajo el agua” requiere una liquidación, los intereses deben devengarse y un oráculo debe actualizarse. Si se detiene la cadena en pleno funcionamiento, la parte «justa» de esas posiciones pasa a ser indefinida, y no solo difícil de calcular.

Desde el punto de vista técnico, se puede intentar aclarar quién es el propietario de cada cosa. Desde el punto de vista jurídico, quizá haya que decidir qué derecho tiene prioridad. Pero desde el punto de vista económico, el límite es muy sencillo: no se pueden repartir más activos de los que realmente existen.

- ¿Deberían los equipos de L2 exigir que los protocolos cuenten con una vía de escape antes de permitirles inyectar liquidez en la red?

Sí, sobre todo si un protocolo va a custodiar el dinero de la gente. No se puede aceptar depósitos, generar liquidez y luego empezar a preguntarse “¿cómo sacamos a todo el mundo de aquí?” cuando la red ya se está cerrando.

La propia L2 solo puede ayudar con la parte clara y sencilla: saldos que coincidan con lo que hay en el depósito de garantía del puente. No es realista pensar que pueda entrar en cada protocolo DeFi y desentrañar los libros contables. En ese momento, el equipo de la L2 tendría que decidir quién es el propietario de qué, cómo deben valorarse las posiciones y a quién se le paga primero. Es una gran responsabilidad, y en realidad no es su trabajo.

Así que sí, los protocolos DeFi necesitan contar con sus propias vías de retirada de emergencia, su propia lógica de liquidación o sus propios planes de cierre antes de que los usuarios empiecen a inyectar una cantidad considerable de liquidez en ellos.

- ¿Cómo afecta el cierre de un secuenciador al modelo de confianza de los L2? ¿Deberían los usuarios evaluar ahora no solo el riesgo de puente, sino también el riesgo de cierre?

Aquí es donde la idea de “simplemente retirar los fondos” empieza a fallar. Funciona si tus fondos están simplemente depositados en un monedero. No funciona tan bien si están inmovilizados en un mercado de préstamos, una posición en un LP, una caja fuerte o un contrato que aún requiere una transacción más para que puedas retirarlos.

Cuando el secuenciador se detiene, la cadena deja de recibir instrucciones. Es posible que aún tengas una reclamación válida en algún lugar, pero quizá ya no dispongas de una ruta operativa para actuar al respecto. Esa es la parte incómoda: puede que el activo no haya desaparecido, pero la ruta para acceder a él sí puede hacerlo.

Los usuarios deben ir más allá de la seguridad de los puentes. En el caso de los L2 más pequeños, especialmente aquellos con escasa liquidez o ecosistemas experimentales, también habría que plantearse: ¿qué pasaría si esta red dejara de funcionar? ¿Podría salir de ella antes de que eso ocurra?

- ¿Qué ocurre con las reservas de las stablecoins en una red en declive, especialmente al comparar el USDC.e transferido a través de un puente con la emisión nativa mediante un modelo similar al CCTP?

En el caso de las stablecoins “bridged” como el USDC.e, el USDC real se encuentra en un depósito de garantía en Ethereum L1. Si tu USDC.e simplemente está en tu monedero, puede migrarse o reclamarse. Si están bloqueados en un contrato con el que ya nadie puede interactuar, el USDC subyacente sigue ahí, pero el usuario no tiene ninguna forma práctica de acceder a él. El emisor no obtiene ningún dinero «extra» por ello. El respaldo sigue ahí, pero el valor queda, básicamente, atrapado.

Las stablecoins nativas funcionan de manera diferente. En una configuración tipo CCTP, el token se acuña directamente en la L2, y la reserva fiduciaria la mantiene el emisor. Para salir de forma ordenada, es necesario quemar el token en la L2 antes del cierre y acuñarlo en otro lugar. Si el token queda bloqueado en un contrato inactivo, ya no es posible quemarlo en la cadena. Así pues, el emisor se queda con las reservas reales correspondientes a tokens que aún existen, pero en una red que ya no funciona.

En ese momento, el emisor debe decidir qué hacer a continuación: conservar las reservas, aceptar reclamaciones fuera de la cadena con pruebas o, en última instancia, considerar esos tokens como abandonados.

No dejes que el riesgo de infraestructura se convierta en un riesgo para el producto

Innowise ayuda a diseñar infraestructuras Web3 con menos puntos ciegos

- ¿Qué lecciones deberían extraer los equipos que están creando nuevos ecosistemas de rollup del cierre de Polygon zkEVM?

Polygon zkEVM nos recuerda que todo rollup necesita dos hojas de ruta: una para el crecimiento y otra para el cierre seguro. Atraer liquidez es solo la mitad del trabajo. Los equipos también necesitan una forma clara de retirar esa liquidez en caso de que la red llegue a cerrarse.

Esto implica avisar a los usuarios con antelación, mantener el puente abierto el mayor tiempo posible, ofrecer a los usuarios un proceso sencillo para reclamar los saldos de sus monederos y ponerse en contacto con los protocolos DeFi mucho antes de la fecha de cierre. También implica explicar con detalle qué ocurre con los activos transferidos a través del puente, los activos nativos y las monedas estables.

Por encima de todo, los equipos deberían dejar de considerar el TVL como algo que simplemente se puede recoger y trasladar más adelante. Una vez que el secuenciador deja de funcionar, la verdadera pregunta es: ¿cuánta liquidez queda aún por salir en una transacción?

Detrás de todo esto también hay una lección sobre el diseño. Si desmantelar un sistema resulta tan complicado, merece la pena preguntarse con sinceridad, antes del lanzamiento, si la carga de trabajo realmente necesitaba su propia cadena. Muchos casos de uso “a prueba de manipulaciones” se resuelven mejor con una base de datos verificable o un registro de transparencia con un punto de referencia externo. En ese caso, no hay ningún secuenciador que desactivar.

- ¿Qué debería incluir el plan de contingencia mínimo para cualquier L2 antes del lanzamiento de la red principal: comunicación, reclamaciones de puentes, coordinación de DeFi, política de stablecoins o algo más?

Un plan de cierre adecuado de L2 debe detallar todo el proceso, desde la primera advertencia hasta el plazo final para reclamar. Los equipos deben decidir con antelación cuándo se notificará a los usuarios, cuánto tiempo permanecerá abierto el puente, cuándo se realizará la instantánea final, cómo funcionarán las reclamaciones de L1 y qué ocurrirá con los fondos que no se reclamen.

El DeFi merece un plan específico. Los protocolos deben explicar si los usuarios pueden retirar fondos en caso de emergencia, cómo se pueden liquidar las posiciones y qué ocurre con los tokens de LP, las participaciones en las cajas fuertes, las garantías y la deuda si la red deja de procesar transacciones.

Las stablecoins necesitan la misma claridad. Los activos transferidos a través de puentes y los activos emitidos de forma nativa se comportan de manera muy diferente cuando una red deja de funcionar, por lo que los usuarios deben saber exactamente qué normas se aplican a cada token.

- En estas situaciones, ¿qué suele ser lo más difícil: detener técnicamente la red, atribuir legalmente la responsabilidad o resolver económicamente el bloqueo de la liquidez?

Desconectar la red es probablemente la parte más sencilla de todo el proceso. Los verdaderos problemas empiezan cuando se analiza quién sigue teniendo dinero invertido, dónde se encuentra ese dinero y quién tiene derecho a tomar decisiones al respecto.

Desde el punto de vista jurídico, la responsabilidad se vuelve muy difusa en muy poco tiempo. El equipo de L2 gestiona la infraestructura, pero no es propietario de todos los protocolos DeFi que se construyen sobre ella. Desde el punto de vista económico, la situación se complica aún más, ya que la DeFi puede generar varias capas de derechos sobre la misma liquidez subyacente. Si esa liquidez es limitada, está bloqueada o ya se ha comprometido de diferentes formas, algunos derechos simplemente no pueden satisfacerse en su totalidad.

Así pues, la tarea más complicada consiste en encontrar una forma justa de gestionar la liquidez congelada sin pagar dos veces por el mismo activo subyacente, sin crear nuevos pasivos y sin obligar al equipo de infraestructura a actuar como un juez para cada protocolo del ecosistema.

- ¿Cómo crees que afectará este caso a la confianza en las L2 más pequeñas y en los ecosistemas de zk-rollup con un TVL bajo?

Este caso hará que las L2 más pequeñas parezcan mucho menos “seguras por defecto”. Un TVL bajo ya llama la atención. Ahora los usuarios tienen otra pregunta que plantearse: si esta red deja de funcionar, ¿podré realmente salir de ella?

En el caso de los zk-rollups, la confianza dependerá de algo más que la tecnología, las comisiones y la velocidad. La dependencia del secuenciador, las reclamaciones relacionadas con los puentes, las vías de salida de DeFi y la gestión de las stablecoins pasan a formar parte de la lista de aspectos a tener en cuenta. Ahora, un rollup tiene que demostrar que los usuarios pueden salir del sistema con la misma facilidad con la que entraron.

La experiencia de Andrew en acción

Más sobre este tema

Blog

Cómo mover USDT de Tron a EVM sin quedar atrapado por la liquidez

Blog

Top Layer 2 blockchains: encuentre la que mejor se adapte a su proyecto

Blog

¿Qué es un DID? Una guía sobre la identidad digital

Contáctenos

Reserve usted una llamada o rellene usted el siguiente formulario y nos pondremos en contacto con usted cuando hayamos procesado su solicitud.

Nombre

Empresa

Correo electrónico

Teléfono

Mensaje

Envíenos un mensaje de voz

Adjuntar documentos

Cargar archivo

Puede adjuntar 1 archivo de hasta 2 MB. Formatos de archivo válidos: pdf, jpg, jpeg, png.

Al hacer clic en Enviar, autoriza a Innowise a procesar sus datos personales de acuerdo con nuestra política de privacidad. Política de privacidad para proporcionarle información relevante. Al enviar su número de teléfono, acepta que nos pongamos en contacto con usted a través de llamadas de voz, SMS y aplicaciones de mensajería. Pueden aplicarse tarifas de llamadas, mensajes y datos.

También puede enviarnos su solicitud
a contact@innowise.com

¿Qué pasa después?

Una vez recibida y procesada su solicitud, nos pondremos en contacto con usted para detallarle las necesidades de su proyecto y firmar un acuerdo de confidencialidad. Proyecto y firmaremos un acuerdo de confidencialidad.

Tras examinar sus deseos, necesidades y expectativas, nuestro equipo elaborará una propuesta de proyecto con el alcance del trabajo, el tamaño del equipo, el plazo y los costes estimados con el alcance del trabajo, el tamaño del equipo, el tiempo y las estimaciones de costes.

Concertaremos una reunión con usted para hablar de la oferta y concretar los detalles.

Por último, firmaremos un contrato y empezaremos a trabajar en su proyecto de inmediato.