Dá para sacar da Base ou da Arbitrum se o sequencer cair?

Um rollup pode manter uma rota Ethereum aberta para usuários cujas transações estão travadas no sequenciador. Essa rota lida com a inclusão de transações. Recuperar fundos para o Ethereum também depende de a retirada do rollup poder ser provada e concluída sob as regras da bridge.

Considere dois usuários que possuem ETH, um na Base e outro na Arbitrum One. Ambos usam a bridge oficial, mas tentam sair em momentos diferentes de uma interrupção. Uma retirada já está nos registros do rollup. A outra ainda precisa que uma transação seja aceita.

O Ethereum pode fornecer uma alternativa à rota normal do sequenciador. Se isso leva qualquer um dos usuários até o fim depende do próximo passo da bridge e de as pessoas capazes de alterar ou pausar os contratos terem agido.

Uma retirada tem mais de uma etapa

Em operação normal, um usuário começa enviando uma transação de retirada no rollup. O sequenciador a ordena com outras transações. A retirada pela bridge pode então ser estabelecida no Ethereum assim que o estado relevante do rollup estiver disponível e os requisitos aplicáveis de prova e espera forem atendidos.

As duas transações podem parecer uma única ação em uma carteira. A primeira registra a retirada no rollup. Uma ação posterior pode concluí-la no Ethereum. Um usuário que consegue ver a primeira transação em um explorador tem evidência de que ela foi incluída, mesmo que os fundos ainda não estejam disponíveis no Ethereum.

A rota em torno do sequenciador

A documentação de transações forçadas da Arbitrum descreve uma rota através de sua Delayed Inbox no Ethereum. Uma transação pode esperar lá antes de se tornar elegível para inclusão forçada. O período é separado do tempo necessário para concluir uma retirada no Ethereum.

A especificação de derivação da Base descreve depósitos derivados do Ethereum, incluindo a rota do protocolo para inclusão forçada. A comparação útil é se o usuário pode iniciar a ação necessária através do Ethereum, quanto tempo o protocolo pode levar para incluí-la e o que ainda precisa acontecer após a inclusão.

O fallback pode envolver uma taxa de transação no Ethereum. Também depende de o usuário ou o serviço que age em seu nome conseguir enviar a mensagem correta. Uma carteira com conexão quebrada ao seu endpoint normal pode precisar de uma interface diferente para usar uma rota de cadeia funcional.

Uma atualização de emergência testa uma proteção diferente

Uma interrupção levanta uma questão sobre se uma transação pode entrar no rollup. Uma atualização levanta uma questão sobre quem pode alterar os contratos que determinam se a retirada será honrada. Uma rota de transação forçada não preserva por si só as regras existentes até que um usuário possa concluir a retirada.

A ETHBEAT lista Base e Arbitrum One como Estágio 1. Sua avaliação não mostra janela de saída para a Base e distingue atualizações regulares de emergência para a Arbitrum One. O caminho regular da Arbitrum lista uma janela de 10 dias, enquanto o caminho de emergência não tem tal janela.

Essa diferença é o motivo pelo qual uma classificação de Estágio 1 sozinha não pode responder quanto tempo um usuário tem para sair. Um período de aviso precisa ser considerado junto com o tempo necessário para iniciar, provar e finalizar uma retirada. O período relevante é o tempo restante após contabilizar as etapas que o usuário precisa concluir.

Uma ponte de terceiros adiciona suas próprias condições

Uma ponte rápida pode pagar o usuário a partir da liquidez que já possui na Ethereum enquanto liquida sua própria posição depois. Isso pode tornar a retirada visível mais rápida em operação normal. Também introduz um provedor cuja liquidez e política operacional importam quando o rollup está sob estresse.

O ativo também importa. Um saldo emitido por meio de uma ponte de terceiros pode depender dos contratos dessa ponte mesmo que seja mantido na Base ou na Arbitrum. Uma avaliação do mecanismo oficial de saída do rollup não pode, por si só, estabelecer o que um emissor externo resgatará.

