---
title: "Retiro forzado de L2"
description: "Guía por protocolo sobre inclusión forzada, retiro forzado y vías de escape: qué garantiza cada mecanismo, de qué depende y cómo verificar una salida."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retiro forzado de L2

> Solo con fines educativos; no constituye asesoramiento financiero ni de seguridad. Los mecanismos de salida, plazos, comisiones, permisos de contratos y supuestos de disponibilidad de datos varían según la L2 y pueden cambiar tras una actualización.

<a id="answer"></a>

## Respuesta directa

Un retiro forzado de L2 es una ruta del protocolo que permite iniciar o completar una salida sin la aprobación del operador de L2. El término no está estandarizado. En algunos sistemas significa enviar una solicitud de retiro directamente a un contrato de L1; en otros, la única primitiva disponible es la inclusión forzada, que solo garantiza que una transacción originada en L1 entre en la cola de ejecución de L2. Después aún debe seguirse el flujo normal de retiro y finalización del puente canónico.

Una vía de escape es una ruta de emergencia más fuerte para cuando se detienen las actualizaciones normales de estado. Puede congelar la aplicación y permitir que los usuarios demuestren sus saldos contra una raíz de estado comprometida. Ningún mecanismo promete salida instantánea, un valor concreto del activo ni protección frente a fallos de contratos o poderes de gobernanza. La garantía real depende del código desplegado, la configuración vigente, los datos de estado disponibles y la capacidad del usuario para construir y enviar las transacciones o pruebas requeridas.

<a id="mechanism"></a>

## Cómo funciona

- **Identificar la primitiva.** La inclusión forzada, el retiro forzado y el modo de escape resuelven problemas distintos. La inclusión forzada evita un secuenciador censor o inactivo. Una solicitud de retiro forzado obliga al protocolo u operador a procesar la salida o demostrar que es inválida. El modo de escape suele ser el último recurso: cesan las actualizaciones normales y se retira con pruebas de estado.
- **Entrar por L1.** El usuario envía una transacción al buzón, portal o contrato de liquidación de L1 documentado por el protocolo. En OP Stack, los depósitos de L1 se derivan en bloques de L2 dentro de la ventana de secuenciación. En Arbitrum Nitro, un mensaje puede entrar en Delayed Inbox y, tras el retraso configurado, forzarse al buzón principal si el secuenciador no lo incluyó.
- **Esperar el procesamiento.** La confirmación en L1 es solo el primer control. La solicitud quizá deba integrarse en la cadena canónica de L2, ejecutarse, aparecer en un estado probado o confirmado, superar un período de impugnación o gracia y finalizar en L1. Una transacción forzada todavía puede revertirse por nonce incorrecto, Gas insuficiente, calldata errónea, restricciones del token o cambios de estado en L2.
- **Cumplir las condiciones de salida.** StarkEx Spot ilustra un retiro forzado y escape reales. El usuario envía `fullWithdrawalRequest`; la aplicación debe cumplirlo o demostrar que es inválido. Si sigue pendiente después de `FREEZE_GRACE_PERIOD`, puede solicitarse la congelación. Escapar exige una ruta de Merkle contra la raíz congelada de la bóveda, verificar la prueba, llamar a `escape` y después a la función normal en cadena `withdraw`.
- **Comprobar la disponibilidad de datos.** Una raíz de estado es un compromiso, no contiene por sí sola los saldos ni las rutas de Merkle. Si los datos para reconstruir el estado se publican en L1, un tercero independiente puede en principio crear la prueba de salida. En Validium u otros diseños con datos fuera de cadena, el usuario puede depender de que un comité u operador publique los datos. Validez de pruebas y disponibilidad de datos son garantías diferentes.
- **Comprobar controles y herramientas.** Revise poderes de pausa, congelación, actualización y gobernanza; direcciones exactas y sus implementaciones proxy; activos admitidos; claves requeridas; Gas de L1 y L2; software de pruebas; e interfaces independientes. Un mecanismo correcto sobre el papel puede ser impracticable sin datos, herramientas o fondos suficientes en L1.

<a id="example"></a>

## Ejemplo

