¿Puedes retirar fondos de Base o Arbitrum si el secuenciador deja de funcionar?

Un rollup puede mantener una ruta de Ethereum abierta para usuarios cuyas transacciones están atascadas en el secuenciador. Esa ruta gestiona la inclusión de transacciones. Recuperar los fondos a Ethereum también depende de si el retiro del rollup puede probarse y completarse bajo las reglas del puente.

Consideremos dos usuarios que tienen ETH, uno en Base y otro en Arbitrum One. Ambos usan el puente oficial, pero intentan salir en momentos diferentes de una interrupción. Un retiro ya está en los registros del rollup. El otro todavía necesita que se acepte una transacción.

Ethereum puede proporcionar una alternativa a la ruta normal del secuenciador. Si eso lleva a cualquiera de los usuarios hasta el final depende del siguiente paso del puente y de si las personas capaces de cambiar o pausar los contratos han actuado.

Un retiro tiene más de un paso

En el funcionamiento ordinario, un usuario comienza enviando una transacción de retiro en el rollup. El secuenciador la ordena con otras transacciones. El retiro del puente puede entonces establecerse en Ethereum una vez que el estado relevante del rollup esté disponible y se cumplan los requisitos aplicables de prueba y espera.

Las dos transacciones pueden parecer una sola acción en una billetera. La primera registra el retiro en el rollup. Una acción posterior puede completarlo en Ethereum. Un usuario que puede ver la primera transacción en un explorador tiene evidencia de que fue incluida, incluso si los fondos aún no están disponibles en Ethereum.

La ruta alrededor del secuenciador

La documentación de transacciones forzadas de Arbitrum describe una ruta a través de su Bandeja de Entrada Retrasada en Ethereum. Una transacción puede esperar allí antes de volverse elegible para inclusión forzada. El período es independiente del tiempo necesario para completar un retiro de Ethereum.

La especificación de derivación de Base describe los depósitos derivados de Ethereum, incluida la ruta del protocolo para la inclusión forzada. La comparación útil es si el usuario puede iniciar la acción necesaria a través de Ethereum, cuánto tiempo puede tardar el protocolo en incluirla y qué aún debe suceder después de la inclusión.

La alternativa puede implicar una tarifa de transacción de Ethereum. También depende de que el usuario o el servicio que actúa por él puedan enviar el mensaje correcto. Una billetera con una conexión rota a su punto de acceso normal puede necesitar una interfaz diferente para usar una ruta de cadena funcional.

Una actualización de emergencia pone a prueba una protección diferente

Una interrupción plantea la pregunta de si una transacción puede llegar al rollup. Una actualización plantea la pregunta de quién puede cambiar los contratos que determinan si el retiro será honrado. Una ruta de transacción forzada no preserva por sí misma las reglas existentes hasta que un usuario pueda completar el retiro.

ETHBEAT enumera Base y Arbitrum One como Etapa 1. Su evaluación no muestra ventana de salida para Base y distingue las actualizaciones regulares de las de emergencia para Arbitrum One. La ruta regular de Arbitrum enumera una ventana de 10 días, mientras que la ruta de emergencia no tiene tal ventana.

Esa diferencia es la razón por la que una calificación de Etapa 1 por sí sola no puede responder cuánto tiempo tiene un usuario para retirarse. Un período de aviso debe considerarse junto con el tiempo necesario para iniciar, probar y finalizar un retiro. El período relevante es el tiempo restante después de contabilizar los pasos que el usuario necesita completar.

Un puente de terceros añade sus propias condiciones

Un puente rápido puede pagar al usuario con la liquidez que ya tiene en Ethereum mientras liquida su propia posición más tarde. Eso puede hacer que el retiro visible sea más rápido en operación normal. También introduce un proveedor cuya liquidez y política operativa importan cuando el rollup está bajo estrés.

El activo también importa. Un saldo emitido a través de un puente de terceros puede depender de los contratos de ese puente incluso si se mantiene en Base o Arbitrum. Una evaluación del mecanismo de salida oficial del rollup no puede por sí sola establecer qué redimirá un emisor externo.

