Vai al contenuto
Financial Context Wiki

Come verificare un token ricevuto dopo un bridge

Verificare identità, provenienza, modello di copertura, autorità, contabilità in transito, 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

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.

Verifica dei token bridged
0 / 5
0 elementi recensiti; 5 elementi ancora irrisolti

Il completamento di questa revisione non dimostra che una risorsa, una transazione o un sistema siano sicuri.

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

Fonti

Navigazione

Cerca nella wiki...