Supongamos que el secuenciador y la interfaz oficial de un Rollup no están disponibles, pero L1 sigue finalizando. El usuario verifica primero el ID de cadena y los contratos canónicos de L1 en la documentación oficial. Si solo existe inclusión forzada, envía una transacción de L1 a L2 que llama a la función de retiro en L2 del puente canónico. Luego sigue por separado el envío en L1, la inclusión forzada, la ejecución en L2, el compromiso de estado, la fase de impugnación o prueba y la finalización en L1. Un envío exitoso en L1 no demuestra que la llamada de retiro funcionó.

En un sistema tipo StarkEx la secuencia cambia: se envía la solicitud forzada documentada, se espera el período de gracia configurado, se verifica si fue atendida o declarada inválida y solo se usa la congelación y el escape si se cumplen las condiciones del contrato. El identificador de bóveda, la clave y la ruta de Merkle deben coincidir con el estado congelado. Copiar el procedimiento de Arbitrum u OP Stack sería incorrecto aunque los tres se describan a veces como “retiros forzados”.

Antes de depender de una ruta, ensáyela con un importe pequeño mientras el sistema funciona. Registre direcciones de contratos, firmas de funciones, eventos esperados, temporizadores y hashes de transacciones. Verifique el estado con otro RPC o explorador fiable. Nunca introduzca una frase semilla o clave privada en una web de “retiro de emergencia” ni envíe un pago extra de “desbloqueo” a cuentas de soporte o mensajes privados.

<a id="risks"></a>

## Riesgos

- El protocolo ofrece inclusión forzada, pero no una función directa de retiro forzado.
- La solicitud de L1 está confirmada, pero la llamada de L2 revirtió o aún no se ejecutó.
- Un período de impugnación, prueba, gracia o finalización retrasa el acceso a los fondos.
- Faltan datos de estado o una ruta de Merkle, sobre todo con disponibilidad fuera de cadena.
- Se usa la cadena, contrato, implementación proxy, función o bóveda equivocados.
- El contrato de salida está pausado, actualizado, mal congelado o afectado por un fallo.
- La gobernanza, un consejo de seguridad u otro actor privilegiado puede cambiar la salida.
- El activo no está admitido, no es estándar, carece de liquidez o tiene reglas de margen.
- Un pico de Gas en L1 o la falta de Gas nativo impide enviar o finalizar.
- Las interfaces, RPC, indexadores o herramientas de pruebas no están disponibles.
- Una interfaz falsa, anuncio o falso soporte roba credenciales o fondos.
- El valor de mercado puede caer durante la demora; poder salir no protege el precio.

<a id="misconceptions"></a>

## Errores comunes

- **El “retiro forzado” tiene un flujo universal.** Los nombres y garantías dependen del protocolo; lea los contratos y documentos de la versión desplegada.
- **La inclusión forzada devuelve de inmediato los fondos a L1.** Suele garantizar acceso al ordenamiento o ejecución; el retiro del puente conserva su propio ciclo.
- **Un hash de L1 demuestra que la salida tuvo éxito.** Solo demuestra inclusión en L1; la ejecución en L2 y la finalización en L1 se revisan aparte.
- **Una prueba de validez garantiza que los datos de salida estén disponibles.** La corrección de la prueba y la disponibilidad de datos son distintas; los datos fuera de cadena añaden dependencias.
- **La ruta de emergencia carece de confianza porque existe una función.** Su uso también depende de permisos, configuración, datos, software, Gas y claves.
- **Una vía de escape elimina el riesgo financiero.** Atiende fallos de actividad o censura, no riesgos de precio, liquidez, contratos o robo de claves.

<a id="related"></a>

## Temas relacionados

- [Puente canónico](/es/crypto/canonical-bridge/)
- [Optimistic Rollup](/es/crypto/optimistic-rollup/)
- [Vía de escape de Rollup](/es/crypto/rollup-escape-hatch/)
- [Secuenciador](/es/crypto/sequencer/)
- [ZK Rollup](/es/crypto/zk-rollup/)

<a id="sources"></a>

## Fuentes

- [Descripción general del protocolo OP Stack](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification (consultado: 2026-08-21)
- [Arbitrum Nitro: un Optimistic Rollup de segunda generación](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultado: 2026-08-21)
- [Retirar y escapar sin aprobación de la aplicación](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation (consultado: 2026-08-21)
- [Disponibilidad de datos](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (consultado: 2026-08-21)

Source: https://wiki.fcontext.com/es/crypto/l2-forced-withdrawal/index.mdx