﻿---
title: "Como verificar um token recebido após usar uma bridge"
description: "Verifique identidade, origem, modelo de lastro, autoridades, valores em trânsito, resgate e saída executável."
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.

# Como verificar um token recebido após usar uma bridge

> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

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

## Resposta direta

Nome, símbolo, ícone, preço exibido ou evento `Transfer` não verificam um token recebido por bridge. A identidade começa na chain/domain e no contrato ou marcador nativo e inclui implementation ou beacon atual do proxy, issuer/bridge, route e versão, ativo de origem e snapshot do bloco.

Classifique o claim: supply issuer-native, representação designada por bridge, wrapped token de terceiro, receipt de liquidity/intent ou counterfeit. São emissores, ativos, direitos de resgate e falhas diferentes. Representação canônica não é automaticamente issuer-native; registry do issuer não comprova reservas de bridge de terceiro.

São necessários quatro livros: identidade/autoridade; reservas/claims; mensagens in-flight; e resgate ou saída executável. Um saldo pode ser estado real e ainda representar ativo errado, claim sem lastro suficiente, token congelado ou posição impossível de vender ao preço mostrado.

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

## Como funciona

Símbolo, nome e decimals são metadata ERC-20, não autenticação. Counterfeit pode copiá-los, emitir eventos, publicar source verificado e criar pool. Verificação de source apenas liga código exibido ao bytecode da address. No proxy, saldo e interação ficam no proxy; implementation/beacon fornece lógica, enquanto admin e upgrade path são fatos distintos.

Classifique a contabilidade antes de coverage. Lock-and-mint reconcilia escrow elegível com todas as representações e claims in-flight. Burn-and-mint do issuer transfere supply entre domains e pode não ter escrow persistente. Liquidity bridge antecipa inventory ou cria claim de solver/LP; pool não é automaticamente lastro. Shared reserves contam uma vez entre chains/versões.

Para escopo lock-and-mint definido: `coverage = eligible reserves / supported outstanding claims`. Reserve elegível é o ativo correto, sob custódia prometida, livre e não empenhado novamente. Claims incluem circulação multichain/versão e locks finalizados ainda não minted, menos burns refletidos no supply. Ratio acima de um não prova código, admins, finality, resgate ou depth.

Revise roles mint/burn, remote-token mappings, validators/attesters, proxy admin, implementation, timelock, caps, pause, freeze, denylist e migration powers. Decimals, fee-on-transfer, rebase, hooks/callbacks, returns não padrão e lógica upgradeable podem fazer o valor solicitado divergir de escrow/balance recebido.

Resgate e venda são saídas diferentes. Resgate pode exigir conta elegível, direction suportada, limites, queue, proof/attestation, finality, gas, fee e contratos ativos. DEX exige route executável para o tamanho, fee, depth, price impact, minimum output e timestamp. Quote pequeno perto de um dólar não prova lastro nem saída grande.

Migration divide identidade e liquidity. Representação deprecated pode negociar após replacement, e conversão pode ter cap, ser unilateral, tardia ou fechada. Confirme mapping old-to-new, ratio, deadline e resgate oficiais; não troque só porque suporte ou symbol diz upgrade.

Use este fluxo:

1. Fixe chain/domain, proxy/marcador nativo, implementation/beacon, admin, decimals, bloco/hora, issuer/bridge, route/version e origin asset.
2. Cruze registries de issuer/bridge; verifique remote-token mapping, deployment, replacement/deprecation e direitos issuer-native ou bridge-only.
3. Classifique burn-and-mint, lock-and-mint, shared reserve, wrapper, liquidity/intent receipt ou outro modelo documentado.
4. Reconstrua raw-unit reserves, supply em todas chains/versões, claims in-flight, burns/releases pending e fees; evite dupla contagem.
5. Revise mint/burn/pause/freeze/denylist/cap, validator/attester, proxy admin, implementation/upgrades e transfer/rebase/hook.
6. Teste resgate e saída por tamanho: eligibility, limits, queue, proof, finality, gas, fees, route, depth, minimum output e ativo recebido.
7. Reconcilie receipt, delta de escrow/burn, mensagem, receipt destino, balance, supply, fees e saída líquida; monitore migration e pare em divergências.

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

