---
title: "Rota de escape de Rollup"
description: "Guia por protocolo sobre rotas de escape de Rollup: os diferentes mecanismos abrangidos pelo termo, suas garantias, dependências e como verificar a saída."
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.
# Rota de escape de Rollup
> Conteúdo apenas educacional; não constitui orientação financeira ou de segurança. Mecanismos de saída, prazos, taxas, permissões de contratos e premissas de disponibilidade de dados variam entre L2 e podem mudar após atualizações.
## Resposta direta
Uma rota de escape de Rollup é um caminho emergencial do protocolo destinado a preservar a capacidade do usuário de sair ou transacionar quando o operador da L2, o sequenciador ou a interface normal falha ou censura. O termo não é padronizado. Conforme o projeto, pode ser uma rota de inclusão forçada pela L1, uma solicitação de saque forçado ou um modo de escape que congela atualizações de estado e permite saques com provas. Esses mecanismos oferecem garantias distintas e não são intercambiáveis.
A rota de escape é um caminho emergencial mais forte, usado quando as atualizações normais de estado param. Ela pode congelar a aplicação e permitir que usuários provem saldos contra uma raiz de estado comprometida. Nenhum desses mecanismos promete saída instantânea, determinado valor do ativo ou imunidade a falhas de contratos e poderes de governança. A garantia real vem do código implantado, da configuração vigente, dos dados de estado disponíveis e da capacidade do usuário de criar e enviar as transações ou provas exigidas.
## Como funciona
- **Identifique a primitiva.** Inclusão forçada, saque forçado e modo de escape resolvem problemas diferentes. A inclusão forçada contorna um sequenciador censor ou indisponível. Uma solicitação de saque forçado obriga o protocolo ou operador a processar a saída ou provar sua invalidade. O modo de escape costuma ser o último recurso: atualizações comuns param e usuários sacam com provas de estado.
- **Entre pela L1.** O usuário envia uma transação ao inbox, portal ou contrato de liquidação da L1 documentado pelo protocolo. Na OP Stack, depósitos da L1 são derivados em blocos da L2 dentro da janela de sequenciamento. Na Arbitrum Nitro, uma mensagem entra na Delayed Inbox e, após o atraso configurado, pode ser forçada ao inbox principal se o sequenciador não a incluir.
- **Aguarde o processamento.** A confirmação na L1 é apenas o primeiro ponto de controle. A solicitação talvez precise integrar a cadeia canônica da L2, ser executada, aparecer em estado provado ou confirmado, passar por período de contestação ou carência e ser finalizada na L1. Uma transação forçada ainda pode reverter por nonce incorreto, Gas insuficiente, calldata errada, restrições do token ou mudança de estado na L2.
- **Cumpra as condições de saída.** StarkEx Spot ilustra um saque forçado e escape reais. O usuário envia `fullWithdrawalRequest`; a aplicação deve atender à solicitação ou provar que é inválida. Se continuar pendente após `FREEZE_GRACE_PERIOD`, é possível pedir o congelamento. O escape exige um caminho de Merkle contra a raiz congelada do cofre, verificação da prova, uma chamada `escape` e a chamada normal on-chain `withdraw`.
- **Verifique a disponibilidade de dados.** Uma raiz de estado é um compromisso, não os saldos ou caminhos de Merkle subjacentes. Quando os dados para reconstruir o estado são publicados na L1, um agente independente pode em princípio montar a prova de saída. Em Validium ou outros projetos com dados off-chain, o usuário pode depender de um comitê ou operador para liberar os dados. Validade da prova e disponibilidade de dados são garantias distintas.
- **Verifique controles e ferramentas.** Examine poderes de pausa, congelamento, atualização e governança; endereços exatos e implementações proxy; ativos aceitos; chaves necessárias; Gas em L1 e L2; software de geração de provas; e interface independente. Um mecanismo correto no papel pode ser impraticável sem dados, ferramentas ou fundos suficientes na L1.
## Exemplo
Suponha que o sequenciador e a interface oficial de um Rollup estejam indisponíveis, mas a L1 continue finalizando. Primeiro, o usuário confirma o ID da cadeia e os contratos canônicos da L1 na documentação oficial. Se houver apenas inclusão forçada, envia uma transação da L1 para a L2 que chama a função de saque na L2 da ponte canônica. Depois acompanha separadamente o envio na L1, a inclusão forçada, a execução na L2, o compromisso de estado, a fase aplicável de contestação ou prova e a finalização na L1. Um envio bem-sucedido na L1 não comprova que a chamada de saque funcionou.
Em um sistema ao estilo StarkEx, a sequência é diferente: envie a solicitação forçada documentada, aguarde o período de carência configurado, confirme se ela foi atendida ou provada inválida e use congelamento e escape apenas quando as condições do contrato forem satisfeitas. O identificador do cofre, a chave e o caminho de Merkle devem corresponder ao estado congelado. Copiar o procedimento da Arbitrum ou OP Stack seria errado, embora todos sejam às vezes chamados de “saque forçado”.
Antes de depender de qualquer rota, ensaie com um valor pequeno enquanto o sistema está saudável. Registre endereços, assinaturas de funções, eventos esperados, temporizadores e hashes. Verifique o estado com outro RPC ou explorador confiável. Nunca informe seed ou chave privada a um site de “saque emergencial” nem envie pagamento extra de “desbloqueio” a suporte ou mensagens diretas.
## Riscos
- O protocolo tem inclusão forçada, mas não função direta de saque forçado.
- A solicitação na L1 foi confirmada, mas a chamada na L2 reverteu ou não foi executada.
- Um período de contestação, prova, carência ou finalização atrasa o acesso.
- Dados de estado ou caminho de Merkle estão indisponíveis, sobretudo com dados off-chain.
- São usados cadeia, contrato, proxy, função ou identificador de cofre incorretos.
- O contrato de saída está pausado, atualizado, congelado incorretamente ou com falha.
- Governança, conselho de segurança ou outro agente privilegiado pode mudar a rota.
- O ativo não é aceito, não é padrão, tem pouca liquidez ou segue regras de margem.
- Alta do Gas na L1 ou falta de Gas nativo impede o envio ou a finalização.
- Interfaces oficiais, RPCs, indexadores ou ferramentas de prova ficam indisponíveis.
- Interface falsa, anúncio ou falso suporte rouba credenciais ou fundos.
- O valor de mercado pode cair durante a demora; saída possível não protege o preço.
## Equívocos comuns
- **Todo Rollup tem a mesma rota de escape.** Nomes, mecanismos e garantias dependem do protocolo; leia documentos e contratos da versão implantada.
- **A inclusão forçada devolve fundos imediatamente à L1.** Ela costuma garantir acesso à ordenação ou execução; o saque da ponte ainda tem ciclo próprio.
- **Um hash na L1 prova que a saída ocorreu.** Ele prova apenas inclusão na L1; execução na L2 e finalização na L1 exigem verificações separadas.
- **Uma prova de validade garante que os dados de saída estejam disponíveis.** Correção da prova e disponibilidade de dados são distintas; dados off-chain criam dependências.
- **A rota emergencial é trustless porque há uma função.** Uso real também depende de permissões, configuração, dados, software, Gas e chaves.
- **Uma rota de escape elimina risco financeiro.** Ela trata falhas de atividade ou censura, não riscos de preço, liquidez, contrato ou comprometimento de chaves.
## Tópicos relacionados
- [Ponte canônica](/pt-br/crypto/canonical-bridge/)
- [Optimistic Rollup](/pt-br/crypto/optimistic-rollup/)
- [Saque forçado em L2](/pt-br/crypto/l2-forced-withdrawal/)
- [Sequenciador](/pt-br/crypto/sequencer/)
- [ZK Rollup](/pt-br/crypto/zk-rollup/)
## Fontes
- [Visão geral do protocolo OP Stack](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification (acessado: 2026-08-21)
- [Arbitrum Nitro: um Optimistic Rollup de segunda geração](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (acessado: 2026-08-21)
- [Saque e escape sem aprovação da aplicação](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation (acessado: 2026-08-21)
- [Disponibilidade de dados](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (acessado: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/rollup-escape-hatch/index.mdx