Uma comparação justa levaria o mesmo tipo de ativo pelas duas pontes oficiais e registraria as etapas de primeira inclusão, prova e finalização. Em seguida, compararia o que muda se o sequenciador parar e o que uma atualização de emergência pode fazer antes que qualquer uma das retiradas seja concluída.

Comece com a mesma retirada nas duas redes

Considere um usuário que detém ETH nativo em cada rede e quer o ETH de volta na Ethereum. Usar o mesmo ativo facilita a comparação porque evita as regras de resgate separadas que podem se aplicar a tokens encapsulados. A ponte oficial ainda precisa de evidência de que a retirada começou e de que o estado que a contém foi aceito sob as regras do rollup.

Em operação comum, o usuário envia uma instrução no rollup. Sua inclusão produz um registro que o sistema de retirada pode reconhecer posteriormente. O usuário ou uma interface agindo em seu nome pode então executar as etapas necessárias na Ethereum. Os fundos ficam disponíveis na Ethereum assim que o contrato de ponte relevante executa a retirada.

A carteira pode mostrar vários tipos de progresso. Ela pode mostrar que o sequenciador aceitou a transação, que um lote chegou à Ethereum ou que uma retirada está pronta para uma etapa posterior. Esses rótulos descrevem eventos diferentes. Uma interface que mostra uma transação como confirmada ainda pode estar descrevendo seu status no rollup.

Uma retirada iniciada antes de uma interrupção também é diferente de uma que o usuário ainda precisa iniciar. Se a transação e o estado necessários para sustentá-la já chegaram à Ethereum, o trabalho restante pode ocorrer lá. Se a única evidência é uma resposta recente do sequenciador, o usuário ainda precisa dos dados e do estado relevantes para atravessar o restante do sistema.

A distinção ajuda a explicar por que a primeira pergunta útil durante uma interrupção é onde a retirada parou. Uma transação de rollup ausente exige uma rota para inclusão. Uma retirada já registrada no rollup pode estar aguardando a etapa de prova ou finalização. A próxima ação depende de qual dessas etapas a rede alcançou.

O que muda quando o sequenciador para

O sequenciador normalmente oferece ao usuário uma rota rápida para ter uma transação ordenada. Se o serviço parar de responder, uma transação enviada pode não aparecer mesmo que a Ethereum continue operando. Uma rota pela Ethereum oferece aos usuários uma maneira de inserir uma mensagem nas entradas do rollup sem esperar que seu endpoint normal volte.

Na Arbitrum One, a Ethereum registra mensagens na Delayed Inbox. Um sequenciador pode incluí-las no curso normal. Se uma mensagem permanecer lá além da espera aplicável, a rota de inclusão forçada pode torná-la parte da sequência. A transação na Ethereum que registra a mensagem e a transação do rollup que a executa permanecem observações separadas.

Na Base, os depósitos registrados na Ethereum tornam-se entradas para as regras de derivação do rollup. O termo depósito pode ser enganoso nesse contexto porque também se refere a um tipo de mensagem por meio da qual uma transação na Ethereum pode acionar uma ação no rollup. A operação pretendida pelo usuário no rollup ainda precisa ser executada com sucesso após a inclusão.

As páginas de projeto da ETHBEAT descrevem o atraso sob as condições que modelam. A estimativa se aplica à etapa de fallback e pode diferir entre as duas redes. Ela não transforma uma ponte de rollup para Ethereum em uma retirada imediata. Um pagamento final ainda depende de a ponte aceitar o estado resultante e concluir suas próprias etapas.

O usuário também precisa dos meios para enviar a transação na Ethereum. Alguém cujo saldo inteiro está no rollup pode precisar de acesso a ETH na Ethereum para o fallback. Uma aplicação que lida com isso para usuários em condições normais pode enfrentar a mesma restrição prática se depender do endpoint que falhou ou não expuser a rota pela Ethereum.