## Exemplos

- **Metadata não define unidade ou identidade.** Raw amount `123,456,789` vira `123.456789` com `6 decimals`, mas `0.000000000123456789` com `18 decimals`: escala `10^12`. Symbol igual não iguala contratos.
- **Fee-on-transfer cria déficit.** Lock `1,000-token`; fee `1%` remove `10`, escrow recebe `990`; bridge cobra `2-token`. Mint correto `1,000 - 10 - 2 = 988`. Mint de `998` contra `990` cria déficit `8-token`.
- **Shared reserves exigem denominator sistêmico.** Escrow `12.0 million`; B `10.5 million`, C `0.4 million`, claim in-flight `0.6 million`. Claims `10.5 + 0.4 + 0.6 = 11.5 million`; coverage `12 / 11.5 = 1.0434782609` ou `104.34782609%`. Só B dá `12 / 10.5 = 1.1428571429` e superestima.
- **Resgate e DEX diferem.** Holder tem `100,000 tokens`; resgate limita `60,000`, fee `0.20%`, paga `60,000 * (1 - 0.002) = 59,880` e deixa `40,000`. DEX a `0.972` antes de `0.30%`: gross `97,200`, fee `291.60`, net `96,908.40`, antes de gas/MEV. Ícone `$1` não prova resultado.

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

## Riscos

- Address igual em chain/domain errado.
- Symbol/name/icon copiado oculta outro contrato.
- Proxy, implementation ou beacon confundidos.
- Source verificado confundido com endosso do issuer.
- Implementation/admin/upgrade history não conferidos.
- Versão deprecated permanece em uso.
- Counterfeit cria eventos e liquidez artificiais.
- Wrapped/LP receipt confundido com issuer-native supply.
- Modelo lock/burn/mint/reserve/liquidity errado.
- Eligible reserves incluem ativos frozen, borrowed, pledged ou distintos.
- Mesma reserve contada por chain.
- Claims de outras chains, legacy ou in-flight omitidos.
- Burns/mints/snapshots usam tempos incompatíveis.
- Autoridade mint/burn/attester/validator/upgrade comprometida.
- Pause/freeze/denylist/rate limit bloqueia transfer/exit.
- Decimals/raw units/fee-on-transfer/rebase/hooks quebram accounting.
- Reorg ou finality insuficiente invalida backing.
- Eligibility/cap/queue/deadline/finality/fee ignorado.
- Depth/state drift/slippage/MEV/fees inviabiliza quote.
- Migration/replacement/refund/receipts mal reconciliados ou phishing.

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

## Erros comuns

- **Mesmo nome/ícone significa mesmo ativo.** Identidade começa em chain/domain e contrato exato.
- **Token official/canonical bridge é sempre issuer-native.** Designação e direitos do issuer são distintos.
- **Coverage acima de um prova segurança/resgate.** Não prova código, autoridade, finality, liquidity ou eligibility.
- **Verified no explorer prova endosso e imutabilidade.** Não verifica issuer, reserves, proxy admin ou upgrades.
- **DEX em um dólar garante saída a um dólar.** Proceeds depende de direção, tamanho, route, depth, fees, gas, MEV e timing.

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

## Tópicos relacionados

- [Tokens canônicos, nativos e wrapped](/pt-br/crypto/canonical-vs-wrapped-token/)
- [Bridge canônica](/pt-br/crypto/canonical-bridge/)
- [Bridge cross-chain](/pt-br/crypto/cross-chain-bridge/)

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

## Fontes

- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Developers (acesso: 2026-08-13)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (acesso: 2026-08-13)
- [Routes](https://docs.wormhole.com/products/connect/concepts/routes/) - Wormhole Docs (acesso: 2026-08-13)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (acesso: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (acesso: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (acesso: 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (acesso: 2026-08-13)
- [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) - Uniswap (acesso: 2026-08-13)

Source: https://wiki.fcontext.com/pt-br/crypto/bridge-token-verification/index.mdx
