Il drenaggio di Avici spiegato: cosa è successo e cosa devono fare gli utenti

Il caso Avici è iniziato il 28 agosto 2026, quando sono emerse segnalazioni di oltre 600.000 dollari usciti dai conti usati come garanzia per le carte. Le prime stime on-chain sono variate rapidamente: da circa 600.000 dollari a oltre 1 milione, mentre venivano tracciati i movimenti verso wallet controllati dall'attaccante. In seguito, Rain, il partner di Avici per l'emissione delle carte, ha indicato una vulnerabilità in una vecchia versione di un contratto Solana per le carte e ha riferito che i contratti interessati erano stati aggiornati. Le cifre iniziali, però, non devono essere considerate automaticamente come il totale definitivo della perdita. 49 50 53

La distinzione più importante riguarda il tipo di fondi coinvolti. Le segnalazioni indicavano i contratti separati utilizzati per sostenere i saldi delle carte, non necessariamente i wallet ordinari self-custodial con cui gli utenti conservavano altri asset su Solana o sulle reti EVM. 50 53

Come Avici trasformava le criptovalute in spesa Visa

Avici utilizzava un modello di carta garantita, diverso da un normale conto bancario. Secondo la documentazione del servizio:

1. l'utente depositava USDC in uno smart contract di loan escrow;
2. il deposito generava un saldo di credito in dollari per la carta;
3. ogni acquisto riduceva quel credito;
4. gli USDC corrispondenti alla spesa venivano liquidati dal contratto della carta in un secondo momento, generalmente dopo uno o più giorni. 35

La documentazione spiegava inoltre che il contratto della garanzia era distribuito su una rete EVM, ma poteva ricevere depositi provenienti da Solana attraverso un meccanismo di auto-bridging. Il wallet della carta era separato dallo smart wallet e Visa poteva prelevare i fondi soltanto dimostrando che era stata effettuata una spesa. 33

Questo modello spiegava il principale vantaggio del prodotto: spendere contro le proprie criptovalute senza trasferire l'intero patrimonio a un exchange centralizzato o a una banca. Ma introduceva anche una catena tecnica articolata, composta da smart contract, bridge, infrastruttura dell'emittente della carta e sistemi di autorizzazione delle transazioni.

In altre parole, “self-custodial” non significava che ogni componente del sistema fosse semplice, indipendente o privo di rischi. I fondi destinati alla carta entravano in un sistema programmabile distinto dal wallet principale.

Cosa è successo: dalle prime ipotesi alla ricostruzione successiva

Le prime ore: un problema sui prelievi dei saldi delle carte

Il 28 agosto Avici ha riconosciuto un problema che riguardava i prelievi dai saldi delle carte, mentre gli osservatori on-chain segnalavano movimenti verso indirizzi controllati dall'attaccante. Le prime ricostruzioni hanno indicato perdite comprese tra circa 600.000 e 653.000 dollari; altre hanno seguito più di 1 milione di dollari attraverso il wallet sospetto. Questi numeri potrebbero riferirsi a fasi o flussi diversi e non vanno sommati senza una riconciliazione completa. 49 51 54 58

In quella fase non era ancora possibile stabilire se la causa fosse:

• un difetto nel contratto della carta o della garanzia;
• la compromissione di un sistema di autorizzazione, relay o account abstraction;
• l'abuso di passkey, sessioni o deleghe amministrative;
• un attacco di phishing;
• oppure un problema in un altro componente della piattaforma, come front end, bridge o infrastruttura del partner.

L'aggiornamento di Rain: vulnerabile un vecchio contratto Solana

Un aggiornamento successivo ha attribuito l'incidente a una vulnerabilità scoperta da Rain in una vecchia versione del contratto Solana per le carte, utilizzata da Avici e da un numero limitato di altri programmi. I contratti interessati sarebbero stati aggiornati e, al momento della comunicazione, non risultavano ulteriori attività non autorizzate. Secondo la stessa ricostruzione, l'incidente riguardava il contratto Solana separato che custodiva i saldi delle carte dopo il top-up; i wallet self-custodial Solana ed EVM degli utenti erano segregati e non risultavano coinvolti. 50 62

Una successiva comunicazione ha indicato una perdita riconciliata di 500.859,22 dollari a danno di 1.685 utenti, con l'impegno di Avici a rimborsare integralmente gli interessati. 53

Questa cifra è più precisa delle stime diffuse durante l'attacco, ma la differenza va interpretata correttamente: le prime cifre erano conteggi in tempo reale dei movimenti on-chain, mentre quella successiva sarebbe il risultato della riconciliazione dei saldi colpiti.

Perché il phishing resta una pista importante

L'ipotesi della vulnerabilità del contratto non elimina il rischio, distinto, dei siti di phishing. Il 28 agosto sono stati segnalati siti falsi che imitavano Avici e promuovevano presunti airdrop o funzioni della piattaforma. Gli utenti venivano invitati a collegare il wallet e a firmare transazioni che trasferivano i fondi. Alcuni resoconti hanno attribuito a un sito-clone perdite superiori a 600.000 dollari e, in quel momento, non riportavano prove pubbliche di una violazione interna di Avici. 2 4

