---
title: "Come verificare un token ricevuto dopo un bridge"
description: "Verificare identità, provenienza, modello di copertura, autorità, contabilità in transito, riscatto e valore di uscita eseguibile."
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.
# Come verificare un token ricevuto dopo un bridge
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Nome, simbolo, icona, prezzo mostrato o evento `Transfer` non verificano un token ricevuto dopo un bridge. L'identità parte da chain/domain e contratto o marker dell'asset nativo e include implementation o beacon corrente del proxy, issuer/bridge, route e versione, origin asset e snapshot del blocco.
Classificare il claim: supply issuer-native, rappresentazione designata dal bridge, wrapped token di terzi, receipt di liquidity/intent o counterfeit. Ciascuno ha issuer, asset, diritto di riscatto e failure mode diversi. Una rappresentazione canonica non è automaticamente issuer-native; il registry dell'issuer non prova le riserve di un bridge terzo.
Servono quattro registri: identità/autorità; reserves/claims; messaggi in-flight; riscatto o exit eseguibile. Un saldo può essere stato contrattuale reale ma rappresentare asset errato, claim sottocollateralizzato, token congelato o posizione non vendibile al prezzo mostrato.
## Come funziona
Simboli, nomi e decimals sono metadata ERC-20, non autenticazione dell'issuer. Un counterfeit può copiarli, emettere eventi, pubblicare source verificato e creare un pool. Source verification collega solo il codice mostrato al bytecode di una address. Con proxy, interazione e saldi sono al proxy; implementation/beacon fornisce logica, mentre admin e upgrade path restano separati.
Classificare il modello contabile prima della coverage. Lock-and-mint riconcilia escrow eleggibile con rappresentazioni supportate e claim in-flight validi. Burn-and-mint dell'issuer trasferisce supply tra domains e può non avere escrow persistente. Liquidity bridge anticipa inventory o crea claim solver/LP; il pool non è automaticamente backing. Shared reserves vanno contate una volta tra chain/versioni.
Per uno scope lock-and-mint definito: `coverage = eligible reserves / supported outstanding claims`. Eligible reserves devono essere asset corretto, sotto custodia promessa, non gravato e non impegnato di nuovo. Claims possono includere circulation multichain/versione e lock finalizzati non ancora minted, meno burn già nel supply. Ratio sopra uno non prova codice, admin, finality, accesso al riscatto o depth.
Ispezionare ruoli 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, return non standard e logica upgradeable possono cambiare escrow/balance rispetto alla richiesta.
Riscatto e vendita sono exit distinti. Il riscatto può richiedere account eleggibile, direction supportata, limiti, queue, proof/attestation, finality, gas, fee e contratti attivi. DEX richiede route eseguibile per size, fee, depth, price impact, minimum output e timestamp. Un piccolo quote vicino a un dollaro non prova backing né un exit grande.
Migration può dividere identità e liquidità. Una representation deprecated può negoziare dopo un replacement; conversion può avere cap, essere one-way, tardiva o chiusa. Verificare mapping old-to-new, ratio, deadline e redemption status ufficiali; non scambiare per un messaggio di supporto o symbol upgrade.
Usare questo flusso:
1. Fissare chain/domain, proxy/native marker, implementation/beacon, admin, decimals, block/time, issuer/bridge, route/version e origin asset.
2. Incrociare registry issuer/bridge; verificare remote-token mapping, deployment, replacement/deprecation e diritti issuer-native o bridge-only.
3. Classificare issuer burn-and-mint, lock-and-mint, shared reserve, wrapper terzo, liquidity/intent receipt o altro modello.
4. Ricostruire raw-unit reserves, supply di tutte chain/versioni, claim in-flight, burn/release pending e fee; evitare double counting.
5. Ispezionare mint/burn/pause/freeze/denylist/cap, validator/attester, proxy admin, implementation/upgrades e transfer/rebase/hook.
6. Testare riscatto ed exit per size: eligibility, limits, queue, proof, finality, gas, fee, route, depth, minimum output e asset ricevuto.
7. Riconciliare receipt sorgente, delta escrow/burn, messaggio, receipt target, balance, supply, fee ed exit netto; monitorare migration e fermarsi sulle differenze.
## Esempi
- **Metadata non determina unità o identità.** Raw amount `123,456,789` è `123.456789` con `6 decimals`, ma `0.000000000123456789` con `18 decimals`: scala `10^12`. Symbol uguale non rende identici i contratti.
- **Fee-on-transfer crea shortfall.** Lock `1,000-token`; fee `1%` rimuove `10`, escrow riceve `990`; bridge addebita `2-token`. Mint corretto `1,000 - 10 - 2 = 988`. Mint `998` contro `990` crea shortfall `8-token`.
- **Shared reserves richiede denominator di sistema.** 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` o `104.34782609%`. Solo B dà `12 / 10.5 = 1.1428571429` e sovrastima.
- **Capacità di riscatto e valore DEX differiscono.** Holder ha `100,000 tokens`; riscatto solo `60,000` con fee `0.20%`: `60,000 * (1 - 0.002) = 59,880` underlying e `40,000` in queue. DEX a `0.972` prima di `0.30%`: gross `97,200`, fee `291.60`, net `96,908.40`, prima di gas/MEV. Icona `$1` non prova nulla.
## Rischi
- Stessa address sulla chain/domain errata.
- Symbol/name/icon copiato nasconde contratto diverso.
- Proxy, implementation o beacon confusi.
- Source verificato scambiato per endorsement dell'issuer.
- Implementation/admin/upgrade history non controllati.
- Versione deprecated ancora usata.
- Counterfeit crea eventi e liquidità artificiali.
- Wrapped/LP receipt terzo scambiato per issuer-native supply.
- Modello lock/burn/mint/reserve/liquidity errato.
- Eligible reserves includono asset frozen/borrowed/pledged/mismatched.
- Stessa reserve contata per ogni chain.
- Claim other-chain/legacy/in-flight omessi.
- Burn/mint/snapshot a tempi incoerenti.
- Autorità mint/burn/attester/validator/upgrade compromessa.
- Pause/freeze/denylist/rate limits bloccano transfer/exit.
- Decimals/raw units/fee-on-transfer/rebase/hooks rompono accounting.
- Reorg o finality insufficiente invalida backing.
- Eligibility/cap/queue/deadline/finality/fee ignorato.
- Depth/state drift/slippage/MEV/fee rende quote ineseguibile.
- Migration/replacement/refund/receipt mal riconciliato o phishing.
## Errori comuni
- **Stesso nome/icona significa stesso asset.** Identità inizia da chain/domain e contratto esatto.
- **Token official/canonical bridge è sempre issuer-native.** Designazione bridge e diritti issuer sono distinti.
- **Coverage sopra uno prova sicurezza/riscatto.** Non prova codice, autorità, finality, liquidity o eligibility.
- **Verified nell'explorer prova endorsement e immutabilità.** Non verifica issuer, reserves, proxy admin o upgrade.
- **DEX a un dollaro garantisce exit a un dollaro.** Proceeds dipende da direction, size, route, depth, fee, gas, MEV e timing.
## Argomenti correlati
- [Token canonici, nativi e wrapped](/it/crypto/canonical-vs-wrapped-token/)
- [Bridge canonico](/it/crypto/canonical-bridge/)
- [Bridge cross-chain](/it/crypto/cross-chain-bridge/)
## Fonti
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Developers (consultato: 2026-08-13)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (consultato: 2026-08-13)
- [Routes](https://docs.wormhole.com/products/connect/concepts/routes/) - Wormhole Docs (consultato: 2026-08-13)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consultato: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (consultato: 2026-08-13)
- [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) - Uniswap (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/bridge-token-verification/index.mdx