Vai al contenuto
Financial Context Wiki

Token canonici, nativi e wrapped

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...