Ir para o conteúdo
Financial Context Wiki

Como verificar um token recebido após usar uma bridge

Verifique identidade, origem, modelo de lastro, autoridades, valores em trânsito, resgate e saída executável.

Atualizado

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

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.

Verificação de token bridged
0 / 5
0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

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.

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.

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.

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.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...