Um destinatário também deve distinguir uma solicitação falha de uma submissão onchain bem-sucedida que ainda não entrou em vigor. Um hash de transação da Ethereum estabelece que a mensagem de fallback foi submetida se o seu recibo a confirmar. Não estabelece o resultado da execução posterior no rollup.

Quando a rede continua produzindo blocos mas os saques ficam parados

Uma rede pode produzir transações enquanto outra parte do processo de saque está atrasada. Os contratos na Ethereum precisam de um registo reconhecido do que aconteceu no rollup. Um atraso na publicação ou no estabelecimento desse estado pode deixar os utilizadores à espera depois de o sequenciador já ter devolvido um resultado bem-sucedido.

A distinção vem das diferentes funções envolvidas. O sequenciador ordena as transações. A disponibilidade de dados permite que outras partes reconstruam o que foi ordenado. Os sistemas de proposta e de prova estabelecem qual o estado resultante que os contratos da Ethereum devem reconhecer. Um serviço pode desempenhar uma dessas funções enquanto outra está à espera.

Para um observador, um explorador de blocos que ainda mostra atividade é, portanto, um teste incompleto. O observador pode comparar a inclusão recente de transações no rollup com os registos da Ethereum relativos ao estado ou às reivindicações das quais os saques dependem. Uma lacuna entre os dois ajuda a identificar se o estrangulamento é anterior ou posterior.

A ETHBEAT distingue a falha do sequenciador da falha do proponente porque o fallback de uma não resolve necessariamente a outra. As suas categorias são uma forma de ver qual ator pode intervir quando o operador habitual está ausente. Devem ser lidas com as condições e o atraso descritos para cada projeto.

O mesmo princípio aplica-se a relatos de serviço degradado. Um front end pode estar indisponível enquanto os contratos continuam a poder ser chamados. Um explorador pode ficar atrasado enquanto a cadeia avança. Uma interface de bridge pode desativar submissões durante um incidente mesmo que outra interface ainda consiga alcançar os contratos. Cada caso deve ser verificado na camada onde ocorre.

A Crypto.news noticiou que a Base sofreu uma interrupção de 33 minutos em agosto de 2025. Esse incidente fornece um caso para perguntar quais ações dos utilizadores foram interrompidas e quais alternativas permaneceram disponíveis. A sua duração não estabelece como um evento futuro envolvendo um componente diferente afetaria os saques.

A espera após a inclusão pertence à bridge

Depois de um saque estar no estado do rollup, ainda tem de cumprir as condições de prova e finalização da bridge. Os designs otimistas dão aos participantes a oportunidade de contestar uma reivindicação incorreta. O atraso pode ser uma parte deliberada desse processo e não um sinal de que o sequenciador está offline.

A contagem do tempo começa a partir do evento definido pela bridge, que não tem de coincidir com o instante em que o utilizador clica pela primeira vez em sacar. A espera pode depender de quando o output ou a reivindicação relevante está disponível e se a prova exigida foi submetida. Um utilizador pode passar tempo à espera antes de o período de contestação que aparece na descrição de uma bridge começar a importar.

A contagem decrescente de uma carteira pode, portanto, descrever uma estimativa e não uma data de pagamento incondicional. Pode depender de a publicação normal e a atividade de prova continuarem. Se o estado for disputado, o tempo até à finalidade pode mudar mesmo que a instrução de saque já apareça no rollup.

O sistema de prova da Arbitrum e o design de prova da Base têm detalhes de implementação diferentes. A comparação prática para um utilizador é quem pode submeter uma reivindicação, quem a pode contestar e o que acontece se o ator que normalmente submete a reivindicação seguinte parar. A mesma palavra, saque, abrange sequências diferentes nesses sistemas.

O atraso também afeta as comparações com bridges de terceiros. Um serviço que pode pagar ao utilizador imediatamente na Ethereum está a usar a sua própria liquidez ou uma rede separada de participantes. O pagamento rápido pode ser concluído antes de o saque oficial por trás dele ser elegível para liquidação.