Una comparación justa llevaría el mismo tipo de activo a través de ambos puentes oficiales y registraría los primeros pasos de inclusión, prueba y finalización. Luego compararía qué cambia si el secuenciador se detiene y qué puede hacer una actualización de emergencia antes de que cualquiera de los retiros finalice.

Comenzar con el mismo retiro en ambas redes

Tomemos un usuario que posee ETH nativo en cada red y quiere recuperar el ETH en Ethereum. Usar el mismo activo facilita la comparación porque evita las reglas de redención separadas que pueden aplicarse a los tokens envueltos. El puente oficial aún necesita evidencia de que el retiro comenzó y de que el estado que lo contiene ha sido aceptado bajo las reglas del rollup.

En operación ordinaria, el usuario envía una instrucción en el rollup. Su inclusión produce un registro que el sistema de retiro puede reconocer más tarde. El usuario o una interfaz que actúe por él puede entonces llevar a cabo los pasos requeridos en Ethereum. Los fondos quedan disponibles en Ethereum una vez que el contrato de puente correspondiente ejecuta el retiro.

La billetera puede mostrar varios tipos de progreso. Puede mostrar que el secuenciador aceptó la transacción, que un lote llegó a Ethereum o que un retiro está listo para un paso posterior. Esas etiquetas describen eventos diferentes. Una interfaz que muestra una transacción como confirmada aún puede estar describiendo su estado en el rollup.

Un retiro que comenzó antes de una interrupción también es diferente de uno que el usuario aún no ha iniciado. Si la transacción y el estado necesario para respaldarla ya llegaron a Ethereum, el trabajo restante puede tener lugar allí. Si la única evidencia es una respuesta reciente del secuenciador, el usuario aún necesita los datos y el estado relevantes para atravesar el resto del sistema.

La distinción ayuda a explicar por qué la primera pregunta útil durante una interrupción es dónde se detuvo el retiro. Una transacción de rollup faltante requiere una ruta hacia la inclusión. Un retiro ya registrado en el rollup puede estar esperando la etapa de prueba o finalización. La siguiente acción depende de cuál de esas etapas ha alcanzado la red.

Qué cambia cuando el secuenciador se detiene

El secuenciador normalmente ofrece al usuario una ruta rápida para que una transacción sea ordenada. Si el servicio deja de responder, una transacción enviada puede no aparecer aunque Ethereum siga operando. Una ruta a través de Ethereum da a los usuarios una forma de introducir un mensaje en las entradas del rollup sin esperar a que su endpoint normal vuelva a responder.

En Arbitrum One, Ethereum registra mensajes en la Bandeja de Entrada Retrasada. Un secuenciador puede incluirlos en el curso normal. Si un mensaje permanece allí más allá de la espera aplicable, la ruta de inclusión forzada puede hacerlo parte de la secuencia. La transacción de Ethereum que registra el mensaje y la transacción del rollup que lo ejecuta siguen siendo observaciones separadas.

En Base, los depósitos registrados en Ethereum se convierten en entradas para las reglas de derivación del rollup. El término depósito puede ser engañoso en este contexto porque también se refiere a un tipo de mensaje mediante el cual una transacción de Ethereum puede desencadenar una acción en el rollup. La operación del rollup que el usuario pretende aún debe ejecutarse con éxito después de la inclusión.

Las páginas de proyecto de ETHBEAT describen el retraso bajo las condiciones que modelan. La estimación se aplica al paso de respaldo y puede diferir entre las dos redes. No convierte un puente de rollup a Ethereum en un retiro inmediato. Un pago final aún depende de que el puente acepte el estado resultante y complete sus propios pasos.

El usuario también necesita los medios para enviar la transacción de Ethereum. Alguien cuyo saldo completo está en el rollup puede necesitar acceso a ETH en Ethereum para el respaldo. Una aplicación que gestiona esto para los usuarios en condiciones ordinarias puede enfrentar la misma restricción práctica si depende del endpoint fallido o no expone la ruta de Ethereum.

