---
title: "Token canonici, nativi e wrapped"
description: "Guida basata sulla verifica a identità del token, asset nativi dell'emittente, rappresentazioni designate dal protocollo, wrapper sulla stessa chain, copertura, 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.
# Token canonici, nativi e wrapped
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Canonico e wrapped non sono classi di token contrapposte. Canonico descrive la mappatura o la rotta designata da uno specifico ecosistema; wrapped descrive un meccanismo di rappresentazione. Un bridge token designato dal protocollo può essere a sua volta wrapped, mentre WETH è un wrapper sulla stessa chain e l'USDC nativo dell'emittente su una chain supportata può utilizzare burn-and-mint controllato dall'emittente anziché un escrow del bridge.
Si parte dall'identità, non dal simbolo: `chainId`, indicatore di asset nativo o contratto del token, implementazione del proxy e blocco. Occorre poi stabilire chi lo emetta o designi, quale asset o passività lo copra, chi possa effettuare mint, burn, pausa o upgrade e se un titolare idoneo possa davvero eseguire unwrap, riscatto, bridging o vendita. Solvibilità, disponibilità del riscatto e liquidità di mercato sono questioni separate.
## Come funziona
1. Fissare lo snapshot: chain, `chainId`, indicatore nativo o indirizzo del token, blocco e ora, decimali, implementazione del proxy o `codeHash` e versione della documentazione dell'emittente o protocollo. Nome, simbolo, logo o token list del wallet non provano l'identità.
2. Classificare su due assi. Lo status può essere nativo della chain, nativo dell'emittente, designato dal protocollo o di terzi. Il meccanismo può essere un wrapper sulla stessa chain, un credito verso un bridge lock-and-mint, un trasferimento burn-and-mint, un wrapper custodial, una quota di vault o una ricevuta di una rete di liquidità. Un token può rientrare in più categorie.
3. Tracciare esattamente provenienza e grafo delle autorità: asset di origine, controparte remota registrata, contratto di escrow o burn, messenger o attester, minter di destinazione, proxy admin, ruoli di mint e burn, poteri di pausa o denylist, timelock, limiti e piano di migrazione.
4. Ricostruire i registri di copertura e passività in unità grezze e visualizzate. Nel lock-and-mint, riconciliare l'escrow idoneo per la coppia con l'offerta della rappresentazione e i crediti in transito. Nel burn-and-mint dell'emittente, riconciliare le offerte sulle chain e la passività dell'emittente; non ipotizzare un escrow del bridge inesistente.
5. Verificare il ciclo eseguibile di riscatto: idoneità, direzione, approval, unwrap o burn, prova o attestazione, finalizzazione o claim, gas su ogni chain, commissioni, limiti, pause e recupero dagli errori. Un piccolo test prova solo quella rotta e quello snapshot.
6. Confrontare le vie di uscita. Registrare separatamente bid DEX eseguibile e profondità, slippage, commissioni di protocollo e LP, gas, ritardo e accettazione da parte di custodian o exchange, senza confonderli con la copertura. Un token coperto può quotare sotto la pari e un prezzo liquido non dimostra la copertura.
7. Riconciliare ricevute, eventi, saldi, offerta, escrow, crediti pendenti e allowance residue. Tenere separati saldi nativi, wrapped, bridged e nativi dell'emittente; monitorare implementazione, ruoli, mapping, migrazione, pause, informative sulle riserve e liquidità; dimensionare l'esposizione sulla peggiore uscita eseguibile plausibile.
## Esempi svolti
- **La copertura deve includere i crediti pendenti.** L'escrow idoneo per la coppia è `2,500.000000 units`, l'offerta emessa a destinazione `2,400.000000 units` e i crediti bloccati ma non ancora emessi `100.000000 units`. Le passività economiche sono `2,400 + 100 = 2,500`, quindi la copertura rettificata è `2,500 / 2,500 = 100%`. Ignorando i crediti pendenti si ottiene `2,500 / 2,400 = 104.1666666667%`, un avanzo fuorviante. Anche una copertura corretta non prova sicurezza contrattuale o liquidità immediata.
- **Lo stesso simbolo può rappresentare crediti diversi.** Un titolare possiede `2,500 units` di ciascuno di due contratti. Il contratto nativo dell'emittente ha un bid eseguibile di `$0.998`, per un valore di `2,500 * 0.998 = $2,495`; il contratto di un bridge terzo ha un bid di `$0.920`, per un valore di `2,500 * 0.920 = $2,300`. La differenza è `$195` nonostante nome e decimali uguali.
- **Wrapped non implica cross-chain.** Un wallet parte con `5.000 ETH`, deposita `3.000 ETH` in un contratto WETH sulla stessa chain e paga `0.002 ETH` di gas. Termina con `1.998 ETH` e `3.000 WETH`; il rapporto riserva/offerta del wrapper è `3 / 3 = 100%`; l'esposizione economica è `1.998 + 3.000 = 4.998 ETH` prima del rischio contrattuale. Sommare di nuovo la riserva significherebbe contarla due volte.
- **Uscita sul mercato e riscatto differito sono diversi.** Per `10,000 tokens`, il bid DEX è `$0.985`, l'impatto sul prezzo `0.60%`, la commissione LP o di protocollo `0.10%` e il gas `$12`. Nell'ordine dichiarato, il ricavo netto è `10,000 * 0.985 * (1 - 0.006 - 0.001) - 12 = $9,769.05`. Un riscatto idoneo restituisce `$9,987` al netto delle commissioni in `7 days`; a un tasso opportunità annuo semplice del `8%`, il valore attuale è `9,987 / (1 + 0.08 * 7 / 365) = $9,971.7009519641`, cioè `$202.6509519641` in più. Non è arbitraggio garantito e omette rischio di default, finalità, fiscalità e prezzo.
## Rischi
- Utilizzare chain, indicatore nativo o contratto del token errati.
- Fidarsi di simbolo, nome, icona o token list contraffatti.
- Interpretare male decimali, unità grezze, offerta o saldi.
- Ignorare implementazione, amministratore o upgrade del proxy.
- Accettare registro, coppia, router o mapping del gateway obsoleti.
- Perdere il controllo per compromissione dei ruoli di emittente, mint, burn o attestazione.
- Considerare riserve commiste, date in garanzia o gravate come copertura idonea.
- Contare due volte escrow, offerta rappresentativa e crediti pendenti.
- Omettere depositi, burn, prelievi, commissioni o messaggi in transito.
- Presumere contabilità standard per token fee-on-transfer, rebasing o con hook.
- Subire freeze dell'emittente, pausa del bridge, denylist, limite o censura.
- Concedere allowance eccessiva o approvare lo spender del bridge errato.
- Confondere finalità della fonte, validità del messaggio ed esecuzione a destinazione.
- Dipendere da relayer, sequencer, prover, attester o dati indisponibili.
- Subire replay, doppio mint, burn fallito, reorg della fonte o difetti contabili.
- Scoprire che il titolare non può accedere al riscatto diretto.
- Subire liquidità frammentata, depeg, slippage, MEV o profondità insufficiente.
- Omettere gas, commissioni, ritardo, costo opportunità o accettazione custodial.
- Restare bloccati in un contratto deprecato o in una migrazione incompleta.
- Combinare rischi correlati di chain, bridge, emittente, oracolo, UI, RPC, fiscalità, sanzioni e custodia.
## Errori comuni
- Canonico significa sempre nativo dell'emittente, ufficiale, trustless e sicuro.
- Wrapped significa sempre che il token ha attraversato una chain.
- Token con simbolo e decimali uguali rappresentano crediti fungibili.
- Un'etichetta uno-a-uno, il saldo di un contratto o una cifra di offerta provano la riscattabilità.
- La copertura delle riserve garantisce valore monetario immediato uno-a-uno in ogni mercato e conto.
## Argomenti correlati
- [Bridge canonico](/it/crypto/canonical-bridge/)
- [Verifica dei bridge token](/it/crypto/bridge-token-verification/)
- [Wrapped token](/it/crypto/wrapped-token/)
## Fonti
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (consultato: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-12)
- [WETH9.sol](https://github.com/gnosis/canonical-weth/blob/master/contracts/WETH9.sol) - Gnosis (consultato: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consultato: 2026-08-12)
- [Bridged token addresses](https://docs.optimism.io/app-developers/reference/tokens/tokenlist) - Optimism Documentation (consultato: 2026-08-12)
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Docs (consultato: 2026-08-12)
- [Cross-Chain Transfer Protocol](https://developers.circle.com/cctp) - Circle Docs (consultato: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/canonical-vs-wrapped-token/index.mdx