O utilizador passa então a depender da capacidade e da vontade do terceiro de efetuar o pagamento. Se a liquidez se esgotar ou o fornecedor deixar de aceitar pedidos, a rapidez anunciada para transações rotineiras pode deixar de se aplicar. As proteções de saída do rollup subjacente e as condições de pagamento do serviço comercial continuam distintas.

A questão da atualização diz respeito a quais regras se aplicam amanhã

Uma falha do sequenciador impede que um usuário alcance a rota normal para a cadeia. Uma atualização pode alterar as regras que regem a própria rota. Isso torna o atraso da atualização relevante mesmo que o sequenciador esteja saudável e todas as transações estejam sendo aceitas.

Sob um processo de governança regular, uma atualização anunciada pode ter que passar por um atraso antes de entrar em vigor. Durante esse período, os usuários podem avaliar a proposta e começar a sair se a ponte permanecer aberta. A janela útil de saída é o que resta após considerar as etapas normais de retirada.

Sob um caminho de emergência, signatários designados às vezes podem agir sem o atraso regular. Isso pode ajudar a responder rapidamente a um incidente de segurança. Também dá aos usuários uma garantia diferente daquela que veem quando a governança segue sua rota ordinária.

A avaliação do Arbitrum One lista dez dias para o caminho regular e nenhuma janela de saída para uma atualização de emergência. A avaliação do Base não lista janela de saída. A classificação de estágio principal pode ser a mesma enquanto esses poderes diferem na prática.

Uma pausa é outra ação a distinguir de uma atualização. Uma pausa pode interromper uma operação específica sob as regras contratuais existentes. Uma atualização pode substituir ou alterar essas regras. O signatário e o limite exigidos para uma pausa podem diferir do signatário e do limite para uma nova implementação.

O Crypto.news cobriu um exemplo concreto de autoridade de emergência quando o Conselho de Segurança do Arbitrum moveu fundos ligados ao hack da Binance. Esse caso envolveu fundos identificados e uma alteração contratual temporária. Sua relevância aqui é que a autoridade de emergência pode ser exercida na prática e pode ser separada do processo posterior que determina para onde os fundos vão.

Como ler o Estágio 1 sem confundi-lo com uma garantia de saída

As classificações de estágio agrupam várias dimensões de um rollup. Elas indicam o quanto um sistema se afastou da dependência de operadores ou conselhos sob os critérios do framework. Um rótulo de estágio não pode fornecer a resposta para todos os modos de falha porque cada proteção aborda uma função diferente.

Para um usuário, os detalhes importantes são as condições que se aplicam à sua transação. Um fallback do sequenciador importa se a transação não puder ser incluída. A capacidade de propor estado importa se o proponente habitual do rollup parar. Um atraso de atualização importa se alguém puder alterar o que a ponte fará enquanto o usuário espera.

A disponibilidade de dados pertence à mesma comparação. Se os dados necessários para reconstruir o rollup estiverem acessíveis no Ethereum, outro participante tem base para acompanhar a cadeia. A existência dos dados não realiza por si só uma prova nem envia uma transação no Ethereum em nome do usuário.

Base e Arbitrum One podem ambos oferecer uma rota através do Ethereum para um problema de sequenciador, mantendo permissões diferentes em torno de atualizações. Uma avaliação prática registra ambos em vez de tirar a média deles em uma única pontuação. Um usuário tentando sair precisa da etapa relevante mais fraca para o evento que está enfrentando.

As premissas também variam com o token. ETH nativo pode seguir as próprias regras da ponte oficial. Um token que chegou por meio de um contrato de terceiros pode adicionar controles do emissor ou da ponte. Duas carteiras no mesmo rollup podem enfrentar condições de resgate diferentes mesmo quando suas interfaces mostram ambos os saldos nos mesmos termos em dólar.

O incidente da ponte Ankr fornece um exemplo separado de como a lógica da ponte pode determinar se uma retirada é válida. Ele envolveu um sistema diferente. Sua relevância é a distinção entre atividade em uma cadeia e as regras que a ponte usa para aceitar mensagens e liberar ativos.