Un receptor también debe distinguir una solicitud fallida de un envío onchain exitoso que aún no ha surtido efecto. Un hash de transacción de Ethereum establece que el mensaje de respaldo fue enviado si su recibo lo confirma. No establece el resultado de la ejecución posterior en el rollup.

Cuando la red sigue produciendo bloques pero los retiros se estancan

Una red puede producir transacciones mientras otra parte del proceso de retiro está retrasada. Los contratos en Ethereum necesitan un registro reconocido de lo que ocurrió en el rollup. Un retraso en la publicación o el establecimiento de ese estado puede dejar a los usuarios esperando después de que el secuenciador ya haya devuelto un resultado exitoso.

La distinción proviene de las diferentes tareas involucradas. El secuenciador ordena las transacciones. La disponibilidad de datos permite a otras partes reconstruir lo que se ordenó. Los sistemas de propuesta y prueba establecen qué estado resultante deben reconocer los contratos de Ethereum. Un servicio puede realizar una de esas tareas mientras otra está en espera.

Para un observador, un explorador de bloques que sigue mostrando actividad es, por lo tanto, una prueba incompleta. El observador puede comparar la inclusión reciente de transacciones en el rollup con los registros de Ethereum del estado o las reclamaciones de las que dependen los retiros. Una brecha entre ambos ayuda a identificar si el cuello de botella está antes o después.

ETHBEAT distingue el fallo del secuenciador del fallo del proponente porque el respaldo para uno no resuelve necesariamente el otro. Sus categorías son una forma de ver qué actor puede intervenir cuando el operador habitual está ausente. Deben leerse junto con las condiciones y el retraso descritos para cada proyecto.

El mismo principio se aplica a los informes de servicio degradado. Un front end puede no estar disponible mientras los contratos siguen siendo invocables. Un explorador puede retrasarse mientras la cadena avanza. Una interfaz de puente puede deshabilitar los envíos durante un incidente incluso si otra interfaz aún puede llegar a los contratos. Cada caso debe verificarse en la capa donde ocurre.

Crypto.news informó que Base experimentó una interrupción de 33 minutos en agosto de 2025. Ese incidente proporciona un caso para preguntar qué acciones del usuario se interrumpieron y qué alternativas permanecieron disponibles. Su duración no establece cómo afectaría a los retiros un evento futuro que involucre un componente diferente.

La espera tras la inclusión pertenece al puente

Una vez que un retiro está en el estado del rollup, todavía tiene que cumplir las condiciones de prueba y finalización del puente. Los diseños optimistas dan a los participantes la oportunidad de impugnar una reclamación incorrecta. El retraso puede ser una parte deliberada de ese proceso en lugar de una señal de que el secuenciador está desconectado.

El tiempo comienza a partir del evento definido por el puente, que no necesariamente coincide con el instante en que el usuario hace clic por primera vez en retirar. La espera puede depender de cuándo esté disponible la salida o reclamación relevante y de si se ha enviado la prueba requerida. Un usuario puede pasar tiempo esperando antes de que el período de impugnación que aparece en la descripción de un puente empiece a importar.

La cuenta atrás de una billetera puede, por lo tanto, describir una estimación en lugar de una fecha de pago incondicional. Puede depender de que continúen la publicación normal y la actividad de prueba. Si el estado se disputa, el tiempo hasta la finalidad puede cambiar aunque la instrucción de retiro ya aparezca en el rollup.

El sistema de prueba de Arbitrum y el diseño de prueba de Base tienen detalles de implementación diferentes. La comparación práctica para un usuario es quién puede enviar una reclamación, quién puede impugnarla y qué sucede si el actor que normalmente envía la siguiente reclamación se detiene. La misma palabra, retiro, abarca secuencias diferentes en esos sistemas.

El retraso también afecta las comparaciones con puentes de terceros. Un servicio que puede pagar al usuario inmediatamente en Ethereum está utilizando su propia liquidez o una red separada de participantes. El pago rápido puede completarse antes de que el retiro oficial detrás de él sea elegible para liquidarse.

