Sumar articol:
În DeFi, codul nu descrie regulile, codul este regula. Când îți depui colateralul într-un protocol de lending sau când pui lichiditate într-un pool, nu te bazezi pe un funcționar, pe un call center ori pe un set de proceduri interne. Te bazezi pe o bucată de software care execută totul automat, cu aceeași răceală cu care un ceas își mișcă acele.
Tocmai de aceea, securitatea contractelor inteligente a devenit, în ultimii ani, o problemă de infrastructură. Nu mai vorbim doar despre programatori care își verifică munca, ci despre un întreg ecosistem care încearcă să țină în frâu un risc ce se reinventează permanent.
Pe 19 februarie 2026, OpenAI și Paradigm au făcut public un instrument numit EVMbench, conceput să evalueze cât de bine se descurcă agenții de inteligență artificială atunci când trebuie să identifice, să repare sau să exploateze vulnerabilități din contracte inteligente. Lansarea a venit într-un moment sensibil, la câteva zile după ce un bug legat de cod generat cu ajutorul AI a declanșat pierderi de aproape 2,7 milioane de dolari pentru utilizatori ai protocolului Moonwell.
Informația despre EVMbench a fost adusă rapid în atenția publicului din România de Cryptology.ro, site-ul de știri și analize crypto în limba română, iar articolul de față pornește de la această relatare și o dezvoltă pe înțelesul tuturor.
De ce apare EVMbench acum, când piața pare deja plină de audituri
De fiecare dată când apare un atac mare în DeFi, reacția pieței este aproape reflexă. Echipele promit audituri suplimentare, cresc bugetele pentru bug bounty, își întăresc monitorizarea on-chain și, uneori, schimbă complet arhitectura. Industria a acumulat experiență, dar a acumulat și un adevăr incomod: auditul reduce riscul, nu îl elimină.
În plus, contractele inteligente nu sunt un software obișnuit. Odată lansate și folosite de mii de oameni, nu le poți opri ca pe un server clasic. Orice corecție cere guvernanță, upgrade-uri, migrări, iar în unele cazuri cere chiar rescriere.
În acest context a intrat în scenă inteligența artificială. Modelele de azi nu mai sunt doar instrumente care îți sugerează fragmente de cod. Pot lucra ca agenți: primesc o sarcină, răsfoiesc un proiect, rulează teste, schimbă fișiere, încearcă exploatări într-un mediu controlat și revin cu o soluție. Pentru securitate, această schimbare e dublă. Apărătorii pot folosi agenții pentru a găsi buguri mai repede, dar atacatorii pot folosi exact același tip de capacitate pentru a automatiza exploatarea.
EVMbench nu promite că va opri atacurile. Este mai degrabă un instrument de măsurare. Dacă vrei să știi cât de mare e un val, pui un reper pe mal. Asta face benchmark-ul: încearcă să ofere o măsură, repetabilă și comparabilă, a modului în care agenții AI se comportă în fața unor vulnerabilități severe, din lumea reală.
Ce este EVM și de ce contează pentru aproape tot DeFi-ul
EVM, Ethereum Virtual Machine, este mediul standard în care rulează contractele inteligente pe Ethereum și pe multe rețele compatibile. Chiar dacă un utilizator obișnuit intră în DeFi pe Base, Arbitrum, Optimism ori o altă rețea, în spate logica este, de cele mai multe ori, aceeași: contracte scrise pentru EVM. Asta face ca vulnerabilitățile să fie, uneori, portabile. O greșeală într-un contract, dacă este copiată într-o altă implementare, poate fi replicată în lanț.
Din acest motiv, un benchmark axat pe EVM are relevanță largă. Nu se uită doar la Ethereum ca rețea, ci la întregul univers de aplicații compatibile, unde aceleași tipare de design reapar, aceleași biblioteci sunt refolosite și, inevitabil, aceleași greșeli tind să se strecoare.
Cum a fost construit EVMbench și ce tip de probleme include?
EVMbench este construit pe 120 de vulnerabilități selectate ca fiind de severitate ridicată, extrase din 40 de audituri anterioare. O bună parte dintre aceste cazuri provin din competiții publice de audit, acolo unde proiecte sau sponsori pun la bătaie recompense pentru descoperirea bugurilor.
Pe lângă cazurile istorice, EVMbench include și scenarii de vulnerabilități inspirate din procesul de audit pentru Tempo, un blockchain aflat în dezvoltare, proiectat pentru plăți rapide și ieftine cu stablecoins.
Alegerea nu este întâmplătoare. Vulnerabilitățile istorice sunt utile fiindcă sunt documentate și verificabile, însă lumea reală se schimbă, iar codul de plăți are particularități care pot deveni tot mai frecvente. O aplicație de lending are un set de riscuri, un contract care orchestrează plăți recurente și transferuri în masă are alte colțuri sensibile.
Includerea scenariilor Tempo sugerează că EVMbench nu vrea să rămână blocat în trecut, ci încearcă să prindă și zonele unde DeFi-ul începe să se transforme în infrastructură de plăți.
Din punct de vedere tehnic, benchmark-ul rulează sarcinile în medii izolate, tocmai pentru a nu crea un instrument periculos în lumea reală. Agenții lucrează într-un container, fără acces la internet, iar exploatările au loc într-o instanță locală de EVM, nu pe rețele publice.
Grading-ul este făcut programatic, prin verificarea stării blockchain-ului local, a tranzacțiilor și a schimbărilor deterministe de balanțe. Un detaliu relevant este că OpenAI a construit și întărit un harness în Rust, inclusiv cu restricții pentru metode RPC riscante, pentru a limita tentativele de a păcăli evaluarea.
Aceste detalii par tehnice, dar au un sens simplu: dacă vrei să testezi exploatarea, trebuie să oferi un mediu realist, însă fără să expui bani reali și fără să lași loc pentru scurtături. În DeFi, un exploit reușit nu este o poveste frumoasă, ci o stare finală verificabilă, de tipul fonduri drenate sau o condiție critică declanșată. EVMbench încearcă să transforme această realitate într-un test reproductibil.
Ce evaluează, concret, benchmark-ul?
EVMbench testează trei tipuri de capabilități, dar în spatele lor se ascunde o singură provocare majoră: acoperirea completă. În viața reală, un auditor nu câștigă dacă găsește doar o problemă. Un protocol poate avea două, trei, cinci vulnerabilități severe, iar atacatorul are nevoie de una singură. Așadar, un agent care se oprește după primul bug descoperit poate arăta bine într-un demo, dar nu ajută suficient într-un audit serios.
În partea de detectare, agenții trebuie să parcurgă un proiect și să producă un raport, iar scorul se bazează pe cât de multe vulnerabilități reale sunt identificate. În patch, agenții modifică efectiv codul, iar evaluarea verifică două lucruri în același timp: vulnerabilitatea să nu mai fie exploatabilă și funcționalitatea legitimă să rămână în picioare, cu testele relevante trecute. În exploatare, agentul primește acces la o instanță locală de blockchain, chei și endpoint-uri pentru interacțiune, apoi trebuie să ducă atacul până la capăt.
Această structură e importantă pentru că arată diferența dintre un instrument care doar semnalează probleme și un agent care poate opera end-to-end, în stilul unui atacator. În audit, semnalarea este utilă, dar exploatarea completă îți confirmă că problema chiar poate produce pierderi.
Rezultatele inițiale și semnalul pe care îl transmit
Când te uiți la scoruri, primul lucru care sare în ochi este că agenții tind să fie mai buni la exploatare decât la apărare. OpenAI arată că în modul de exploatare, GPT‑5.3‑Codex rulat prin Codex CLI ajunge la un scor de 72,2%, în timp ce GPT‑5, un model lansat cu puțin peste șase luni înainte, obține 31,9%. Saltul e prea mare ca să fie ignorat. Înseamnă că ritmul de progres pe partea ofensivă poate depăși ritmul cu care echipele de securitate își schimbă procesele.
În același timp, detectarea și patch-uirea rămân sub acoperire completă. Explicația este mai intuitivă decât pare. Atacul are un obiectiv limpede: să ajungă la fonduri, să le miște, să dovedească reușita. Într-un sandbox, agentul poate încerca iar și iar, până când găsește drumul bun. Detectarea cere răbdare și exhaustivitate.
Patch-ul cere și mai mult: trebuie să închizi ușa atacului fără să strici casa. În contractele DeFi, casa are multe camere, colateral, dobândă, oracole, limite de lichidare, integrări cu alte protocoale. O schimbare mică poate avea efecte neașteptate.
În testele comparate, un model de la Anthropic, Claude Opus 4.6, a obținut cel mai bun scor mediu la detectarea vulnerabilităților, în timp ce GPT‑5.3‑Codex a ieșit în față la patch și exploatare. Asta sugerează că, în practică, nu există un singur model care să domine fiecare etapă. Pentru echipele de securitate, mesajul este că viitorul ar putea arăta ca un workflow mixt, în care instrumentele sunt alese în funcție de sarcină.
OpenAI avertizează că EVMbench are limite. Setul de vulnerabilități este finit, iar lumea reală inventează mereu combinații noi. În plus, atunci când un agent raportează ceva în afara problemelor cunoscute, benchmark-ul nu poate decide cu certitudine dacă e o descoperire reală sau un fals pozitiv. În securitate, falsul pozitiv consumă resurse și poate împinge echipele către modificări care nu erau necesare.
Incidentul Moonwell, un exemplu care a pus paie pe foc
EVMbench a fost lansat la câteva zile după un episod care a agitat comunitatea. Pe forumul de guvernanță Moonwell a fost publicată o propunere de recuperare care descrie un interval clar, 14–18 februarie 2026, în care o parte dintre utilizatorii care foloseau cbETH drept colateral pe Base au fost lichidați în mod considerat nedrept.
Documentul vorbește despre pierderi totale nete de aproximativ 2,68 milioane de dolari, distribuite pe aproximativ 181 de împrumutați.
Propunerea insistă asupra ideii că nu a fost vorba de riscul normal de piață, ci de un comportament al protocolului legat de o schimbare de parametri, ceea ce în practică înseamnă că oamenii au pierdut nu pentru că au pariat greșit pe volatilitate, ci pentru că mecanismul intern a reacționat anormal.
Textul mai detaliază o metodologie de reconstrucție on-chain a lichidărilor din acel interval și o abordare de remediere în care o parte din fonduri ar veni imediat dintr-o trezorerie, iar restul ar fi acoperit treptat din venituri viitoare ale protocolului.
În spațiul public cripto, incidentul a fost asociat și cu ideea de cod generat cu ajutorul AI. Un inginer Moonwell a spus că bucata de cod discutată trecuse printr-un audit al firmei Halborn, însă problema tot a produs pagube. În jurul acestui subiect a fost menționat și Claude, modelul Anthropic, în contextul în care o parte din cod ar fi fost generată cu suport AI.
Pentru un utilizator obișnuit, toate aceste detalii se pot amesteca ușor, dar lecția este directă. În DeFi, un bug nu rămâne un bug. Devine un eveniment economic. Îți schimbă poziția, îți schimbă balanța, îți schimbă încrederea.
De ce auditul, oricât de serios, nu poate fi tratat ca o garanție?
E ușor să crezi că un audit este un fel de poliță de asigurare. Dar auditul este mai degrabă un control tehnic într-un moment în timp. Codul se schimbă, integrările se schimbă, parametrii se schimbă. În plus, multe vulnerabilități nu arată ca niște greșeli evidente. Unele apar din interacțiuni, din ordinea apelurilor, din presupuneri greșite despre un oracol, din condiții de margine pe care testele nu le ating.
Când intră în scenă codul generat cu ajutorul AI, problema capătă o dimensiune nouă. Codul generat poate fi corect, poate fi chiar elegant, dar poate ascunde un detaliu pe care dezvoltatorul îl acceptă prea repede. Uneori nu pentru că este neglijent, ci pentru că ritmul de livrare crește. Dacă primești o soluție în câteva secunde, tentația este să o pui în producție după un review scurt, mai ales într-o echipă mică.
În același timp, agenții AI pot deveni o armă defensivă serioasă. Pot rula audituri interne repetate, pot genera teste suplimentare, pot simula atacuri în sandbox. Însă tocmai aici apare paradoxul. Cu cât apărătorii se bazează mai mult pe agenți, cu atât atacatorii au motive să facă același lucru.
Agenții AI, între paznic și hoț
Un agent AI nu are o intuiție magică. Are capacitatea de a executa rapid pași, de a încerca variante, de a învăța din feedback-ul obținut din test. În modul de exploatare, acest lucru devine extrem de potent. Un agent poate porni de la un repository mare, poate identifica o zonă fragilă, poate construi un contract ajutător, poate trimite tranzacții și poate itera până când obține rezultatul dorit.
Diferența dintre un auditor uman și un agent, în multe situații, nu este inteligența pură, ci rezistența la repetitivitate. Omul obosește. Agentul nu. Iar când recompensa este drenarea unui pool, repetitivitatea este o strategie.
Asta explică și de ce EVMbench este interesant ca instrument de monitorizare. Dacă vezi că scorurile pe exploatare cresc accelerat, înțelegi că trebuie să îți întărești procesele defensive înainte ca „tactica standard” a atacatorilor să fie automatizată complet.
Ce schimbă EVMbench pentru dezvoltatori și echipele de securitate?
Un benchmark nu îți repară codul, dar îți poate schimba obiceiurile. Pentru dezvoltatori, mesajul este că un agent AI poate fi un coleg util, însă nu poate fi tratat ca un autor care își asumă răspunderea. Codul generat rămâne un draft până când este înțeles, testat, pus sub stres și revizuit.
Pentru echipele de securitate, EVMbench sugerează că e timpul să separi clar sarcinile. Detectarea cere acoperire completă și rigoare, patch-uirea cere înțelegerea arhitecturii și atenție la regresii, iar exploatarea cere creativitate și determinare. Dacă modelele au puncte forte diferite, atunci și pipeline-ul ar trebui să fie construit în jurul acestor diferențe.
Mai există și o lecție legată de testare. În patch mode, un agent trebuie să păstreze funcționalitatea, nu doar să închidă bugul. Asta pune presiune pe calitatea testelor scrise de oameni. Dacă testele sunt superficiale, un patch poate trece, dar poate rupe o logică importantă pe care nimeni nu a acoperit-o.
Ce înseamnă toate acestea pentru utilizatorii care nu scriu cod?
Majoritatea oamenilor care folosesc DeFi nu vor citi niciodată un audit. Interfața este cea care inspiră încredere, nu repository-ul. Totuși, evenimente precum Moonwell arată că riscul tehnic nu se vede în UI. Randamentele pot arăta liniștitoare, graficele pot arăta stabile, însă dedesubt rămâne un set de reguli automate.
În practică, un utilizator ar trebui să înțeleagă un lucru simplu: un protocol este atât de sigur cât sunt componentele lui cele mai fragile. Când un activ nou este acceptat drept colateral, se adaugă risc. Când se schimbă parametrii de lichidare, se adaugă risc. Când un oracol este actualizat, se adaugă risc. Când o echipă accelerează dezvoltarea cu AI, se adaugă risc dacă disciplina de testare nu crește în același ritm.
Asta nu înseamnă că DeFi trebuie evitat. Înseamnă că DeFi trebuie tratat ca infrastructură experimentală, chiar și atunci când pare matură. Un protocol poate arăta impecabil luni întregi și totuși să aibă un colț de logică exploatabil.
Tempo, stablecoins și ideea de plăți făcute de agenți
Tempo apare în EVMbench ca sursă de scenarii tocmai pentru că plățile cu stablecoins ar putea deveni următoarea zonă unde agenții AI intră cu adevărat în viața de zi cu zi. O aplicație care face plăți automate nu seamănă cu un DEX, chiar dacă folosește aceleași primitive EVM. În plăți, accentul cade pe volum, pe latență mică, pe costuri predictibile și pe robustețe.
Pe hârtie, stablecoins par liniștitoare. Au un preț relativ stabil, deci reduc anxietatea pe care o simți când vezi un activ volatil. Dar stabilitatea prețului nu elimină riscul tehnic. Dacă logica de decontare este greșită sau dacă un mecanism de verificare se poate păcăli, paguba nu vine din volatilitate, vine din cod.
Un agent care gestionează plăți în numele tău ar putea fi o comoditate uriașă. În același timp, dacă acel agent interacționează cu contracte vulnerabile, automatizarea devine un multiplicator de risc. De aceea, măsurarea capabilităților agentice în medii de plăți nu este un exercițiu abstract. Este un indicator despre cât de repede trebuie să evolueze securitatea.
Unde se adună tensiunea: responsabilitate, viteză și bani reali
După fiecare incident, apare întrebarea vinovatului. Dezvoltatorul, auditorul, modelul, instrumentul, ecosistemul. În realitate, responsabilitatea este împărțită, iar inteligența artificială o împarte și mai mult. Un instrument AI nu semnează un raport de audit. Un instrument AI nu își asumă pierderea unui utilizator. În schimb, un instrument AI poate accelera munca, iar accelerația, dacă nu este dublată de disciplină, produce accidente.
Aici EVMbench joacă un rol interesant. Dacă devine un reper, va influența comportamentul industriei. Modelele vor fi comparate, îmbunătățite și integrate în procese. Asta va crește, probabil, eficiența defensivă. Dar va crește și eficiența ofensivă, fiindcă atacatorii urmăresc aceleași progrese.
În presa cripto, DeFiLlama a fost citat cu o cifră care nu lasă loc de confort: peste 108 milioane de dolari pierduți în hackuri și exploatări în 2026, până la mijlocul lui februarie. În spatele acestei sume sunt zeci de incidente, mici și mari, iar fiecare incident este o lecție plătită de utilizatori.
În analiza editorială publicată de Cryptology.ro, site de știri și analize crypto în limba română, Mihai Popa a insistat asupra unui detaliu care se pierde ușor în zgomot: faptul că AI nu schimbă natura riscului, ci îi schimbă viteza, iar în DeFi viteza este exact ceea ce face paguba să se propage.
Ce rămâne de reținut?
EVMbench este un semn că industria începe să trateze inteligența artificială ca pe un factor de securitate, nu doar ca pe un instrument de productivitate. Dacă agenții ajung să exploateze cu o rată de succes care depășește 70% într-un set de vulnerabilități severe, atunci discuția despre apărare devine urgentă.
Episodul Moonwell arată că o problemă de logică, combinată cu dinamica unui protocol folosit de oameni reali, produce pagube reale. Iar faptul că acel cod a trecut printr-un audit și totuși a ajuns să fie asociat cu pierderi de milioane spune ceva despre cât de aspră este realitatea DeFi.
Securitatea contractelor inteligente nu mai poate fi tratată ca o etapă de bifat. Este o practică permanentă, în care oamenii, auditul, testele și agenții AI trebuie să se completeze, nu să se înlocuiască. Într-o lume în care banii circulă la viteza codului, singurul avantaj stabil este disciplina. Restul este doar noroc, iar norocul, în DeFi, se consumă repede.
