Pe 7 mai 2026, o singură tranzacție pe Ethereum a scos 5,87 milioane de dolari din trezoreria TrustedVolumes. Patru active drenate la rând, în interiorul aceluiași bloc, iar firmele care monitorizează permanent rețeaua au descris public mecanismul înainte ca echipa atacată să fi confirmat oficial că s-a întâmplat ceva. TrustedVolumes opera ca furnizor de lichiditate și resolver în ecosistemul Fusion al 1inch, ceea ce face cazul greu de explicat la prima vedere.
Nu vorbim aici despre o vulnerabilitate de tip zero-day și nici despre chei private compromise printr-un atac sofisticat. Codul vulnerabil putea fi citit de oricine se ostenea să arunce o privire peste el, iar problema centrală era vizibilă cu ochiul liber pentru cineva care înțelegea ce înseamnă o verificare de autorizare făcută cum trebuie.
Trei greșeli s-au compus într-un singur contract, un proxy RFQ pe care echipa TrustedVolumes îl construise pe cont propriu și pe care îl conectase la trezorerie prin aprobări ERC-20 nelimitate. Fiecare dintre acele greșeli ar fi fost prinsă într-un audit decent. Niciuna nu a fost prinsă, pentru că auditul respectiv pare să nu fi existat vreodată.
Cineva a deschis contractul, a văzut unde lipsește gardul și a trecut prin el cu patru extrageri succesive. Costul real al operațiunii, după cum a arătat ulterior reconstrucția Foundry, a fost de patru wei USDC. O sumă pe care doar matematica o poate exprima fără să-i piardă semnificația, plătită aproape ritualic de atacator către inventarul TrustedVolumes pentru a îndeplini o cerință formală din contract, cum că trebuie să trimită ceva înapoi la fiecare swap. Atât a stat între un cont oarecare de pe Ethereum și milioanele aflate sub aprobare nelimitată.
Patru active, o singură tranzacție, banii dispăruți
Conform analizei publicate de QuillAudits, prada s-a împărțit pe patru active calculate la prețurile pieței din ziua respectivă. Cel mai consistent transfer a fost cel de USDC, cu 1.268.771 de stablecoini scoși din inventar, urmat îndeaproape de 1.291 WETH care, după desfacere, au luat drumul portofelului atacatorului ca ETH lichid.
Suma s-a rotunjit cu încă 206.282 USDT și cu 16,939 WBTC, totalul ajungând la cei 5,87 milioane de dolari pe care îi cunoaștem. Anunțul ulterior al echipei TrustedVolumes a vorbit despre o cifră ușor mai mare, în jur de 6,7 milioane, diferența rezultând din variațiile de preț din intervalul scurt dintre exploit și conversia activelor.
Întreaga operațiune s-a desfășurat într-o singură tranzacție pe blockchain-ul Ethereum, validată în blocul 25039669. Atacatorul a folosit un contract dedicat, lansat cu puțin timp înainte, prin care a apelat de patru ori funcția de fill a proxy-ului RFQ vulnerabil.
Fiecare apel scotea câte un activ din cele aflate sub aprobare nelimitată și nu cerea în schimb nicio semnătură reală din partea victimei. La fiecare extragere, contractul atacatorului trimitea înapoi câte un wei USDC, gest aproape ceremonios pe care logica protocolului îl trata ca pe un swap legitim.
Sumele ajunse în contractul atacatorului au fost convertite rapid, în câteva minute, către ETH și consolidate în portofelele finale. Cineva care a operat astfel a urmărit clar să transforme activele tranzacționabile în valoare lichidă înainte ca presiunea comunitară sau coordonarea cu bursele centralizate să poată îngheța rutele de spălare. Toată conversia se închisese deja când TrustedVolumes a apărut public, târziu, cu prima confirmare a incidentului.
Anatomia unui exploit care n-ar fi trebuit să fie posibil
Trei vulnerabilități, montate într-o arhitectură care le-a permis să se completeze între ele aproape perfect. Fiecare în parte ar fi fost prinsă printr-o revizuire minimă a codului. Combinația lor a produs ceea ce cercetătorul cunoscut online sub numele banteg a denumit în reconstrucția sa Foundry o eroare de delimitare a autorizării.
Tipul acesta de eroare nu este nou pe Ethereum. Există un istoric întreg de incidente care își au rădăcina în confuzia dintre verificarea identității și verificarea drepturilor, începând chiar de la afacerea Parity Multisig din 2017 și continuând prin zeci de cazuri mai discrete pe parcursul anilor care au urmat. Ce surprinde aici este însă faptul că aceeași clasă de greșeală apare, în 2026, într-un contract care păzește milioane de dolari în trezoreria unui operator activ pe piață.
O funcție publică pe care nimeni nu a închis-o
Totul a început cu o funcție numită registerAllowedOrderSigner, lăsată practic deschisă oricui dorea să o cheme. Orice adresă de pe Ethereum putea să o apeleze și să se înregistreze pe sine drept semnatar valid pentru un anumit maker, fără să întâlnească vreun control de proprietate sau vreo verificare de rol. Pur și simplu nu exista un filtru pe acea cale.
Atacatorul a chemat funcția respectivă, s-a înregistrat ca semnatar pentru propria adresă în calitate de maker și a devenit, dintr-o singură mișcare, un participant tehnic „valid” în logica contractului. Nu i s-a cerut să demonstreze nimic privind deținerea unui activ sau vreo legătură reală cu inventarul protocolului. A trebuit doar să apeleze de pe orice adresă, ceea ce și-a permis fără efort.
Deschiderea absolută a unei funcții cu rol de control al accesului intră, în terminologia auditorilor de smart contracts, în categoria anti-pattern-urilor recunoscute de aproape un deceniu. Trail of Bits, OpenZeppelin și ConsenSys Diligence avertizează asupra problemei de ani buni prin documentele lor publice, iar materiale educaționale precum Ethernaut sau Damn Vulnerable DeFi îi sunt dedicate sub o formă sau alta.
Faptul că o astfel de funcție a ajuns în producție într-un contract care păzește milioane sugerează ceva mai grav decât o simplă scăpare tehnică.
Închiderea acelei funcții ar fi cerut o singură linie de cod. Un modificator de tipul onlyOwner sau o verificare explicită a apelantului împotriva unei liste de adrese autorizate ar fi blocat complet vectorul. Lipsa acelei linii nu este un fenomen pe care un audit profesionist să-l rateze, iar asta lasă deschisă o singură concluzie verosimilă. Nu a existat un astfel de audit.
Verificare făcută pe adresa greșită
A doua vulnerabilitate este, până la urmă, cea care transformă prima într-o problemă financiară reală. În momentul executării funcției fillOrder, contractul verifica dacă semnatarul ordinului era autorizat. Numai că verifica această autorizare împotriva adresei greșite.
Conform analizei tehnice publicate de SlowMist, codul căuta în maparea allowedOrderSigner folosind drept cheie adresa takerului, adică a apelantului controlat de atacator, în loc să folosească adresa makerului care deținea efectiv inventarul.
Tradus simplu, contractul confirma că atacatorul are dreptul să semneze pentru sine însuși, lucru trivial adevărat după înregistrarea de la pasul anterior, dar nu verifica nicăieri dacă semnatarul respectiv are vreo legătură cu fondurile pe care urma să le miște.
Autentificarea, adică „cine ești”, și autorizarea, adică „ce ai voie să faci”, au fost tratate ca aceeași întrebare. Sunt însă două întrebări complet distincte, iar diferența dintre ele este fundamentală în arhitectura sistemelor sigure. Un sistem care răspunde corect la prima și o ignoră pe a doua nu este, propriu-zis, un sistem securizat. Este un sistem care își amână problema până la apariția primului atacator competent să citească cu atenție.
Greșeala de mapare are, dincolo de consecințele ei imediate, un caracter aproape didactic. Este genul de bug pe care îl primești ca exemplu de discuție într-un workshop avansat de Solidity, tocmai pentru a învăța să faci diferența dintre cheile sub care indexezi permisiunile.
Câmpul taker, folosit pe dos
A treia componentă a exploit-ului vine din modul în care contractul determina sursa transferului. Codul folosea câmpul taker din structura ordinului drept adresă „from” pentru transferul efectiv de tokeni, iar atacatorul a setat acel taker egal cu adresa care deținea inventarul TrustedVolumes.
Pe ramura aceasta de execuție, autorizarea către contractul proxy fusese acordată cu mult timp în urmă, sub forma unor aprobări ERC-20 nelimitate. Contractul putea, tehnic, să mute orice token de pe adresa care deținea inventarul, fără nicio semnătură suplimentară. Atacatorul nu a avut nevoie să forțeze aprobarea pentru că ea exista deja, oferită voluntar de TrustedVolumes propriului său proxy.
Mecanismul de extragere a fost astfel complet operat de propria logică a protocolului. Atacatorul a transmis instrucțiuni, contractul a executat transferurile, iar inventarul s-a golit fără ca vreo alarmă să se declanșeze. Din punctul de vedere al codului, tot ce se întâmpla rămânea perfect conform regulilor pe care chiar codul le scrisese.
Aprobările nelimitate sunt o practică des întâlnită în DeFi și se justifică prin eficiența operațională pe care o aduc. Eliminarea lor ar presupune semnături la fiecare swap, ceea ce ar consuma timp și fonduri suplimentare de gaz pentru utilizatorii activi. Compromisul este cunoscut. Numai că, pentru un protocol care păzește trezorerie reală, costul scăzut al unei aprobări permanente devine, până la urmă, riscul cel mai mare în absența unui audit suficient.
Protecția anti-replay care nu păzea nimic
A patra slăbiciune, neclasificată întotdeauna ca bug separat dar la fel de consecventă în efecte, este mecanismul de protecție împotriva reluării ordinelor. Conform reproducerii Foundry, variabila saltStatus, gândită să marcheze ordinele deja executate, scria într-o cheie de storage și citea, în momentul verificării, dintr-o cheie diferită.
Practic, fiecare dintre cele patru apeluri consecutive trecea de testul de replay fără rezistență, pentru că testul respectiv nu avea cum să vadă urmele apelului anterior. Aceeași greșeală structurală, repetată patru ori la rând în interiorul aceleiași tranzacții, a permis ca exploit-ul să fie eficient și complet, nu doar reușit inițial.
Dacă oricare dintre cele patru probleme ar fi fost rezolvată corect, atacul ar fi eșuat sau cel puțin s-ar fi oprit la primul drenaj. Coexistența lor sugerează însă o calitate uniformă a codului, nu o serie de scăpări izolate. Sună mai degrabă a un contract scris dintr-o suflare și deployat fără să fi fost lăsat să se odihnească măcar o zi sub privirea unui auditor extern.
Cum s-a desfășurat tranzacția pe blockchain?
Tranzacția unică prin care s-a derulat exploit-ul este confirmată pe Ethereum sub un hash care începe cu prefixul 0xc5c61b3a, vizibil în continuare pe Etherscan pentru oricine vrea să verifice cu propriii ochi ce s-a întâmplat. În interiorul ei, cele patru apeluri către funcția de fill au curs secvențial, fiecare scoțând câte un activ și predându-l contractului-capcană controlat de atacator.
Contractul exploit, lansat la o adresă cu prefixul 0xD4D5DB5E, a fost construit explicit pentru o singură întrebuințare. A jucat simultan rolurile de maker și de receiver în structurile ordinelor falsificate, a primit activele drenate și le-a transmis mai departe către conturile finale ale atacatorului. Proxy-ul RFQ vulnerabil, găzduit la o adresă cu prefix vanity 0xeEeEEe53, a procesat instrucțiunile cu o seninătate de bibliotecar care nu observă că rafturile se golesc.
Inventarul TrustedVolumes, păstrat la o adresă separată sub controlul echipei, s-a golit complet pe cele patru active. Aprobările nelimitate acordate proxy-ului în trecut, gândite ca o optimizare pentru a evita semnături repetate la fiecare swap, au funcționat exact cum fuseseră concepute. Doar că instrucțiunile transferurilor veneau, de data asta, dintr-o sursă neașteptată.
După ce activele au ajuns în contractul exploit, WETH-ul a fost desfăcut în ETH lichid, iar restul tokenurilor au luat aceeași cale spre adresele de stocare operate de atacator. Cele două portofele principale au păstrat fondurile vizibile public, fără să fie încă spălate prin mixere sau distribuite pe rețele cross-chain la momentul publicării analizelor.
Toate aceste mișcări s-au succedat în câteva minute pe blockchain. Atacatorul a avut conversia gata făcută înainte ca echipa TrustedVolumes să apuce să scrie primul tweet despre incident, iar etapa de extragere efectivă a profitului se închisese deja când mesajele oficiale începeau să apară.
Reacția firmelor de securitate, mai rapidă decât a echipei
CertiK a fost prima firmă care a semnalat atacul, printr-o postare care descria deja, în câteva fraze, mecanismul exact al exploit-ului. Avertismentul includea recomandarea explicită ca utilizatorii să-și revoce aprobările acordate contractului vulnerabil. Recomandarea venea însă târziu pentru că la momentul publicării atacul fusese deja consumat în întregime.
Șaizeci de secunde mai târziu a apărut Blockaid, cu o relatare mai detaliată care liste adresa contractului victimă, adresa atacatorului și suma cumulată drenată în cele patru active. SlowMist a venit curând după, cu o reconstrucție tehnică a cauzei rădăcină care identifica exact greșeala de mapare din verificarea semnatarului. Cele trei firme operaseră independent una de cealaltă, dar ajunseseră la aceeași concluzie practic simultan.
Reproducerea Foundry publicată de banteg a venit ca o confirmare definitivă. Era reconstruită pas cu pas în Solidity, însoțită de o diagramă D2 a fluxului și de dovezi on-chain validate împotriva unui fork al blocului în care exploit-ul fusese executat. Concluzia tehnică era cât se poate de simplă. Orice adresă cu patru wei USDC și un sfert de oră de atenție putea executa atacul, fără să aibă nevoie de semnături prealabile sau să compromită vreo cheie privată.
Echipa TrustedVolumes a confirmat oficial incidentul abia după aproximativ două ore și jumătate de la primul alert public. Postarea, transmisă pe contul oficial de pe X, oferea o adresă de bug bounty și o invitație la „comunicare constructivă”, fără să intre în detalii despre felul în care fusese construit contractul, despre deciziile arhitecturale care permiseseră exploit-ul sau despre pașii planificați pentru recuperarea fondurilor.
Decalajul dintre comunitatea de securitate și echipa atacată a fost mai mult decât simbolic. A indicat un dezechilibru evident între atenția pe care actorii externi o acordă protocolului și atenția pe care echipa internă o acorda propriei infrastructuri. Dovezile sugerează că exploit-ul fusese complet vizibil pentru oricine ar fi monitorizat cu seriozitate codul de producție.
Un protocol care a tăcut un an, până nu a mai avut de ales
Postarea de confirmare a fost prima activitate publică a TrustedVolumes pe Twitter după o tăcere care depășea cu mult un an de zile. Pe parcursul acelui an nu apăruse niciun anunț despre actualizări tehnice, despre integrări noi sau despre revizuiri de securitate, ceea ce ridicase deja, pentru cine urmărea, semne de întrebare privind starea reală a proiectului.
Site-ul oficial al protocolului, accesibil la trustedvolumes.com, listează secțiuni dedicate pentru CeFi, DeFi, API și o pagină About Us. Documentația API duce însă într-o fundătură. O adresă URL de bază, un endpoint de producție și atât. Nu se găsește nicăieri o arhitectură descrisă, nicio publicare de revizii de securitate și niciun release note care să indice că proiectul este menținut activ din punct de vedere tehnic.
Pentru un protocol care funcționa drept market maker și resolver, deținând active estimate la milioane de dolari în trezorerie, infrastructura publică se reducea la un nume, o adresă de email pe Proton Mail și o pagină de documentație fără conținut real. Niciun audit al proxy-ului RFQ vulnerabil nu a fost publicat vreodată. Codul implementării nu a fost niciodată verificat pe Etherscan, ceea ce însemna că singurul mod de a inspecta logica reală a contractului era reverse engineering pe bytecode.
Pentru o piesă de cod care păzea aprobări nelimitate peste un inventar de milioane, absența documentației publice și a verificării sursei spune mai mult decât orice declarație oficială ulterioară. În ecosistemul DeFi, transparența codului nu este un detaliu cosmetic, ci principalul argument prin care un protocol convinge piața că merită aprobări permanente.
Adresa de bug bounty rămâne deschisă, conform postării oficiale a TrustedVolumes. Dacă atacatorul va răspunde sau nu este o întrebare separată, iar răspunsul depinde de calcule pe care doar el le poate face. Invitația merge într-o direcție. Fondurile au mers deja în cealaltă.
Dinamica aceasta nu este nouă. Mai multe protocoale atacate în ultimii ani au încercat negocieri directe cu atacatorii, cu rezultate amestecate. Unele au recuperat o parte semnificativă din fonduri, altele au rămas cu mâna goală, iar câteva au transformat invitația într-o bătălie publică care s-a întins pe luni de zile. Modelul, oricât de imperfect, a devenit o componentă acceptată a peisajului DeFi, în care lipsa unor mecanisme legale clare împinge protocoalele spre soluții improvizate.
Aprilie negru pentru DeFi, mai nu pare diferit
Pierderea de la TrustedVolumes vine după o lună aprilie deja consemnată ca un record recent al furturilor în spațiul DeFi. Conform unei sinteze publicate de The Defiant, 28 de incidente separate au cumulat 635 de milioane de dolari sustrași în decurs de patru săptămâni. A fost cea mai gravă lună înregistrată din februarie 2025 încoace, momentul în care spargerea Bybit produsese un șoc similar pentru piață.
Tipologia incidentelor a fost variată, dar pattern-ul de fond se repetă cu o regularitate care a început să obosească până și pe cei plătiți să o raporteze. Unul a venit dintr-o eroare de autorizare, altul dintr-o manipulare de oracle, al treilea dintr-o cheie privată compromisă prin inginerie socială.
La acestea s-au adăugat contracte lansate fără revizuiri externe și integrări insuficient testate cu protocoale terțe. Fiecare incident apare îmbrăcat într-un detaliu tehnic propriu, dar în spatele detaliilor se află de obicei aceeași structură. Cineva a construit ceva care mișca bani, a ales să sară peste etapele de validare critică și a presupus că nimeni nu va privi codul suficient de atent.
În rapoartele cumulate din primele cinci luni ale anului 2026, totalul fondurilor sustrase din protocoale DeFi se apropie deja de pragul de două miliarde de dolari, conform datelor compilate de Chainalysis și Hacken pe parcursul aceleiași perioade. Ritmul incidentelor s-a accelerat după o pauză scurtă în martie, iar TrustedVolumes este al treilea protocol semnificativ atacat în primele zece zile ale lunii mai.
Repetiția aceasta nu mai surprinde pe nimeni dintre observatorii spațiului, dar continuă să fie scrisă în rapoarte ca și cum ar fi o noutate. Probabil pentru că singura alternativă, recunoașterea faptului că industria trăiește cu un nivel acceptat de risc operațional, ar deschide o discuție mult mai inconfortabilă despre încrederea reală pe care utilizatorii ar trebui sau nu să o acorde infrastructurii pe care o folosesc zilnic.
Industria a încercat, sub diverse forme, să răspundă acestei probleme prin programe de bug bounty extinse, prin audituri standardizate sau prin asigurări on-chain care preiau o parte din risc. Niciuna dintre aceste soluții nu este, deocamdată, generalizată suficient pentru a schimba traiectoria. Atacurile continuă, iar pierderile cumulate confirmă că măsurile reactive nu țin pasul cu rata de deployment al codului nou.
Aceleași greșeli, alți operatori, același rezultat
Pattern-ul e simplu și începe să devină familiar. Cineva construiește un contract care mută milioane, iar din diverse motive omite pasul revizuirii de securitate.
O echipă păstrează tăcerea publică peste un an de zile, până când nu mai are nimic de spus dincolo de confirmarea drenajului. Un atacator are nevoie de o funcție publică, de o verificare de autorizare aliniată greșit și de o trezorerie fără gard de protecție, iar toate astea există exact așa cum sunt. Rezultatul urmează în mod previzibil.
Reconstrucția lui banteg a arătat că exploit-ul putea fi executat de orice adresă cu fonduri minime și ceva timp liber. Observația aceasta, mai mult chiar decât suma efectiv pierdută, este partea cu adevărat tulburătoare. O barieră de patru wei USDC și un sfert de oră de atenție separa inventarul TrustedVolumes de oricine se ostenea să citească codul public.
Adresa de bug bounty rămâne deschisă, iar pe ea se construiește singurul scenariu favorabil care le mai rămâne celor de la TrustedVolumes. O parte din fonduri s-ar putea întoarce, fie printr-o negociere directă, fie prin presiune comunitară, fie pur și simplu pentru că atacatorul a obosit să le țină.
Un asemenea scenariu, oricât de favorabil financiar, nu rezolvă însă problemele structurale care au făcut posibil incidentul. Recuperarea de fonduri, când se întâmplă, rămâne o ușurare contabilă, nu o lecție tehnică pentru cei care construiesc DeFi.
Vectorii se schimbă de la o lună la alta, însă structura subiacentă rămâne aceeași. Sub o lună e vorba despre chei private, sub alta despre oraculi, sub a treia despre autorizări sau despre integrări complicate. Numele subcategoriilor se rotesc, dar logica este invariabilă. Cineva a construit ceva care păzea active reale și a sărit peste partea în care întreba dacă a construit acel ceva în siguranță.
În mai 2026, TrustedVolumes a devenit, prin omisiune, ilustrația acestei reguli, încă o dată. Întrebarea care rămâne deschisă este aceeași ca în cazurile anterioare. Dacă a fost nevoie de o pierdere de 5,87 milioane de dolari pentru ca echipa să accepte că proxy-ul ei merita o revizuire externă, atunci ce plan funcționa pentru perioada de dinaintea apariției atacatorului.
Întrebarea, judecând după pattern-ul ultimilor ani, își va găsi următorul răspuns abia după următorul drenaj de aceleași dimensiuni, dintr-un alt protocol care nu se aștepta să fie vreodată citit cu atenție.
Intrebari Frecvente(FAQ)
TrustedVolumes este un furnizor de lichiditate și resolver activ în ecosistemul Fusion al protocolului 1inch, care operează pe Ethereum în calitate de market maker. Trezoreria sa era conectată la un proxy RFQ construit intern de echipă, prin aprobări ERC-20 nelimitate.
Pe 7 mai 2026, un atacator a executat o singură tranzacție pe Ethereum prin care a apelat de patru ori funcția de fill a proxy-ului RFQ vulnerabil al TrustedVolumes, drenând patru active din inventar. Suma totală sustrasă, conform analizei on-chain, a fost de 5,87 milioane de dolari.
Cauza tehnică a fost o combinație de trei vulnerabilități compuse într-o eroare de delimitare a autorizării. Funcția registerAllowedOrderSigner era complet permisivă, verificarea semnatarului folosea ca cheie adresa apelantului în loc de adresa makerului, iar contractul folosea câmpul taker drept adresă sursă pentru transfer. La acestea s-a adăugat un bug de replay care nu citea ce scria, permițând patru drenaje succesive.
Contractul nu a fost niciodată verificat pe Etherscan și nu există niciun audit public al implementării RFQ. Codul sursă nu a fost open-sourced, iar echipa nu publicase nicio actualizare publică pe Twitter de peste un an înainte de incident.
Setup-ul tehnic al atacului a costat patru wei USDC, echivalentul a câteva miimi de cent. Atacatorul a folosit un contract dedicat, lansat înainte de exploit, plus costul standard de gaz al tranzacției pe Ethereum.
Nu, la momentul publicării analizelor inițiale. TrustedVolumes a oferit o adresă de bug bounty și o invitație la „comunicare constructivă”, însă fondurile rămâneau distribuite în două adrese controlate de atacator, după ce WETH-ul fusese convertit în ETH.
Luna aprilie 2026 a înregistrat 635 milioane de dolari sustrași în 28 de incidente, cea mai gravă lună DeFi din februarie 2025 încoace. Pierderea TrustedVolumes adaugă încă un caz la un trimestru deja dificil pentru spațiul DeFi, totalul cumulat din primele cinci luni apropiindu-se de două miliarde de dolari.
CertiK a fost prima firmă care a semnalat exploit-ul, urmată la șaizeci de secunde de Blockaid și apoi de SlowMist cu o analiză tehnică detaliată. Reconstrucția Foundry a fost publicată ulterior de cercetătorul cunoscut sub numele banteg.