El usuario entonces depende de la capacidad y la voluntad del tercero de realizar el pago. Si la liquidez se agota o el proveedor deja de aceptar solicitudes, la velocidad cotizada para las operaciones habituales puede dejar de aplicarse. Las protecciones de salida del rollup subyacente y las condiciones de pago del servicio comercial siguen siendo distintas.

La cuestión de la actualización se refiere a qué reglas se aplicarán mañana

Un fallo del secuenciador impide que un usuario llegue a la ruta normal hacia la cadena. Una actualización puede cambiar las reglas que rigen la propia ruta. Eso hace que el retraso de la actualización sea relevante incluso si el secuenciador está sano y todas las transacciones se están aceptando.

En un proceso de gobernanza regular, una actualización anunciada puede tener que pasar por un retraso antes de poder entrar en vigor. Durante ese período, los usuarios pueden evaluar la propuesta y comenzar a salir si el puente permanece abierto. La ventana de salida útil es lo que queda después de tener en cuenta los pasos normales de retiro.

En una vía de emergencia, los firmantes designados a veces pueden actuar sin el retraso regular. Eso puede ayudar a responder rápidamente a un incidente de seguridad. También otorga a los usuarios una garantía diferente de la que ven cuando la gobernanza sigue su ruta ordinaria.

La evaluación de Arbitrum One indica diez días para la vía regular y ninguna ventana de salida para una actualización de emergencia. La evaluación de Base no indica ninguna ventana de salida. La calificación principal de etapa puede ser la misma mientras esos poderes difieren en la práctica.

Una pausa es otra acción que debe distinguirse de una actualización. Una pausa puede detener una operación específica bajo las reglas contractuales existentes. Una actualización puede reemplazar o cambiar esas reglas. El firmante y el umbral requeridos para una pausa pueden diferir del firmante y el umbral para una nueva implementación.

Crypto.news cubrió un ejemplo concreto de autoridad de emergencia cuando el Consejo de Seguridad de Arbitrum movió fondos vinculados al hackeo de Binance. Ese caso concernía a fondos identificados y a un cambio contractual temporal. Su relevancia aquí es que la autoridad de emergencia puede ejercerse en la práctica y puede ser separada del proceso posterior que determina a dónde van los fondos.

Cómo leer la Etapa 1 sin confundirla con una garantía de salida

Las clasificaciones por etapas agrupan varias dimensiones de un rollup. Indican hasta qué punto un sistema se ha alejado de la dependencia de operadores o consejos según los criterios del marco. Una etiqueta de etapa no puede proporcionar la respuesta para cada modo de fallo porque cada protección aborda una tarea diferente.

Para un usuario, los detalles importantes son las condiciones que se aplican a su transacción. Un mecanismo de respaldo del secuenciador importa si la transacción no puede incluirse. La capacidad de proponer estado importa si el proponente habitual del rollup se detiene. Un retraso de actualización importa si alguien puede cambiar lo que hará el puente mientras el usuario espera.

La disponibilidad de datos pertenece a la misma comparación. Si los datos necesarios para reconstruir el rollup son accesibles en Ethereum, otro participante tiene una base para seguir la cadena. La existencia de los datos no realiza por sí misma una prueba ni envía una transacción de Ethereum en nombre del usuario.

Base y Arbitrum One pueden ofrecer ambos una ruta a través de Ethereum para un problema del secuenciador mientras conservan permisos diferentes en torno a las actualizaciones. Una evaluación práctica registra ambos en lugar de promediarlos en una única puntuación. Un usuario que intenta salir necesita el paso relevante más débil para el evento que está enfrentando.

Los supuestos también varían según el token. El ETH nativo puede seguir las propias reglas del puente oficial. Un token que llegó a través de un contrato de terceros puede añadir controles del emisor o del puente. Dos carteras en el mismo rollup pueden enfrentar condiciones de redención diferentes incluso cuando sus interfaces muestran ambos saldos en los mismos términos en dólares.

El incidente del puente Ankr proporciona un ejemplo separado de cómo la lógica del puente puede determinar si un retiro es válido. Concernía a un sistema diferente. Su relevancia es la distinción entre la actividad en una cadena y las reglas que el puente utiliza para aceptar mensajes y liberar activos.

