Alle 17:35 UTC del 18 aprile 2026 blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il portafoglio di un attaccante ha chiamato il contratto EndpointV2 di LayerZero e il bridge di Kelp ha rilasciato 116.500 rsETH, circa 292 milioni di dollari, secondo la ricostruzione di The Block dai log degli eventi. Sull’altra blockchain non era mai stato fatto alcun deposito corrispondente. Il multisig di emergenza di Kelp ha messo in pausa i contratti 46 minuti dopo, e altri due tentativi da 40.000 rsETH ciascuno sono falliti.
In quel trasferimento non c’era nessun tunnel tra due blockchain. Un bridge crypto, o ponte tra blockchain, non sposta nulla: permette a un contratto sulla catena B di agire su un’affermazione riguardo a ciò che è accaduto sulla catena A. Qualcuno deve garantire quell’affermazione. Nel caso di Kelp un solo verificatore ha garantito un deposito che non esisteva. Il resto della lezione segue una sola domanda in ogni schema: chi dà il via libera al messaggio, e che cosa aspetti o rischi per colpa sua.
Due promemoria prima di scendere nei dettagli. Ogni blockchain tiene il proprio registro e non può leggere da sola lo stato di un’altra; la distinzione tra i livelli base e i rollup costruiti sopra è nella nostra guida a blockchain di livello 1 e di livello 2. Dove si trova la liquidità, rete per rete, era il tema della lezione precedente, dove vive la DeFi: le blockchain a confronto. Spostarsi tra quelle reti è il compito di un bridge, e qui li dividiamo in tre famiglie in base a chi porta la fiducia.
Tre domande da fare a ogni trasferimento cross-chain
Ogni prodotto cross-chain, qualunque sia il marketing, risponde alle stesse tre domande. Che cosa viene spostato: l’asset originale, una copia wrapped, o un messaggio che ordina a un contratto di fare qualcosa? Chi verifica che l’evento sulla catena di partenza sia avvenuto davvero: la catena di arrivo stessa, un gruppo di firmatari, una sola azienda, o un relayer che ha messo a rischio il proprio denaro? E che cosa aspetta l’utente: secondi, minuti o una settimana?
Le risposte raggruppano i prodotti in tre famiglie. I bridge nativi, detti anche canonici, sono gestiti dalla catena o dall’emittente del token e verificati dal sistema di prove della catena o dall’emittente stesso. I bridge di terze parti e le reti di messaggistica sono sistemi separati, verificati da insiemi di validatori, comitati o verificatori configurabili. I sistemi a intent lasciano che l’utente firmi il risultato che vuole e che un filler lo consegni per primo con il proprio capitale, con il regolamento controllato dopo. Commissioni e velocità cambiano, ma la vera differenza è dove cade il rischio quando qualcosa si rompe.
Bridge nativi: prelievi lenti, protetti dal rollup stesso
Il bridge canonico di un rollup è la coppia di contratti che il rollup stesso usa per spostare ETH e token tra Ethereum e il livello 2. I depositi da Ethereum verso il rollup sono rapidi, perché il rollup legge Ethereum direttamente. I prelievi sono la direzione lenta, perché Ethereum deve essere convinta che lo stato del rollup sia corretto.
Come funziona un prelievo da un rollup, passo per passo
Su una catena OP Stack come OP Mainnet o Base, la documentazione di Optimism (in inglese) descrive tre transazioni. Avvii il prelievo sul livello 2. Quando una proposta che copre quel blocco è stata pubblicata su Ethereum, dimostri il prelievo su Ethereum con una prova di Merkle rispetto a quella proposta. Poi aspetti il periodo di contestazione dei guasti, 7 giorni sulla mainnet, e finalizzi. Durante l’attesa chiunque può contestare lo stato pubblicato con un gioco di dispute sui guasti; un prelievo dimostrato rispetto a una proposta perdente non può essere finalizzato.
Arbitrum segue la stessa logica con un vocabolario diverso. La sua documentazione sui messaggi verso la catena madre (in inglese) indica una finestra di disputa di circa 6,4 giorni (la stessa pagina la arrotonda anche a circa 7 giorni). Quando l’asserzione è confermata, chiunque può eseguire il prelievo tramite il contratto Outbox con una prova di Merkle. Il messaggio resta nell’Outbox senza scadenza, quindi un prelievo dimenticato si può reclamare anche più tardi, ma nessuno lo esegue al posto tuo a meno che tu non paghi un servizio di terzi.
La settimana è il prezzo del modello di sicurezza. Il bridge canonico non si fida di nessun firmatario esterno: se lo stato pubblicato dal rollup è sbagliato, il gioco di dispute dovrebbe accorgersene prima che esca del denaro. Per questo i servizi di terzi offrono prelievi veloci: ti pagano su Ethereum molto prima e si caricano sul proprio bilancio i sette giorni di attesa e il rischio che comportano.
CCTP: USDC nativi spostati bruciando e coniando
Il Cross-Chain Transfer Protocol di Circle funziona in modo diverso perché l’emittente controlla entrambe le estremità. Gli USDC vengono bruciati sulla catena di partenza, il servizio di attestazione di Circle certifica che la combustione è avvenuta e gli USDC nativi vengono coniati sulla catena di arrivo. Non nasce alcun token wrapped e non entra in gioco nessun pool di liquidità. Circle ha lanciato la seconda versione l’11 marzo 2025 con due novità: Fast Transfer e gli Hooks, che attivano azioni automatiche sulla catena di arrivo dopo l’arrivo degli USDC. Oggi Circle chiama quella versione semplicemente CCTP; la prima è etichettata come legacy.
Le velocità sono nella pagina per sviluppatori del CCTP (in inglese): circa 8-20 secondi per un Fast Transfer e 15-19 minuti per uno Standard Transfer da Ethereum e dai suoi livelli 2, con la commissione prelevata dall’importo inviato. La pagina delle catene supportate elencava 31 blockchain al 28 ottobre 2026. Il Fast Transfer è rapido perché Circle firma l’attestazione quando la combustione è inclusa in un blocco, senza aspettare la finalità definitiva sulla catena di partenza; per coprire il rischio di una riorganizzazione, Circle limita questi trasferimenti con una soglia globale, secondo la sua pagina sulla finalità.
Il CCTP è nativo, non trustless. L’unico verificatore è Circle. Per uno stablecoin il cui emittente già garantisce ogni token, questo aggiunge poca fiducia nuova rispetto al semplice possesso di USDC, ed evita le copie wrapped che un bridge lock-and-mint creerebbe. Circle ha esteso lo stesso servizio di attestazione a EURC e ai token di terzi registrati, ma per la maggior parte dei token non esiste un percorso di questo tipo gestito dall’emittente.
Dove i bridge nativi sono più deboli di come sembrano
Nativo non significa ugualmente sicuro ovunque. Il riepilogo di L2BEAT colloca Arbitrum One, Base e OP Mainnet allo Stage 1, non allo Stage 2; che cosa significhi ogni stage per i tuoi fondi è spiegato nella lezione precedente. I bridge di alcune catene poggiano su un gruppo con permessi: L2BEAT descrive il bridge di Hyperliquid come validato da un insieme di validatori di Hyperliquid ammessi su autorizzazione. La domanda resta quella di qualsiasi bridge: chi può approvare un prelievo, e quanti di loro dovrebbero fallire.
Conta anche la dimensione. Al 28 ottobre 2026 DefiLlama conta 3,31 miliardi di dollari nel bridge canonico di Arbitrum, 2,92 miliardi in quello di Base e 0,64 miliardi in quello di Optimism. Quei saldi coprono ogni token bridged sul livello 2, quindi un bug nel contratto del bridge raggiungerebbe tutti i possessori insieme.
Bridge di terze parti: lock-and-mint, burn-and-mint e reti di liquidità
Un bridge di terze parti è un sistema separato che si colloca tra due catene che non controlla. La pagina di Ethereum.org sui bridge (in inglese) li ordina per meccanismo. Il lock-and-mint blocca l’asset originale in un contratto sulla catena A e conia una copia wrapped sulla catena B; la copia vale quanto vale il blocco. Il burn-and-mint distrugge i token su una catena e li crea sull’altra, ed è adatto ai token il cui emittente è presente in modo nativo su più reti. Le reti di liquidità tengono token veri su entrambi i lati e scambiano il tuo asset su A con lo stesso asset su B attingendo ai propri pool, così ricevi il token nativo e non una copia.
La stessa pagina traccia la linea che conta per il rischio: i bridge trusted si affidano a un gruppo esterno (una federazione multisig, una rete MPC, una rete di oracoli) per riferire che cosa è successo, mentre i bridge trustless si affidano solo alle catene collegate e alle loro prove. La maggior parte dei bridge in uso sta dal lato trusted. È anche il motivo per cui i bridge attirano gli attacchi: il contratto di blocco custodisce la garanzia di ogni token wrapped dall’altra parte, e un solo difetto può svuotare un pool che sostiene molte posizioni.
Il valore bloccato dà un’idea di dove sta la fiducia. Le cifre qui sotto sono token custoditi nei contratti dei bridge, non volumi di trasferimento, che DefiLlama vende solo nel piano a pagamento. I sistemi burn-and-mint come il CCTP custodiscono quasi nulla per progetto, e i sistemi a intent poco, perché i filler usano il proprio capitale.
| Bridge (nome su DefiLlama) | Tipo | Valore bloccato, 28 ottobre 2026 |
|---|---|---|
| LayerZero V2 | Messaggistica, token custoditi dalle app costruite sopra | 16,73 miliardi di dollari |
| WBTC | Bitcoin wrapped in custodia | 9,48 miliardi di dollari |
| Arbitrum Bridge | Bridge canonico di rollup | 3,31 miliardi di dollari |
| USDT0 | USDT omnichain | 3,21 miliardi di dollari |
| Base Bridge | Bridge canonico di rollup | 2,92 miliardi di dollari |
| Chainlink CCIP | Messaggistica e pool di token | 1,99 miliardi di dollari |
| Portal (Wormhole) | Messaggistica, lock-and-mint | 1,52 miliardi di dollari |
| Optimism Bridge | Bridge canonico di rollup | 0,64 miliardi di dollari |
| NEAR Intents | Sistema a intent | 208 milioni di dollari |
| Axelar | Messaggistica proof-of-stake | 141 milioni di dollari |
| Hyperlane | Messaggistica, sicurezza scelta dall’app | 77 milioni di dollari |
| Across | Sistema a intent | 17 milioni di dollari |
La cifra di LayerZero non è denaro di LayerZero: è la somma dei token custoditi dalle applicazioni che inviano i loro messaggi tramite LayerZero, ciascuna con le proprie impostazioni di sicurezza.
Messaggistica cross-chain: chi dà il via libera a un messaggio
La maggior parte dei bridge moderni sono applicazioni costruite sopra una rete di messaggistica. Il contratto del token sulla catena A emette un messaggio («blocca 10 token per questo indirizzo»); la rete lo trasporta alla catena B; un contratto sulla catena B agisce di conseguenza. La rete svolge lo stesso lavoro di un oracolo che riferisce dati esterni a uno smart contract, con la differenza che il dato esterno è lo stato di un’altra blockchain. La sicurezza del trasferimento è la sicurezza di chi attesta quel messaggio.
LayerZero: verificatori scelti da ogni applicazione
Su LayerZero v2 i verificatori sono le Decentralized Verifier Networks (DVN). Ogni applicazione imposta il proprio stack di sicurezza per ciascun percorso, scritto X-of-Y-of-N: un elenco di DVN obbligatorie che devono verificare tutte, più DVN facoltative di cui un numero stabilito deve concordare. Poi un Executor consegna il messaggio. Se l’applicazione non imposta nulla, il protocollo ripiega su valori predefiniti che, secondo la documentazione di LayerZero (in inglese), possono cambiare senza preavviso. I documenti sono netti: «You should always set your DVN configuration explicitly» (testo originale inglese). Indicano anche alle applicazioni in produzione di richiedere almeno una DVN non gestita da LayerZero Labs.
Questo schema lascia la decisione all’applicazione. Due token su LayerZero possono avere sicurezze molto diverse: uno verificato da cinque operatori indipendenti, un altro da uno solo. Chi guarda un token trasferito con LayerZero non può dedurre nulla dal marchio; la configurazione è un’impostazione della singola app, scelta da qualcuno.
Chainlink CCIP: un comitato, verificatori aggiuntivi e un freno d’emergenza
Il Cross-Chain Interoperability Protocol di Chainlink usa, secondo la sua pagina sull’architettura (in inglese), un Committee Verifier predefinito di 16 operatori di nodo indipendenti su ogni lane; ciascuno firma l’ID del messaggio e un aggregatore raccoglie il quorum. Lane, pool di token e contratti riceventi possono richiedere verificatori aggiuntivi. La consegna è permissionless: qualunque executor può presentare un messaggio verificato. Gli emittenti dei token possiedono i propri pool, che bloccano o bruciano da un lato e rilasciano o coniano dall’altro, e i pool applicano limiti di frequenza per catena. Un componente di gestione del rischio funge da salvaguardia d’emergenza on-chain: può «maledire» (curse) una catena e far fallire le operazioni coinvolte.
Wormhole, Hyperlane e Axelar
Wormhole usa un insieme fisso di 19 Guardiani, gestiti da società di validazione consolidate; un messaggio (un VAA, verified action approval) richiede 13 delle loro 19 firme, secondo la documentazione sui Guardiani di Wormhole (in inglese). Hyperlane, come LayerZero, lascia la scelta all’applicazione ricevente: questa sceglie un Interchain Security Module, per impostazione predefinita un modulo multisig, e può combinare più moduli o distribuirne uno proprio. Axelar gestisce un insieme di validatori proof-of-stake; la chiave che controlla il contratto gateway su ogni catena EVM collegata è divisa in quote detenute dai validatori in proporzione allo stake, e un comando viene eseguito solo quando ha firmato un peso sufficiente.
| Protocollo | Chi verifica il messaggio | Chi sceglie la sicurezza |
|---|---|---|
| LayerZero v2 | DVN, X-of-Y-of-N | Ogni applicazione (esistono valori predefiniti) |
| Chainlink CCIP | Comitato di 16 operatori per impostazione predefinita, verificatori extra facoltativi | Chainlink, più emittenti e riceventi che aggiungono verificatori |
| Wormhole | 19 Guardiani, 13 firme | Il protocollo |
| Hyperlane | Interchain Security Module sulla destinazione | L’applicazione ricevente (multisig predefinito) |
| Axelar | Validatori proof-of-stake, quote di chiave pesate per stake | Il protocollo |
| Circle CCTP | Servizio di attestazione di Circle | Circle |
Nessuna di queste risposte è buona o cattiva sulla carta. Un insieme fisso di 13 firme su 19 società note è facile da controllare e difficile da cambiare. Uno stack scelto dall’app può essere più forte di qualsiasi valore predefinito, o molto più debole. Quello che un utente può fare è scoprire quale caso si applica prima di inviare una somma importante.
Rischio dei bridge crypto: quattro modi in cui la promessa si spezza
I bridge sono stati la parte più costosa da difendere della DeFi. Al 28 ottobre 2026 DefiLlama segnala 99 incidenti come hack di bridge, per 3,69 miliardi di dollari su 21,19 miliardi di tutti gli hack che registra, circa il 17%. Le perdite segnalate come bridge e datate 2026 arrivano già a circa 753 milioni di dollari. La concentrazione era più alta nell’anno di picco: Chainalysis scrisse il 2 agosto 2022 che 13 hack di bridge avevano portato via circa 2 miliardi di dollari, il 69% di tutti i fondi rubati fino a quel momento nell’anno. La nostra storia della DeFi elenca i casi in ordine; qui conta capire perché ciascuno è fallito.
| Data | Bridge | Importo (DefiLlama) | Tecnica secondo DefiLlama |
|---|---|---|---|
| 10 ago 2021 | Poly Network | 611 milioni di dollari | Controllo degli accessi errato |
| 2 feb 2022 | Wormhole (Portal) | 326 milioni di dollari | Difetto nella verifica delle firme |
| 23 mar 2022 | Ronin Bridge | 624 milioni di dollari | Chiave di un validatore compromessa |
| 23 giu 2022 | Harmony Bridge | 100 milioni di dollari | Chiave di un validatore compromessa |
| 1 ago 2022 | Nomad | 190 milioni di dollari | Prova falsificata |
| 6 ott 2022 | Binance Bridge (BSC) | 570 milioni di dollari | Bug nel verificatore delle prove |
| 7 lug 2023 | Multichain | 126 milioni di dollari | Chiave di un validatore compromessa |
| 18 apr 2026 | Kelp (rsETH) | 293 milioni di dollari | Falsificazione di un messaggio cross-chain |
| 6 set 2026 | Liquid Network | 320 milioni di dollari | Conio cross-chain senza copertura |
Troppe poche chiavi: Ronin nel 2022 e Multichain nel 2023
Ronin, la sidechain costruita per Axie Infinity, richiedeva 5 firme su 9 validatori per approvare un prelievo. L’analisi di Halborn descrive come l’attaccante le ottenne tutte e cinque: quattro validatori gestiti da Sky Mavis, più uno appartenente ad Axie DAO. Nel novembre 2021 Axie DAO aveva permesso a Sky Mavis di firmare per suo conto per reggere il traffico elevato; l’accordo finì il mese successivo, ma il permesso non fu mai revocato. Dopo essere entrato nei sistemi di Sky Mavis, l’attaccante aveva abbastanza chiavi per firmare prelievi di 173.600 ETH e 25,5 milioni di USDC, circa 624 milioni di dollari. Nessuno se ne accorse per sei giorni, finché un utente non riuscì a prelevare 5.000 ETH. Il 14 aprile 2022 l’FBI dichiarò di aver confermato la responsabilità del Lazarus Group e di APT38, attori associati alla Corea del Nord, come riportò BleepingComputer (in inglese).
La lezione è aritmetica. Nove firmatari sembravano una federazione, ma quattro stavano nella stessa azienda e un quinto era raggiungibile tramite un permesso scaduto. A proteggere un multisig è l’indipendenza, non il numero in copertina.
Multichain è fallito senza una sola riga di codice sbagliata. Secondo le dichiarazioni del team riportate da Cointelegraph (in inglese), l’amministratore delegato Zhaojun fu portato via da casa dalla polizia cinese il 21 maggio 2023, e «all the team’s funds and access to the servers» (testo originale inglese) erano con lui e con la polizia. All’inizio di luglio più di 100 milioni di dollari uscirono dai contratti del bridge; Multichain fermò le attività il 14 luglio. Chainalysis disse che i prelievi somigliavano a un rug pull interno. La versione del team non è stata verificata in tribunale, ma il tipo di guasto è chiaro: le chiavi di un bridge con centinaia di milioni dipendevano da una sola persona.
Un bug nella verifica: Wormhole nel 2022
Il 2 febbraio 2022 il lato Solana di Wormhole ha coniato 120.000 ETH wrapped senza che nulla fosse bloccato su Ethereum, circa 326 milioni di dollari. Il contratto non validava correttamente gli account che riceveva, e questo permise all’attaccante di presentare come valide firme false dei Guardiani, come riportò The Block (in inglese). La regola dei 13 Guardiani su 19 non fu mai violata: il contratto semplicemente non verificò che il controllo delle firme fosse stato davvero eseguito. Jump Crypto sostituì i 120.000 ETH il giorno dopo, quindi i possessori di ETH wrapped furono risarciti. Quel salvataggio fu una scelta di uno sponsor facoltoso, non una proprietà del bridge.
Un aggiornamento che approvava tutto: Nomad nel 2022
Il guasto di Nomad del 1° agosto 2022 nacque da un aggiornamento di routine. Secondo l’analisi di Immunefi (in inglese), l’inizializzazione di un nuovo contratto Replica segnò come fidata la radice zero. Nello storage di Ethereum una voce sconosciuta vale zero, quindi qualsiasi messaggio che il contratto non aveva mai visto contava come già dimostrato. Il primo attaccante prese 100 WBTC; poi centinaia di altri copiarono la transazione, inserirono il proprio indirizzo e la ripeterono. Circa 190 milioni di dollari uscirono in poche ore. Nessuna chiave fu rubata e nessun firmatario mentì. Un valore di configurazione spense la verifica.
Un solo verificatore e dati avvelenati: Kelp nel 2026
Il caso Kelp del 18 aprile 2026 ha unito una configurazione debole a un attacco ai dati del verificatore. Secondo LayerZero, riportata da The Block il 9 maggio 2026 (in inglese), gli attaccanti hanno compromesso i nodi RPC interni che la DVN di LayerZero Labs usava per leggere la catena di partenza, ne hanno avvelenato i dati e hanno messo fuori uso i fornitori RPC esterni con un attacco denial-of-service, così la DVN ha dato il via libera a un trasferimento mai avvenuto. LayerZero attribuisce l’attacco al Lazarus Group nordcoreano, un’attribuzione che non abbiamo potuto confermare da una fonte governativa.
Chi abbia impostato il verificatore unico è oggetto di disputa. LayerZero ha detto che Kelp usava una configurazione 1-of-1 contro le sue raccomandazioni. Kelp ha dichiarato il 20 aprile, come riportò CoinDesk (in inglese), che l’impostazione rifletteva il valore predefinito documentato da LayerZero ed era stata confermata durante l’espansione sui livelli 2. A maggio LayerZero ha scritto «we made a mistake by allowing our DVN to act as a 1/1 DVN for high-value transactions» (testo originale inglese), ha detto che la sua DVN non supporterà più configurazioni 1-of-1 e ha portato i valori predefiniti ad almeno cinque verificatori ove possibile, con un minimo di tre.
Il danno è andato oltre Kelp. L’attaccante ha usato gli rsETH rubati come garanzia su Aave, che ha congelato i suoi mercati rsETH su V3 e V4 e ha dichiarato che il problema era rsETH, non i propri contratti. Il rischio di un token trasferito via bridge ricade su ogni protocollo che lo accetta come garanzia.
Valore coniato senza copertura: Liquid Network nel 2026
Le sidechain di bitcoin portano lo stesso rischio. Il 6 settembre 2026 un attaccante ha coniato circa 4.000 L-BTC senza alcun bitcoin dietro su Liquid, la sidechain di Blockstream, e li ha riscattati in BTC veri tramite SideSwap, un operatore di peg-out approvato, con la federazione 11-di-15 che firmava il rilascio. Secondo TRM Labs (in inglese) sono passati 36 minuti tra il conio e il pagamento e la perdita è stata di circa 319 milioni di dollari. Halborn la riconduce a una cache in Elements, il software dei nodi di Liquid, la cui chiave non includeva l’ID dell’asset e il contesto dello script, così una prova verificata una volta poteva convalidare un output diverso. La federazione firmò in buona fede: il suo software diceva che le monete erano valide. Il 7 settembre l’attaccante, che si è dichiarato white hat, ha restituito circa 3.400 BTC dopo che i nodi hanno corretto il bug; circa 598,5 BTC sono rimasti a lui, secondo TRM Labs.
Messi uno accanto all’altro, i casi si dividono in quattro famiglie: chiavi in mano a troppo poche parti indipendenti (Ronin, Harmony, Multichain), un bug nella verifica (Wormhole, Binance Bridge, Liquid), un errore di aggiornamento o di configurazione (Nomad, e l’impostazione 1-of-1 in Kelp) e la fiducia in dati off-chain (i nodi RPC di Kelp). Nessuno ha rotto la crittografia. Ognuno ha rotto un’ipotesi su chi stesse controllando.
Intent e solver: qualcun altro si accolla il percorso
I sistemi a intent rovesciano il problema. Invece di inviare una transazione che compie ogni passaggio, l’utente firma il risultato che vuole («cedo 1.000 USDC su Arbitrum e ne voglio almeno 999 su Base») e terze parti in concorrenza, chiamate solver, filler o relayer, lo consegnano con il proprio capitale. Vengono rimborsate dopo, quando lo strato di regolamento ha verificato che hanno consegnato.
Intent sulla stessa catena: i batch di CoW e le aste di UniswapX
CoW Protocol è il caso di scuola su una sola catena. La sua documentazione (in inglese) descrive un intent firmato che «is not an executable user transaction» (testo originale inglese): i solver competono per regolare un batch di ordini, tutte le operazioni sulla stessa coppia in un batch si chiudono a un unico prezzo e gli ordini opposti si possono abbinare direttamente tra loro. Il solver vincitore si assume il rischio di esecuzione. UniswapX, di Uniswap, usa ordini firmati e un’asta olandese: l’ordine parte dal miglior prezzo per l’utente e scende verso un minimo finché un filler non lo ritiene conveniente; l’utente non paga gas e non paga nulla per una transazione fallita.
Intent tra catene: come regola Across
Across applica l’idea tra una catena e l’altra. Secondo la sua pagina sull’architettura (in inglese), i relayer eseguono l’ordine dell’utente sulla catena di arrivo con il proprio denaro, competendo sulla velocità, e scelgono la catena su cui farsi rimborsare. Un Dataworker off-chain raggruppa i fill in pacchetti di circa 1,5 ore, li confronta con i depositi e propone ogni pacchetto al contratto HubPool su Ethereum con una cauzione. L’UMA Optimistic Oracle protegge il processo: un pacchetto viene accettato a meno che qualcuno non lo contesti, e basta un solo contestatore onesto. I bridge canonici riequilibrano i pool dietro le quinte.
L’attesa dell’utente si riduce al tempo di reazione del relayer, e l’utente non dipende più dai sette giorni del bridge canonico. Ne dipende il relayer, e fa pagare quel capitale. Al 28 ottobre 2026 DefiLlama conta appena 17 milioni di dollari bloccati in Across e 208 milioni in NEAR Intents, un altro sistema a intent: nei contratti sta poco capitale perché i filler portano il proprio.
ERC-7683 è ancora una bozza
Ogni sistema a intent ha un proprio formato di ordine, il che costringe i solver a scrivere codice su misura per ciascuno. ERC-7683, Cross Chain Intents (in inglese), creato l’11 aprile 2024, propone un’interfaccia comune: ogni protocollo pubblica un contratto resolver che traduce i propri ordini in una descrizione condivisa di passaggi e pagamenti, così i solver possono valutare un ordine senza codice dedicato. Al 28 ottobre 2026 il suo stato sul sito degli EIP è Draft. Il testo attuale si è ristretto a quel passaggio di risoluzione dopo una versione precedente che copriva più parti del ciclo di vita dell’ordine. Quali prodotti implementino la bozza attuale non siamo riusciti a verificarlo.
Anche gli intent sono stati colpiti: Across e NEAR Intents nel 2026
Gli intent spostano il rischio, non lo eliminano. Il 17 luglio 2026 un attaccante ha falsificato 1.627 eventi di deposito su Solana, per un valore nominale di circa 41,7 milioni di dollari, sfruttando un controllo mancante nel software relayer off-chain che legge gli eventi di Solana, come riportò The Cryptonomist (in inglese). Il relayer ne ha eseguiti 581 prima che Solana fosse disattivata come catena di origine, pagando circa 4,5 milioni di dollari di capitale proprio di Risk Labs (DefiLlama registra 4,5 milioni). Nessuno smart contract è stato compromesso, i trasferimenti genuini sono stati completati o rimborsati lo stesso giorno e il servizio su Solana è ripreso circa 12 ore dopo tramite CCTP. Il capitale del filler ha assorbito la perdita, cioè il progetto ha funzionato, ma il lettore di eventi restava comunque un punto di fiducia.
Il 1° ottobre 2026 NEAR Intents si è fermato dopo perdite di circa 3,8 milioni di dollari. Il team le ha attribuite in un primo momento a un bug nel modo in cui la sua infrastruttura Omni di deposito e prelievo interagiva con il contratto NEAR Intents e ha promesso un risarcimento integrale, come riportò The Block (in inglese). Il post-mortem pubblicato il 16 ottobre dall’amministratore delegato Alex Shevchenko ha raccontato un’altra storia: il difetto stava nel contratto NEAR Intents, non in Omni. A ogni deposito il contratto notificava un contratto di terzi; il contratto dell’attaccante faceva fallire apposta quella notifica, così il contratto del token rimborsava il deposito mentre NEAR Intents teneva il credito nel proprio registro. Con 23 depositi falliti di questo tipo l’attaccante ha accumulato circa 3,8 milioni di dollari di saldi senza copertura e ha prelevato token veri contro di essi. Secondo il post-mortem i fondi sono rientrati entro 36 ore e gli utenti colpiti sono stati risarciti; una seconda segnalazione sulla stessa funzione ne ha portato alla rimozione il 7 ottobre e a una taglia di 300.000 dollari. DefiLlama classifica il caso come difetto nella logica del bridge.
Nativo, di terze parti o a intent: il confronto
| Bridge nativo o dell’emittente | Bridge di terze parti o messaggistica | Sistema a intent | |
|---|---|---|---|
| Chi verifica | Il sistema di prove del rollup, o l’emittente (Circle per il CCTP) | Validatori, un comitato o verificatori scelti dall’app | Uno strato di regolamento dopo che il filler ha pagato |
| Attesa tipica | Circa 7 giorni in uscita da un rollup ottimistico; da 8 secondi a 19 minuti per il CCTP | Dipende dai verificatori e dalla catena di partenza | Appena un filler agisce |
| Che cosa ricevi | L’asset nativo | Spesso una copia wrapped, a volte il token nativo | L’asset nativo, dal filler |
| Che cosa si rompe | Sistema di prove o emittente | Chiavi, controlli delle firme, configurazione | Software del filler, controlli di regolamento |
| Chi perde per primo | Ogni possessore dell’asset trasferito | I possessori del token wrapped, poi i protocolli che lo usano come garanzia | Di solito il capitale del filler |
Per un utente dalla tabella escono due regole. I trasferimenti grandi e senza fretta di un asset con un percorso nativo (ETH in uscita da un rollup, USDC tramite CCTP) hanno meno ipotesi di fiducia aggiuntive. I trasferimenti rapidi vanno bene quando è il capitale di qualcun altro a sopportare il rischio dell’attesa, ma il prezzo è una commissione e, per i token wrapped, l’esposizione al bridge finché li tieni.
Bridge crypto: la lista di controllo per un trasferimento sicuro
Prima di spostare una somma che conta, passa in rassegna questi punti. Richiedono dieci minuti e il costo di una piccola commissione di prova in gas.
- Apri il bridge dall’indirizzo ufficiale, digitato o salvato tra i preferiti, mai da un annuncio nei motori di ricerca, da un messaggio privato o da un link in un post su Discord o Telegram.
- Invia prima un importo di prova e controlla che sia arrivato dove ti aspettavi, sulla catena giusta e come token giusto.
- Verifica il token esatto che riceverai: l’asset nativo, la versione ufficiale dell’emittente o una copia wrapped il cui valore dipende dal bridge.
- Scopri chi verifica il trasferimento: il rollup, l’emittente, un insieme fisso di validatori o la configurazione di un’applicazione, e quante parti indipendenti ciò significa.
- Per gli USDC tra catene supportate, confronta il percorso CCTP con quelli che ti consegnano un dollaro digitale wrapped.
- Leggi l’approvazione del token che il wallet ti chiede di firmare, approva solo l’importo che stai inviando e revoca poi le vecchie approvazioni illimitate.
- Se aggiungi una rete al wallet, controlla chain ID e indirizzo RPC sulla documentazione del progetto.
- Tieni un po’ di token nativo per il gas sulla catena di arrivo, altrimenti non potrai spostare ciò che hai trasferito.
- Conserva gli hash delle transazioni su entrambe le catene finché il trasferimento non è definitivo e visibile nel wallet.
- Annota data, importi e controvalore in euro per la tua contabilità fiscale.
Bridge falsi e catene false
Anche il front end di un bridge è un bersaglio di phishing. A fine settembre 2026 un bridge contraffatto per GIWA, il livello 2 sviluppato da Dunamu, l’operatore di Upbit, ha ricevuto circa 767,65 ETH da 1.335 indirizzi prima che i truffatori ne svuotassero 766,25, circa 2 milioni di dollari, secondo Cointelegraph (in inglese); DefiLlama lo registra al 27 settembre come truffa per impersonificazione da 2,08 milioni di dollari. GIWA ha dichiarato che la sua mainnet non era attiva. DYORSWAP, un exchange decentralizzato che aveva scambiato il bridge falso per la mainnet di GIWA, ha rimborsato di tasca propria più di 200 ETH agli utenti colpiti. Una catena che non è stata lanciata non può avere un bridge. La nostra guida su come evitare le truffe crypto copre gli altri schemi.
Bridge crypto in Italia: regole e tasse
Sul piano delle regole, il Regolamento europeo MiCA si applica ai prestatori di servizi per le cripto-attività (CASP), autorizzati in Italia sotto la vigilanza di Banca d’Italia e Consob, mentre l’OAM tiene l’elenco dei prestatori di servizi relativi all’utilizzo di valuta virtuale. Un bridge usato in autonomia, senza intermediario, è un’altra cosa: il considerando 22 di MiCA dice che i servizi prestati in modo completamente decentralizzato e senza alcun intermediario non rientrano nel regolamento. È un considerando, non un articolo né un’esenzione scritta, e quanto una singola applicazione sia davvero priva di intermediario (un front end gestito da una società, un team che aggiorna i contratti) è una valutazione caso per caso. Non abbiamo trovato posizioni di Consob, Banca d’Italia o OAM specifiche sui bridge. Nella guida a MiCA trovi il quadro generale.
Sul fronte fiscale, per il 2026 l’Agenzia delle Entrate applica il 33% alle plusvalenze da cripto-attività. Ma il trattamento di un trasferimento tramite bridge non è chiarito: non abbiamo trovato una presa di posizione dell’Agenzia delle Entrate che nomini i bridge o il wrapping. Il caso più lineare è quello degli USDC nativi spostati con il CCTP, che somiglia al trasferimento dello stesso asset; ricevere un token wrapped diverso in cambio di ETH può assomigliare invece a una permuta, e quindi a un’operazione che realizza una plusvalenza o una minusvalenza. Le due letture portano a conseguenze diverse e nessuna norma ne sceglie una per te. Conserva tutta la documentazione, ogni passaggio con data, importi e controvalore in euro, e consulta la nostra guida alle tasse sulle crypto in Italia; per un trasferimento rilevante, chiedi un parere a un commercialista.
Come termine di paragone, la pagina dell’IRS sugli asset digitali (in inglese) tratta lo scambio di un asset digitale con un altro come una cessione da dichiarare e i trasferimenti tra wallet propri come non imponibili, senza nominare i bridge. Le autorità non hanno scritto regole specifiche sui bridge. Cercando, non abbiamo trovato nulla sul tema da parte della SEC o della CFTC negli Stati Uniti. Fare un bridge ti lascia inoltre con ciò che il bridge ti consegna: se un token wrapped perde la copertura, nessuna garanzia sui depositi e nessun fondo di indennizzo degli investitori lo copre.
La prossima lezione del corso sulla DeFi lascia le catene e confronta la DeFi con gli exchange centralizzati e con la finanza tradizionale, pilastro per pilastro, seguendo una singola operazione dall’inizio alla fine.