O que uma comparação de saída pode estabelecer

Compare dois usuários que iniciam retiradas ordinárias antes de uma interrupção do sequenciador. Se cada retirada já faz parte do estado disponível para a ponte no Ethereum, as etapas restantes dependem do processo de prova e finalização. A interrupção pode ter pouco efeito direto sobre uma retirada já amadurecida se a execução no Ethereum permanecer disponível.

Agora mova a interrupção para mais cedo. Nenhum dos usuários tem uma transação de retirada incluída. Ambos precisam alcançar a rota do rollup no lado do Ethereum ou esperar pelo serviço normal. O tempo até a inclusão pode diferir, e a espera da própria ponte vem depois.

Por fim, imagine uma ação contratual de emergência enquanto as retiradas estão pendentes. A evidência relevante torna-se a autoridade por trás da ação, os contratos exatos afetados e quais etapas a nova configuração permite. Uma transação incluída anteriormente ainda pode precisar que a bridge a reconheça sob as regras em vigor quando o usuário tenta concluir.

Esses casos mostram por que uma comparação justa começa com o mesmo estado. Um usuário que enviou uma mensagem para Ethereum mas ainda não viu a execução do rollup não deve ser comparado diretamente com alguém cuja prova de bridge já foi aceita. Os relógios começam em eventos diferentes.

O Crypto.news noticiou esforços para fazer os rollups do Ethereum funcionarem juntos. Uma interface mais fluida pode ocultar várias etapas em uma transação normal. Sob estresse, o usuário se beneficia de saber quais partes da operação ocorrem em qual chain e quem é responsável por cada parte.

A cobertura do Crypto.news sobre a proposta de recuperação do Arbitrum vinculada à Binance também mostra por que uma ação de governança deve ser lida em conjunto com a transação que ela autoriza. Uma proposta descreve o resultado pretendido. Os registros do Ethereum e do rollup mostram quando e onde ela foi executada.

Uma rota de saída só é útil na medida em que um detentor pode usá-la a partir de sua posição atual. O registro mais claro identifica o ativo, a chain em que ele está, a transação já concluída e a parte ou contrato que controla a próxima etapa. Esse registro informa ao usuário se a espera restante pertence ao sequencer, à bridge ou a uma autoridade capaz de alterar qualquer um dos dois.

Por que uma prova mais rápida não necessariamente encurta toda saída

A atualização Azul da Base introduziu novas opções de prova. O Crypto.news noticiou um caminho potencial para retiradas em um dia. Uma meta ou capacidade de prova deve ser distinguida do tempo de retirada com o qual um determinado usuário pode contar sob a configuração ativa.

Uma prova pode ajudar a estabelecer o estado do qual uma retirada depende. A bridge ainda pode aplicar outras condições antes de liberar fundos. A sequência também pode variar conforme qual caminho de prova a rede utiliza e o que acontece quando esse caminho está indisponível.

Uma comparação de saída deve, portanto, declarar o caminho que está medindo. Um caminho otimista pode ter um período de desafio. Uma rota que usa uma prova diferente pode encurtar parte do processo. Um risco de atualização diz respeito a se os contratos ou permissões que regem qualquer uma das rotas podem mudar antes de ela terminar.

Uma retirada do Ethereum também exige uma transação que possa ser submetida e executada no Ethereum. Um site de terceiros pode oferecer-se para realizar essa etapa, mas sua capacidade de aceitar uma solicitação é separada de se o contrato oficial pode processá-la. Um usuário que vê a ação tornar-se disponível ainda precisa de uma carteira ou serviço capaz de submetê-la.

A distinção torna-se importante se o usuário estiver mantendo ativos em nome de um aplicativo ou de um cliente. Um tesouro pode exigir várias aprovações antes de qualquer ação no Ethereum. Um usuário comum pode precisar de uma conexão de carteira e gas. O tempo de saída disponível no protocolo e o tempo de que a pessoa precisa para agir podem diferir.

O que o registro público pode mostrar após uma interrupção