Qué puede establecer una comparación de salida

Compare dos usuarios que inician retiros ordinarios antes de una interrupción del secuenciador. Si cada retiro ya forma parte del estado disponible para el puente en Ethereum, los pasos restantes dependen del proceso de prueba y finalización. La interrupción puede tener poco efecto directo sobre un retiro ya madurado si la ejecución de Ethereum sigue disponible.

Ahora adelante la interrupción. Ninguno de los usuarios tiene una transacción de retiro incluida. Ambos necesitan llegar a la ruta del lado de Ethereum del rollup o esperar el servicio normal. El tiempo hasta la inclusión puede diferir, y la propia espera del puente viene después.

Por último, imaginemos una acción contractual de emergencia mientras los retiros están pendientes. La evidencia relevante se convierte en la autoridad que respalda la acción, los contratos exactos afectados y qué pasos permite la nueva configuración. Es posible que una transacción incluida previamente aún necesite que el puente la reconozca según las reglas vigentes cuando el usuario intenta finalizar.

Estos casos muestran por qué una comparación justa comienza con el mismo estado. Un usuario que envió un mensaje a Ethereum pero aún no ha visto la ejecución del rollup no debería compararse directamente con alguien cuyo prueba de puente ya fue aceptada. Los relojes comienzan en eventos diferentes.

Crypto.news ha informado sobre los esfuerzos para hacer que los rollups de Ethereum funcionen juntos. Una interfaz más fluida puede ocultar varios pasos en una transacción normal. Bajo estrés, el usuario se beneficia de saber qué partes de la operación tienen lugar en qué cadena y quién es responsable de cada parte.

La cobertura de Crypto.news sobre la propuesta de recuperación de Arbitrum vinculada a Binance también muestra por qué una acción de gobernanza debe leerse junto con la transacción que autoriza. Una propuesta describe el resultado previsto. Los registros de Ethereum y del rollup muestran cuándo y dónde se ejecutó.

Una ruta de salida es útil solo en la medida en que un tenedor pueda usarla desde su posición actual. El registro más claro identifica el activo, la cadena en la que se encuentra, la transacción ya completada y la parte o contrato que controla el siguiente paso. Ese registro le dice al usuario si la espera restante pertenece al secuenciador, al puente o a una autoridad capaz de cambiar cualquiera de los dos.

Por qué una prueba más rápida no necesariamente acorta cada salida

La actualización Azul de Base introdujo nuevas opciones de prueba. Crypto.news informó sobre un posible camino hacia retiros de un día. Un objetivo o una capacidad de prueba debe distinguirse del tiempo de retiro con el que un usuario particular puede contar bajo la configuración activa.

Una prueba puede ayudar a establecer el estado del que depende un retiro. El puente aún puede aplicar otras condiciones antes de liberar fondos. La secuencia también puede variar según qué ruta de prueba use la red y qué sucede cuando esa ruta no está disponible.

Por lo tanto, una comparación de salidas debe indicar la ruta que está midiendo. Una ruta optimista puede tener un período de desafío. Una ruta que use una prueba diferente puede acortar parte del proceso. Un riesgo de actualización se refiere a si los contratos o permisos que rigen cualquiera de las dos rutas pueden cambiar antes de que finalice.

Un retiro de Ethereum también requiere una transacción que pueda enviarse y ejecutarse en Ethereum. Un sitio de terceros puede ofrecerse a realizar ese paso, pero su capacidad para aceptar una solicitud es independiente de si el contrato oficial puede procesarla. Un usuario que ve que la acción está disponible aún necesita una billetera o un servicio capaz de enviarla.

La distinción se vuelve importante si el usuario mantiene activos en nombre de una aplicación o un cliente. Una tesorería puede requerir varias aprobaciones antes de cualquier acción en Ethereum. Un usuario común puede necesitar una conexión de billetera y gas. El tiempo de salida disponible del protocolo y el tiempo que la persona necesita para actuar pueden diferir.

Qué puede mostrar el registro público después de una interrupción

