---
title: "Ponte canônica"
description: "Um guia orientado à verificação de pontes designadas pelo protocolo, lastro de ativos, estados de mensagens entre domínios, retiradas otimistas e com provas de validade, controles de atualização, taxas e comparação com pontes rápidas."
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.
# Ponte canônica
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Uma ponte canônica é a rota de ativos ou mensagens designada por determinado rollup ou ecossistema de blockchain. Em geral, ela conecta contratos que mantêm um ativo em escrow ou o queimam em uma rede, transmitem uma mensagem reconhecida pelo protocolo e cunham, desbloqueiam ou liberam o ativo correspondente na outra rede. A palavra canônica é um rótulo do ecossistema, não um padrão universal, garantia criptográfica nem prova de que site e endereço são autênticos.
Sua segurança não é uma fórmula aditiva. Ela depende conjuntamente de finalidade da rede de origem, disponibilidade de dados, verificação de estado ou mensagem, contabilidade da ponte, execução no destino, proteção contra replay, poderes de atualização e pausa e rota de saída utilizável. Uma ponte rápida pode pagar o usuário antes com liquidez e liquidar depois pela rota canônica, mas isso acrescenta premissas sobre provedor de liquidez, solver, verificador e execução, em vez de acelerar gratuitamente a mesma máquina de estados.
## Como funciona
1. Fixe o retrato da rota: `chainId` de origem e destino, direção, stack e versão do rollup, endereços de bridge, portal, messenger, inbox ou gateway, endereços dos tokens, destinatário, valor, referências de bloco e documentação oficial. Nunca dependa apenas de resultado de busca ou do rótulo oficial.
2. Determine o modelo de segurança e controle. Registre regras de fault proof otimista ou validity proof, modo de disponibilidade de dados, sequencer e rota forçada, implementação do proxy, administrador ou conselho de segurança, timelock, estado de pausa, limites de taxa e atraso de atualização. Canônica não significa imutável.
3. Classifique o registro do ativo. Diferencie valor nativo de tokens ERC-20 e identifique o mecanismo lock-and-mint, burn-and-release ou burn-and-mint. Verifique o par registrado de tokens, unidades brutas, decimais, gateway personalizado e suporte a ativos fee-on-transfer, rebasing ou sujeitos a denylist.
4. Construa a máquina de estados de mensagens específica para cada direção. Um depósito pode passar por aprovação, escrow ou queima na origem, finalidade na origem, derivação ou relay e cunhagem ou desbloqueio no destino. Uma retirada pode exigir queima ou escrow no destino, inclusão da mensagem, compromisso de estado, prova, contestação ou aceitação da prova, finalização e liberação na origem.
5. Acompanhe três relógios separadamente: inclusão da transação, liquidação do protocolo ou finalidade do estado e disponibilidade do ativo para uso ou retirada. Registre hash da transação de origem, hash da mensagem ou retirada, referência de output ou prova e cada transação de relay, prove, finalize, claim, retry ou refund.
6. Construa o registro econômico. Separe principal transferido, gás de origem e destino, gás de prova ou finalização, taxa do protocolo ou relayer, taxa do provedor de liquidez, slippage e custo de oportunidade da espera. Compare uma ponte rápida e a rota canônica como direitos e modelos de confiança distintos.
7. Reconcilie a rota concluída com recibos, eventos, saldos em escrow, oferta da representação, direitos pendentes, saldos do destinatário e allowances restantes. Aguarde a finalidade exigida, mantenha gás de emergência, teste rotas permissionless ou forçadas quando aplicável e pare em vez de repetir um depósito cujo estado da mensagem não esteja explicado.
## Exemplos resolvidos
- **Registro de depósito de ativo nativo.** Um usuário começa com `5.0000 ETH`, deposita `2.5000 ETH` e paga `0.0042 ETH` de gás na origem. A carteira de origem termina com `5.0000 - 2.5000 - 0.0042 = 2.4958 ETH`; o escrow aumenta em `2.5000 ETH`; e, após um relay bem-sucedido de um para um, a representação no destino aumenta em `2.5000 ETH`. A razão de lastro é `2.5000 / 2.5000 = 100%`. Escrow e representação são lastro e direito, não `5 ETH` de novo valor econômico.
- **Unidades brutas e mapeamento do token.** Um usuário deposita `1,250.000000 USDC`. O contrato de origem verificado usa `6 decimals`, portanto o valor bruto é `1,250 * 10^6 = 1,250,000,000`. Em um mapeamento verificado de um para um e sem taxa do token, o escrow na origem e a cunhagem no destino mudam cada um em `1,250,000,000 raw units`, exibidos remotamente como `1,250.000000 USDC`. Um token de mesmo símbolo em outro endereço não constitui evidência equivalente.
- **Os relógios de retirada são distintos.** Suponha que um deployment registre uma retirada em `2026-08-01 12:00:00 UTC` e aplique um período de contestação de `604,800-second = 7-day` desde esse início definido pelo protocolo. O limite temporal é `2026-08-08 12:00:00 UTC`; uma transação de prove ou finalize, o gás e a política escolhida de confirmação da rede de origem podem acrescentar mais tempo. Este exemplo parametrizado não afirma que todas as pontes aguardem sete dias, e a finalidade da transação no destino não libera por si só os fundos na origem.
- **Cotação da rota rápida versus custo de espera.** Para `10,000 USDC`, uma ponte rápida cobra `0.08%` mais `3 USDC`, ignorando gás e slippage. O custo é `10,000 * 0.0008 + 3 = 11 USDC` e o recebimento imediato é `9,989 USDC`. Em relação a uma espera canônica hipotética de `7-day`, o preço anualizado simples do acesso antecipado é `(11 / 9,989) * (365 / 7) = 5.7420305193%`. Essa comparação não é yield nem taxa livre de risco e exclui riscos de solver, liquidez, inadimplência e liquidação.
## Riscos
- Usar uma interface de phishing ou domínio de documentação não verificado.
- Selecionar rede de origem ou destino e `chainId` incorretos.
- Enviar para bridge, portal, messenger, gateway ou destinatário falsificados.
- Aceitar token de mesmo símbolo com mapeamento de contraparte registrado diferente.
- Interpretar incorretamente decimais, unidades brutas ou comportamento de transferência não padrão.
- Confundir ativos nativos, tokens de gás wrapped e representações transferidas pela ponte.
- Expor allowance excessiva ou aprovar o spender errado.
- Não detectar atualização de proxy, comprometimento do administrador, ação do conselho de segurança ou alteração do timelock.
- Encontrar pausa, denylist, limite de taxa ou rota de retirada congelada.
- Tratar recibo na origem como prova de execução bem-sucedida no destino.
- Financiar insuficientemente gás de execução, retry, prove, claim ou refund no destino.
- Perder mensagem por expiração do retry, tratamento incorreto do refund ou aliasing de endereço.
- Ignorar reorganização da rede de origem ou finalidade insuficiente.
- Depender de sequencer censor ou indisponível sem rota forçada funcional.
- Perder disponibilidade de dados necessária para provar, reconstruir ou sair do estado.
- Aceitar raiz de estado, prova de mensagem, nullifier ou condição de replay inválidos.
- Depender de proposers, provers, challengers ou finalizers permissioned indisponíveis.
- Interpretar incorretamente parâmetro de contestação, maturidade ou aceitação de prova após atualização.
- Sofrer insolvência do escrow, desvio contábil, depeg do token ou iliquidez no destino.
- Acrescentar riscos de ponte rápida, agregador, verificador, LP, solver, slippage, tributos e sanções.
## Equívocos comuns
- Canônica é um padrão universal e significa automaticamente trustless ou sem risco.
- Transação bem-sucedida na origem ou saldo exibido na UI provam liquidação final.
- Toda retirada de rollup tem o mesmo período de espera de sete dias.
- Escrow na origem e representações no destino podem ser somados como TVL independente.
- Uma ponte rápida é apenas a mesma ponte canônica com ajuste de velocidade.
## Tópicos relacionados
- [Ponte entre redes](/pt-br/crypto/cross-chain-bridge/)
- [Rollup](/pt-br/crypto/rollup/)
- [Mecanismo de saída de rollup](/pt-br/crypto/rollup-escape-hatch/)
## Fontes
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (acessado em: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (acessado em: 2026-08-12)
- [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (acessado em: 2026-08-12)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (acessado em: 2026-08-12)
- [L1 to L2 messaging](https://docs.starknet.io/learn/protocol/messaging) - Starknet Documentation (acessado em: 2026-08-12)
- [StarkGate](https://docs.starknet.io/learn/protocol/starkgate) - Starknet Documentation (acessado em: 2026-08-12)
- [Bridging assets](https://docs.zksync.io/zksync-protocol/rollup/bridging-assets) - ZKsync Docs (acessado em: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
Source: https://wiki.fcontext.com/pt-br/crypto/canonical-bridge/index.mdx