Um relato de incidente pode começar com a última resposta normal do sequencer e a primeira transação atrasada. Ele pode então identificar se os dados e o estado continuaram a chegar ao Ethereum. Os registros podem ajudar a explicar por que alguns usuários viram uma interrupção enquanto outros ainda conseguiram concluir retiradas anteriores.

A linha do tempo mais útil também nomeia o aplicativo e o ativo envolvidos. Uma carteira relatando saldos desatualizados é diferente de uma bridge recusando-se a aceitar uma transação de finalização. Um provedor terceirizado pausando um pagamento é diferente da bridge oficial alterando suas regras.

A cobertura do Crypto.news sobre uma intervenção de emergência no Arbitrum ilustra a necessidade de separar uma ação realizada por um conselho do processo de governança que se segue. A existência de um registro no Ethereum pode estabelecer que ocorreu uma ação contratual. Isso não elimina a necessidade de ler qual autoridade a realizou e o que ela afetou.

A resposta direta à questão da retirada depende de quando a falha acontece. Antes da inclusão, observe o fallback do Ethereum e o atraso a ele associado. Após a inclusão, observe o estado, a prova e os requisitos de finalização. Durante uma mudança de emergência, a autoridade para pausar ou modificar contratos torna-se decisiva mesmo que os outros sistemas estejam funcionando.

Um usuário também pode ter várias retiradas em pontos diferentes dessa sequência. Uma pode estar pronta para ser concluída enquanto outra ainda aguarda inclusão. Um aviso de interrupção que fornece um tempo esperado de recuperação não pode resolver o status de ambas.

O recibo de saque é a verificação final

Uma interface de ponte pode rotular um saque como pronto antes que o usuário tenha enviado a transação para concluí-lo. O recibo da transação Ethereum é um registro separado. Para ETH nativo, o destinatário também pode verificar se a transferência chegou ao endereço pretendido e se o destinatário pode utilizá-la.

Essa distinção é importante quando um usuário tenta novamente uma ação após uma interrupção. Duas tentativas de enviar uma instrução podem produzir mensagens diferentes ou apenas uma transação aceita, dependendo de como as solicitações foram feitas. O histórico de uma carteira pode ajudar o usuário a identificar qual mensagem a ponte reconhece antes de tentar o próximo passo.

Um rollup e uma ponte também podem se recuperar em cronogramas diferentes. O sequenciador pode retomar enquanto saques mais antigos ainda aguardam estado ou prova. Novas transações de rollup aparecendo novamente é evidência de recuperação do serviço para ordenação, mas os usuários que aguardam receber ETH na Ethereum ainda precisam verificar seu próprio status de finalização.

O mesmo princípio se aplica a um aviso de atualização. Um anúncio pode dizer que uma ponte está pausada sem alterar o que o rollup continua a processar. Os usuários precisam identificar se a pausa afeta a iniciação, a prova, a finalização ou outra operação. Um único aviso pode ter importância diferente para detentores em pontos distintos do processo.

Para os dois usuários na comparação, a evidência final é a mesma. Seus saques pela ponte oficial estão completos quando a Ethereum registra a liberação de ETH para o destinatário pretendido. Tudo antes disso lhes diz qual parte da rota está funcionando e o que ainda precisa acontecer.

O que observar

• Status do sequenciador: Um aviso de status e registros de transações de rollup podem mostrar quando a ordenação normal parou e foi retomada.
• Caixa de entrada do Ethereum: Um recibo bem-sucedido do Ethereum pode estabelecer que a mensagem de fallback foi enviada e quando ela se tornou elegível para inclusão.
• Publicação de estado: Registros do Ethereum podem mostrar se a bridge possui a reivindicação ou a saída necessária para processar o saque.
• Ações de emergência: Os signatários autorizadores, os contratos afetados e o momento da transação determinam se uma pausa ou atualização alterou a rota do usuário.
• Lastro do ativo: O emissor do token e a bridge determinam se a comparação oficial de saque se aplica àquele saldo.

Perguntas frequentes