Le due spiegazioni non si escludono necessariamente. Una vulnerabilità del contratto può aver colpito i conti collegati ai saldi delle carte, mentre una campagna separata di impersonificazione può aver sottratto fondi agli utenti che hanno firmato transazioni malevole.

Senza un rapporto tecnico completo — con indirizzi, contratti, istruzioni delle transazioni e orari — non è prudente attribuire ogni perdita segnalata alla stessa causa.

Cosa manca ancora nel rapporto pubblico

La documentazione disponibile non chiarisce completamente:

• quale fosse l'esatta versione vulnerabile del contratto e quali fossero i suoi indirizzi di distribuzione;
• quale istruzione o sequenza di transazioni abbia permesso l'exploit;
• se l'attaccante abbia ottenuto privilegi amministrativi non autorizzati o sfruttato un diverso percorso di autorizzazione;
• quali account e saldi siano stati coinvolti in modo definitivo;
• come l'attività sia stata rilevata e con quale rapidità siano stati aggiornati i contratti;
• come funzionerà il rimborso e quale sarà il suo perimetro;
• se alcuni utenti debbano rinnovare passkey, sessioni, deleghe, credenziali o altri metodi di autorizzazione.

L'attribuzione successiva di Rain è una spiegazione rilevante per l'incidente dei saldi delle carte, ma non autorizza a concludere che ogni drenaggio collegato ad Avici sia stato causato dalla stessa vulnerabilità. Per chiudere il caso servirebbe un post-mortem dettagliato, verificabile anche da soggetti indipendenti.

Cosa devono fare ora gli utenti potenzialmente coinvolti

1. Smettere di usare link e contratti sospetti

Non interagire con Avici o con i contratti collegati alle carte attraverso link ricevuti in messaggi privati, pubblicità, risposte sui social o annunci di presunti airdrop. Per verificare gli aggiornamenti, usare un dominio ufficiale salvato nei preferiti o un canale di assistenza autenticato e controllato autonomamente.

2. Distinguere tra autorizzazioni sospette e compromissione della seed phrase

Se è stata inserita una frase di recupero, esposta una chiave privata, installata un'estensione wallet non affidabile o firmata una transazione sconosciuta, è prudente trasferire gli asset rimasti in un wallet nuovo, creato su un dispositivo o ambiente pulito.

La revoca delle autorizzazioni non risolve una compromissione della seed phrase o della chiave di firma: in quel caso il wallet originario non dovrebbe più essere considerato sicuro.

3. Controllare le autorizzazioni su ogni rete

Per i wallet EVM, verificare le allowance dei token e rimuovere gli spender sconosciuti o le autorizzazioni illimitate. Controllare anche eventuali session key, deleghe o permessi di account abstraction sospetti, se supportati dal wallet.

Per i wallet Solana, esaminare le transazioni firmate di recente, le applicazioni collegate, le deleghe sconosciute e le sessioni attive. Solana non utilizza esattamente lo stesso modello di approvazioni delle reti EVM: uno strumento generico per revocare le token approval potrebbe quindi non individuare tutte le autorizzazioni rilevanti.

4. Conservare le prove

Salvare indirizzi dei wallet, firme delle transazioni, URL sospetti, screenshot, orari e messaggi o annunci che hanno portato all'interazione. Questi elementi possono aiutare Avici, il provider del wallet o gli investigatori a distinguere un caso di phishing da un incidente a livello di contratto.

5. Diffidare delle truffe successive

Non firmare transazioni di “verifica”, “rimborso” o “recupero” inviate da account non richiesti. Gli utenti già colpiti diventano bersagli particolarmente appetibili per impostori che promettono di restituire i fondi rubati.

Cosa insegna il caso Avici sulla self-custody

La self-custody modifica il modello di rischio, ma non elimina il rischio. L'utente può evitare di affidare a un custode centralizzato il controllo unilaterale dei propri asset, ma resta esposto a wallet software, smart contract, bridge, relay, passkey, autorizzazioni delegate, interfacce web, emittenti delle carte e procedure di regolamento.

Il confronto con il furto collegato a Coldcard nel 2026 è istruttivo. In quell'episodio, secondo le ricostruzioni disponibili, circa 594 BTC furono sottratti da circa 500 wallet in approssimativamente 25 minuti dopo un problema del firmware che aveva indebolito la casualità utilizzata per generare i seed. Il difetto riguardava il dispositivo e il suo firmware, non la crittografia alla base di Bitcoin. 30

Avici rappresenta una categoria diversa: un prodotto di pagamento può mantenere separato il wallet generale dell'utente e al tempo stesso collocare la garanzia della carta in un sistema specializzato di contratti, con dipendenze proprie.

La lezione non è che la self-custody sia intrinsecamente insicura, né che la custodia centralizzata sia automaticamente più sicura. È che la sicurezza di un prodotto di pagamento self-custodial dipende dall'intero percorso della transazione. Prima di usarlo, è essenziale capire quali asset restano nel wallet ordinario, quali vengono trasferiti a un contratto della carta o di escrow, chi può autorizzare i prelievi, come vengono gestiti gli aggiornamenti e cosa accade se un contratto o un partner fallisce.