---
title: "Risco de disponibilidade de relayer cross-chain"
description: "Risco de uma mensagem autenticada não ser entregue ou executada a tempo; o diagnóstico separa finalidade, prova, entrega, execução e contabilidade."
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.
# Risco de disponibilidade de relayer cross-chain
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
O risco de disponibilidade de relayer cross-chain é o risco de uma mensagem válida e autenticada não ser enviada ou executada a tempo no destino. O relayer normalmente transporta mensagem e prova ou metadata; ele não torna o evento de origem final nem autoriza o payload. Consenso da origem, produção de prova ou atestado, verificação no destino e execução pelo receiver são dependências distintas.
O atraso é inicialmente um problema de disponibilidade, não prova de roubo. Ainda assim, pode gerar custo financeiro, perda de prazo, tickets expirados, liquidez indisponível ou perda permanente conforme o produto. Um receipt na origem e o rótulo `Pending` também não provam falha do relayer: a origem pode não ser final, a prova pode faltar, o destino pode estar pausado, o gas subfinanciado ou o receiver reverter.
A entrega permissionless depende do protocolo. Hyperlane e Wormhole descrevem rotas em que terceiros entregam mensagens autenticadas; outros deployments restringem executors, destination callers ou recuperação. Envio aberto não permite alterar payload autenticado, e allowlist de relayer não substitui verificação ou replay protection.
## Como funciona
Um ciclo analítico separa `source submitted`, `source finalized`, `proof pending`, `ready`, `destination submitted`, `failed/retryable`, `executed` e `expired/cancelled`. São rótulos analíticos; cada protocolo tem campos próprios. Withdrawal do OP Stack, mensagem burn-and-mint do CCTP, VAA do Wormhole e mensagem Hyperlane têm regras diferentes de prova, prazo, fee e retry.
Primeiro confirme se a ação na origem bloqueou, queimou ou despachou valor e atingiu a finalidade exigida. Depois, confirme disponibilidade e vigência de root, assinaturas de validadores, VAA de guardians ou attestation. Só então verifique se o relayer observou a mensagem, aceitou sua política de fees, montou metadata correta e a enviou ao contrato exato.
A execução no destino falha de modo independente: indisponibilidade de chain ou sequencer, RPC obsoleto, pausa, versão errada do receiver, gas insuficiente, bloqueio por nonce ordenado, expiry ou revert da aplicação. Hash de transação é apenas referência de envio. A conclusão exige receipt bem-sucedido, estado processed, evento ou mudança do receiver, token correto e efeito esperado no saldo sob a finalidade necessária.
Relay manual não é resgate universal. Só é possível quando o protocolo implantado expõe entry point elegível, mensagem e prova originais estão disponíveis, o caller é permitido, a mensagem não foi consumida nem expirou e o caller financia gas e valor no destino. Simule a chamada oficial. Nunca crie novo lock ou burn na origem para corrigir uma primeira mensagem não diagnosticada.
Retry e replay são diferentes. Retry documentado reapresenta a mesma mensagem canônica após falha do efeito de destino; estado consumed ou nonce correto permite no máximo um efeito bem-sucedido. Relayers podem competir e gastar gas sem comprometer a segurança. Cancelar tarefa local não recolhe transação já transmitida ou incluída.
Use este fluxo:
1. Fixe protocolo, lane, versão, domínios e contratos, transação e log de origem, ID ou nonce, ação do ativo, raw amount, receiver e expiry.
2. Verifique receipt e evento de origem e aplique a regra de confirmação ou finalidade; confira identidade do bloco e reorg, não apenas a interface.
3. Localize proof, VAA, attestation, checkpoint ou root; confira estado de origem, versão, signer set, disponibilidade e invalidação ou expiry.
4. Verifique saúde do destino, versões de messenger/receiver, pausa, nonce ou processed state, predecessores, deadline e gas nativo.
5. Determine se a entrega é permissionless, allowlisted ou restrita; na rota manual elegível, reconstrua e simule payload, prova e chamada oficiais originais.
6. Atualize gas limit, price, margem cambial, fee cap, refund e expiry; envie ou repita a mesma mensagem, trate corridas de duplicação/replacement e guarde o receipt.
7. Reconcilie escrow ou burn, passivo in-flight, mint, unlock ou call, fees, refunds e estado final; escale por canais documentados sem fornecer seed phrase ou private key.
## Exemplos
- **Atribuição do atraso.** Finalidade leva `12 minutes`, prova `8 minutes`, fila do relayer `35 minutes` e inclusão `5 minutes`. Total: `12 + 8 + 35 + 5 = 60 minutes`. Só a fila de `35-minute` pertence à delivery liveness; os primeiros `20 minutes` e últimos `5 minutes` têm outros responsáveis.
- **Cotação de gas insuficiente.** Limite `300,000`. A `25 gwei`, custo `300,000 * 25 * 10^-9 = 0.0075 ETH`. Na execução, `60 gwei` exige `0.018 ETH`, faltando `0.018 - 0.0075 = 0.0105 ETH`. Mais gas na origem não necessariamente financia o destino.
- **Relayers duplicados gastam gas, não principal.** Três enviam a mensagem de `100,000 USDC`. O vencedor usa `180,000 gas * 30 gwei = 0.0054 ETH`; dois revertem após `70,000 gas * 30 gwei = 0.0021 ETH` cada. Total `0.0054 + 0.0021 + 0.0021 = 0.0096 ETH`; replay state correto permite `100,000 USDC`, não `300,000 USDC`.
- **Passivo em trânsito.** Rota lock-and-mint bloqueia `25 ETH`; após falha, escrow `+25 ETH`, wrapped supply `+0 ETH`, passivo in-flight `25 ETH`. Retry correto mantém escrow `25 ETH`, eleva supply a `25 ETH` e reduz passivo a `0 ETH`. Novo depósito de `25 ETH` criaria `50 ETH` em escrow e duas obrigações.
## Riscos
- Transação de origem fica pending ou reverte enquanto a interface diz enviada.
- Evento é usado antes da finalidade suficiente.
- Reorg remove ou altera o evento.
- Proof, attestation, checkpoint ou assinaturas não estão disponíveis.
- Root ou signer set obsoleto, errado ou invalidado é usado.
- Chave ou serviço de relayer allowlisted fica indisponível.
- Permissionless é confundido com entrega pontual garantida.
- Entry point restrito é confundido com rota manual pública.
- Chain, sequencer, RPC ou indexer de destino está indisponível ou obsoleto.
- Messenger ou receiver de destino está pausado.
- Upgrade ou address mismatch do receiver causa revert.
- Gas limit de destino é baixo.
- Gas quote, câmbio, fee cap ou refund fica obsoleto.
- Wallet não tem o ativo de gas nativo correto.
- Mensagem, ticket, proof ou deadline expira.
- Lacuna de nonce ordenado bloqueia mensagens posteriores.
- Lógica retry/consumed duplica ou impede recuperação.
- Corridas de duplicação, cancelamento ou replacement gastam gas.
- Suporte falso fornece contratos, provas ou calldata maliciosos.
- Lock/burn, claims in-flight, efeitos, fees e refunds são mal reconciliados.
## Erros comuns
- **O relayer autentica a mensagem.** A entrega leva evidência; verifier e aplicação de destino aplicam origem, sender, payload e replay.
- **Falha do relayer significa perda ou refund automático.** Primeiro há atraso; expiry, recuperação, solvência e refund dependem do produto.
- **Permissionless permite mudar payload ou garante execução imediata.** Autenticação impede mudança; proof, gas, chain e receiver controlam liveness.
- **Todo retry duplica o mint.** O retry correto reutiliza uma mensagem e permite um efeito; nova transferência cria nova obrigação.
- **Hash de destino ou rótulo completed prova recebimento.** Confirme receipt, processed state, eventos, saldos, token e finalidade.
## Tópicos relacionados
- [Bridge cross-chain](/pt-br/crypto/cross-chain-bridge/)
- [Proteção contra replay de mensagens](/pt-br/crypto/bridge-message-replay-protection/)
- [Bridge canônica](/pt-br/crypto/canonical-bridge/)
## Fontes
- [Relayer](https://docs.hyperlane.xyz/docs/protocol/agents/relayer) - Hyperlane Documentation (acesso: 2026-08-13)
- [Mailbox](https://docs.hyperlane.xyz/docs/protocol/core/mailbox) - Hyperlane Documentation (acesso: 2026-08-13)
- [VAAs](https://docs.wormhole.com/protocol/infrastructure/vaas/) - Wormhole Docs (acesso: 2026-08-13)
- [Executor Framework](https://docs.wormhole.com/protocol/infrastructure/relayers/executor-framework/) - Wormhole Docs (acesso: 2026-08-13)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (acesso: 2026-08-13)
- [Cross Domain Messengers](https://specs.optimism.io/protocol/messengers.html) - OP Stack Specification (acesso: 2026-08-13)
- [CCTP Technical Guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (acesso: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (acesso: 2026-08-13)
Source: https://wiki.fcontext.com/pt-br/crypto/bridge-relayer-liveness-risk/index.mdx