Un relato de incidente puede comenzar con la última respuesta normal del secuenciador y la primera transacción retrasada. Luego puede identificar si los datos y el estado continuaron llegando a Ethereum. Los registros pueden ayudar a explicar por qué algunos usuarios vieron una interrupción mientras otros aún podían finalizar retiros anteriores.

La línea de tiempo más útil también nombra la aplicación y el activo involucrado. Una billetera que informa saldos desactualizados es diferente de un puente que se niega a aceptar una transacción de finalización. Un proveedor de terceros que pausa un pago es diferente del puente oficial que cambia sus reglas.

La cobertura de Crypto.news sobre una intervención de emergencia en Arbitrum ilustra la necesidad de separar una acción realizada por un consejo del proceso de gobernanza que sigue. La existencia de un registro en Ethereum puede establecer que ocurrió una acción contractual. No elimina la necesidad de leer qué autoridad la realizó y qué afectó.

La respuesta directa a la pregunta del retiro depende de cuándo ocurre la falla. Antes de la inclusión, observe el mecanismo de respaldo de Ethereum y el retraso asociado. Después de la inclusión, observe los requisitos de estado, prueba y finalización. Durante un cambio de emergencia, la autoridad para pausar o modificar contratos se vuelve decisiva incluso si los otros sistemas están funcionando.

Un usuario también puede tener varios retiros en diferentes puntos de esa secuencia. Uno puede estar listo para completarse mientras otro aún espera ser incluido. Un aviso de interrupción que da un tiempo de recuperación esperado no puede resolver el estado de ambos.

El recibo de retiro es la verificación final

Una interfaz de puente puede etiquetar un retiro como listo antes de que el usuario haya enviado la transacción para completarlo. El recibo de la transacción de Ethereum es un registro separado. Para ETH nativo, el destinatario también puede verificar que la transferencia llegó a la dirección prevista y que el destinatario puede usarla.

Esa distinción importa cuando un usuario reintenta una acción tras una interrupción. Dos intentos de enviar una instrucción pueden producir mensajes diferentes o solo una transacción aceptada, dependiendo de cómo se hicieron las solicitudes. El historial de una billetera puede ayudar al usuario a identificar qué mensaje reconoce el puente antes de intentar el siguiente paso.

Un rollup y un puente también pueden recuperarse en calendarios diferentes. El secuenciador puede reanudarse mientras los retiros más antiguos siguen esperando estado o prueba. La reaparición de nuevas transacciones del rollup es evidencia de recuperación del servicio para el ordenamiento, pero los usuarios que esperan recibir ETH en Ethereum todavía necesitan verificar su propio estado de finalización.

El mismo principio se aplica a un aviso de actualización. Un anuncio puede decir que un puente está pausado sin cambiar lo que el rollup sigue procesando. Los usuarios necesitan identificar si la pausa afecta la iniciación, la prueba, la finalización u otra operación. Un solo aviso puede importar de manera diferente para los tenedores en distintos puntos del proceso.

Para los dos usuarios de la comparación, la evidencia final es la misma. Sus retiros oficiales por el puente están completos cuando Ethereum registra la liberación de ETH al destinatario previsto. Todo lo anterior les indica qué parte de la ruta está funcionando y qué queda por suceder.

Qué observar

• Estado del secuenciador: Un aviso de estado y los registros de transacciones acumuladas pueden mostrar cuándo se detuvo y se reanudó el ordenamiento normal.
• Bandeja de entrada de Ethereum: Un recibo exitoso de Ethereum puede establecer que el mensaje de respaldo fue enviado y cuándo pasó a ser elegible para su inclusión.
• Publicación del estado: Los registros de Ethereum pueden mostrar si el puente tiene la reclamación o la salida que necesita para procesar el retiro.
• Acciones de emergencia: Los firmantes autorizantes, los contratos afectados y el momento de la transacción determinan si una pausa o una actualización cambió la ruta del usuario.
• Respaldo de activos: El emisor del token y el puente determinan si la comparación oficial de retiros se aplica a ese saldo.

Preguntas frecuentes