Rețelele crypto au fost construite pentru oameni. Sistemele autonome trebuie să învețe să facă singure ceea ce până acum făceau utilizatorii umani.
Blockchain-urile funcționează impecabil la nivel de execuție. Tranzacțiile se procesează determinist, consensul se atinge matematic, starea finală e imuabilă. Și totuși, atunci când un agent AI încearcă să opereze autonom pe un lanț, se lovește de un zid pe care niciun whitepaper nu l-a anticipat cu adevărat.
Nu e vorba despre o limitare a protocolului, ci despre tot ce se află deasupra lui, mai precis despre acele straturi intermediare prin care oamenii interpretează, filtrează și decid.
Un raport publicat de Galaxy Digital în aprilie 2026, semnat de cercetătorul Zack Pokorny, analizează tocmai această tensiune structurală. Ideea centrală e simplă, dar cu implicații adânci: rețelele blockchain nu au fost proiectate pentru a fi operate de mașini autonome.
Au fost gândite pentru utilizatori umani care citesc interfețe, verifică adrese vizual și semnează tranzacții cu un clic conștient. Când elimini omul din ecuație, toate acele funcții implicite trebuie reconstruite programatic, iar infrastructura actuală nu oferă instrumentele necesare.
Cum funcționează un blockchain, pe scurt?
La bază, un blockchain este un sistem de consens. Mai multe calculatoare din întreaga lume cad de acord asupra unei stări comune, fără să aibă nevoie de o autoritate centrală. Fiecare tranzacție e validată, fiecare rezultat e determinist, iar odată confirmat, nimic nu mai poate fi modificat retroactiv.
Problema apare la nivelul a ceea ce blockchain-ul expune participanților săi. Protocolul oferă acces la sloturi de stocare, jurnale de evenimente și urme de apeluri. Nu oferă însă obiecte economice standardizate. Concepte precum „poziție deschisă”, „randament anual”, „factor de sănătate” sau „adâncime a lichidității” nu sunt primitive ale protocolului. Ele sunt reconstruite de indexatori, platforme de analiză, interfețe web și API-uri care traduc starea brută a contractelor inteligente într-o formă pe care un om o poate parcurge rapid.
Și aici apare discrepanța. Un utilizator obișnuit vede un dashboard curat, cu cifre rotunjite și butoane intuitive. Un agent AI vede bytecode, structuri de date eterogene și funcții care returnează valori fără context semantic. Practic, agentul trebuie să refacă de la zero tot ceea ce interfața grafică face în mod transparent pentru un utilizator uman.
Ce e, de fapt, un agent AI?
Termenul „agent AI” a fost folosit intens în ultimii ani, adesea cu sensuri diferite. În contextul blockchain-urilor, Galaxy Digital propune o distincție utilă între agenții AI propriu-ziși și sistemele algoritmice tradiționale. Diferența nu ține de automatizare, sofisticare sau parametrizare.
Un bot de tranzacționare poate fi extrem de avansat, poate scana contracte noi, poate ajusta dinamic strategia, poate reechilibra portofolii. Cu toate astea, un bot nu e un agent.
Diferența fundamentală stă în capacitatea de a gestiona situații neprevăzute la momentul construcției. Un algoritm tradițional funcționează pe baza unor reguli prestabilite. Dacă întâlnește un scenariu pentru care nu a fost programat, fie îl ignoră, fie eșuează. Nu poate raționa despre situații nefamiliare, ci doar verifică dacă situația se potrivește unui șablon cunoscut.
Un agent bazat pe modele lingvistice de mari dimensiuni face ceva calitativ diferit. Poate interpreta obiective ambigue, poate citi un contract inteligent pe care nu l-a mai văzut, poate analiza documentația aferentă și poate deduce funcția economică a unui sistem nou. Poate evalua probabilistic încrederea pe care o acordă unui contract, poate interpreta erori și se poate adapta pe parcurs.
Aceste capacități sunt reale, dar departe de a fi infailibile. Modelele generative halucinează, comit erori cu un grad ridicat de certitudine aparentă și pot pierde capital în medii adversariale. Teza raportului Galaxy nu e că agenții AI funcționează impecabil în prezent, ci că încearcă să facă lucruri pe care sistemele tradiționale nici nu le abordează. Și tocmai acolo apar problemele.
Cele patru categorii de fricțiune
Galaxy Digital identifică patru zone distincte de fricțiune pe care agenții AI le întâmpină atunci când operează pe blockchain: descoperirea, verificarea legitimității (planul de control), accesul la date și execuția propriu-zisă.
Fricțiunea de descoperire
Într-un ecosistem fără bariere de acces, oricine poate lansa un contract inteligent pe lanț. Un protocol legitim, o clonă malițioasă, un proiect abandonat și un deployment de test arată identic din perspectiva blockchain-ului. Toate sunt bytecode apelabil, fără nicio etichetă de calitate sau relevanță atașată.
Oamenii filtrează natural acest zgomot. Urmăresc anunțuri pe rețelele sociale, verifică listele agregatoarelor precum DeFiLlama, citesc audituri, consultă comunitățile de pe Discord sau Telegram. Procesul e informal și imperfect, dar funcționează suficient de bine pentru că se sprijină pe intuiție și experiență acumulată. Un utilizator care petrece timp în ecosistem învață să distingă un protocol serios de o imitație slab camuflată.
Un agent AI nu dispune de aceste euristici sociale. Poate fi alimentat cu date curate și liste de încredere, dar construirea și menținerea acelor liste într-un mediu care se schimbă zilnic reprezintă o sarcină operațională considerabilă. Iar atunci când listele sunt incomplete sau depășite, agentul nu are mecanismul de rezervă pe care omul îl folosește instinctiv.
Descoperirea nu se referă doar la detectarea unor noi contracte. Sistemele algoritmice sofisticate fac deja asta cu succes. Un bot care monitorizează evenimentele de factory ale Uniswap și integrează automat pool-urile noi face descoperire dinamică, dar o face într-un perimetru strict definit. Știe exact ce tipuri de interfețe caută, pentru că strategia i le definește.
Un agent cu un mandat deschis, de tipul „alocă fondurile în oportunitățile cu cel mai bun raport risc-randament”, nu se poate baza exclusiv pe filtre derivate din strategie. Trebuie să evalueze oportunități necunoscute în raport cu obiectivul propriu, ceea ce presupune parsarea unor interfețe nefamiliare, deducerea funcției economice a unor protocoale noi și decizia dacă oportunitatea respectivă aparține sau nu universului decizional al agentului.
Fricțiunea din planul de control
Verificarea legitimității e poate cel mai contraintuitiv obstacol dintre toate. Pe un blockchain, nu există nicio noțiune nativă de „acesta e contractul oficial al aplicației X”. Asta nu e o eroare de design, ci o consecință directă a naturii deschise și fără permisiuni a sistemului. Dar pentru un agent autonom, absența unei identități canonice creează un risc direct și concret.
Exemplul cel mai grăitor vine chiar de la un token atât de fundamental precum Wrapped Ether, cunoscut sub simbolul WETH. Contractul autentic definește un nume, un simbol și un număr de zecimale. Dar orice alt contract poate returna exact aceleași valori. Funcțiile name(), symbol() și decimals() sunt simple funcții publice care returnează ce a stabilit autorul la momentul creării. Pe Ethereum există aproape 200 de tokeni care au numele „Wrapped Ether”, simbolul „WETH” și 18 zecimale. Dintre toți, doar unul e cel autentic, dar lanțul nu verifică unicitatea și nu validează nimic printr-un registru intern.
Un utilizator uman rezolvă problema apelând la Etherscan, CoinGecko sau la site-ul oficial al proiectului. Folosește stratul de încredere al web-ului ca un verificator informal. Navighează pe un domeniu oficial, descoperit de obicei printr-un agregator sau un cont social verificat, și tratează acel site drept sursă de adevăr pentru maparea dintre concepte umane și adrese de contract.
Un agent nu interpretează brandingul, semnalele sociale sau „oficialitatea” prin context social. Poate primi date curate derivate din aceste semnale, dar transformarea lor în ipoteze de lucru durabile, accesibile mașinii, necesită registre explicite, politici formale sau logică de verificare dedicată.
Consecințele practice ale unei verificări slabe au apărut deja pe piață. Un agent asociat unui YouTuber și influencer crypto cunoscut sub numele Orangie a depus fonduri într-un contract de tip honeypot, adică o capcană din care fondurile nu mai pot fi retrase. Într-un alt caz, un agent numit Lobstar Wilde a transferat un sold semnificativ de tokeni unui „cerșetor” online, după ce o eroare de context l-a determinat să interpreteze greșit starea adresei proprii. Aceste incidente arată cum deficiențele în verificarea identității contractelor se traduc în pierderi reale de capital.
Fricțiunea de date
Un agent care optimizează portofolii DeFi are nevoie de o viziune normalizată asupra fiecărei oportunități ca obiect economic, incluzând randamente, adâncime a lichidității, parametri de risc, structuri de comisioane și surse de oracol. Blockchain-urile nu expun obiecte economice standardizate la nivelul protocolului. Expun sloturi de stocare, jurnale de evenimente și rezultate ale funcțiilor, din care obiectele economice trebuie deduse sau reconstruite de către cel care le interoghează.
Eterogenitatea protocoalelor agravează dramatic această problemă. Prețul unei acțiuni de vault, factorul de colateralizare al unei piețe de lending, adâncimea lichidității unui pool pe un exchange descentralizat și rata de recompensă a unui contract de staking sunt toate informații economice relevante. Niciuna nu e expusă printr-o interfață standardizată. Fiecare familie de protocoale are propriile tipare de extragere, propriile structuri de date și propriile convenții de unitate.
Raportul Galaxy Digital ilustrează această fragmentare cu un exemplu concret: piețele de creditare descentralizată. Conceptele economice sunt familiare și în mare parte comune, adică lichiditatea disponibilă pentru depunere și împrumut, ratele dobânzilor, factorii de colateralizare, pragurile de lichidare. Dar căile prin care un agent poate obține aceste date sunt radical diferite de la un protocol la altul.
Pe Aave v3, enumerarea activelor de rezervă și extragerea stării reprezintă pași separați. Agentul trebuie mai întâi să obțină lista adreselor de tokeni prin funcția getReservesList(), apoi, pentru fiecare activ, să apeleze getReserveData(), funcție care returnează o structură conținând totaluri de lichiditate, indici de rată și flaguri de configurare, totul într-un singur apel.
Pe Compound v3, cunoscut și sub numele de Comet, fiecare implementare reprezintă o singură piață, iar nu există o structură unificată de rezervă. Un snapshot complet al pieței trebuie construit din apeluri separate: getUtilization() pentru utilizarea de bază, totalsBasic() pentru totalurile agregate, getSupplyRate() și getBorrowRate() pentru ratele dobânzilor, getAssetInfo() pentru configurarea activelor colaterale, la care se adaugă parametrii globali de configurare.
Din perspectiva unui agent, ambele protocoale sunt piețe de lending cu funcții economice similare. Din perspectiva integrării tehnice însă, sunt sisteme de extragere structural diferite. Nu există un standard comun care să permită interogarea uniformă, indiferent de protocol.
Fragmentarea introduce și riscuri de latență și de consistență a datelor. Cum starea economică nu e expusă ca un singur obiect atomic, agenții trebuie să facă multiple apeluri RPC către contracte diferite pentru a reconstrui un snapshot coerent. Fiecare apel suplimentar crește latența, expunerea la limitele de rată și riscul de inconsistență între blocuri. În perioadele de volatilitate ridicată, rata de utilizare poate fi deja diferită în momentul în care rata de supply e calculată, iar parametrii de configurare pot să nu reflecte același bloc ca totalurile de lichiditate.
Un alt aspect structural ține de modelul de acces la date. Pe blockchain, accesul la starea economică e fundamental bazat pe interogare (pull-based). Sistemele externe cer nodurilor starea de care au nevoie, în loc să primească actualizări structurate în mod continuu. Există și mecanisme de tip push, prin abonamente WebSocket care pot transmite blocuri noi și jurnale de evenimente în timp real, dar acestea nu acoperă starea de stocare unde rezidă cea mai mare parte din informația cu semnificație economică.
Un agent nu se poate abona la rata de utilizare a unei piețe de lending, la rezervele unui pool sau la factorul de sănătate al unei poziții. Aceste valori se află în stocarea internă a contractelor, iar majoritatea protocoalelor nu oferă niciun mecanism nativ pentru a transmite modificările de stocare către consumatorii din aval. Practic, agentul trebuie să întrebe din nou și din nou, în loc să fie notificat atunci când ceva se schimbă.
Fricțiunea de execuție
Dintre toate cele patru categorii, execuția e zona cu cel mai mare risc direct, pentru că pe un blockchain fiecare greșeală se măsoară în bani pierduți. O eroare nu e o excepție software care generează un mesaj în jurnal, ci o pierdere efectivă de capital.
În fluxul actual, interfața grafică compune secvența de acțiuni necesare, de exemplu swap, aprobare, depunere sau împrumut, iar portofelul digital prezintă un punct de control final unde utilizatorul verifică și aprobă. Judecata de politică se aplică informal la acel ultim pas. Omul decide, adesea cu informații incomplete, dacă tranzacția arată sigură și dacă rezultatul propus e acceptabil. Dacă ceva nu merge, utilizatorul reîncearcă, ajustează toleranța la slippage, schimbă ruta sau renunță la acțiune.
Sistemele autonome elimină omul din această buclă. Asta înseamnă că sistemul trebuie să preia trei funcții pe care omul le îndeplinea implicit.
Prima ține de compilarea intenției. Un obiectiv formulat uman, precum „mută stablecoin-urile mele în cel mai bun randament ajustat la risc”, trebuie transformat într-un plan concret de acțiune care precizează protocolul, piața, ruta de token, dimensiunea alocării, aprobările necesare și ordinea pașilor. Pentru un om, asta se întâmplă natural prin interfață. Pentru un agent, fiecare element trebuie formalizat.
A doua funcție ține de aplicarea politicii. Click-ul de „trimite tranzacția” nu e doar o semnătură criptografică. E o verificare implicită că tranzacția respectă un set de constrângeri: toleranța la slippage, limitele de leverage, factorul minim de sănătate al poziției, lista contractelor permise. Agenții au nevoie de aceste constrângeri exprimate ca reguli formale, verificabile automat înainte de difuzarea tranzacției.
A treia funcție e verificarea rezultatului. Includerea tranzacției într-un bloc nu înseamnă că sarcina s-a încheiat cu succes. O tranzacție poate fi procesată corect din punct de vedere tehnic și totuși să rateze obiectivul economic. Slippage-ul poate depăși toleranța stabilită, dimensiunea poziției dorite poate fi limitată de praguri impuse de protocol, sau o rată se poate modifica între momentul simulării și cel al includerii efective în bloc. Oamenii verifică asta uitându-se la interfață după finalizare. Agenții trebuie să evalueze post-condițiile în mod programatic, fără intervenție umană.
O mare parte din activitatea DeFi este inerent compusă din pași multipli. O alocare de randament poate necesita aprobarea accesului la fonduri, conversia unui token, depunerea într-un vault, contractarea unui împrumut și delegarea către un contract de staking, toate în ordine strictă. Unii pași pot fi tranzacții separate, alții pot fi grupați printr-un apel multicall sau un router specializat. Oamenii tolerează finalizarea parțială, se întorc la interfață și reiau de unde au rămas. Agenții au nevoie de orchestrare deterministă: dacă oricare dintre pași eșuează, agentul trebuie să decidă dacă reîncearcă, dacă alege o rută alternativă, dacă desfășoară pozițiile deschise sau dacă suspendă operațiunea.
Apar astfel moduri de eșec noi, care rămân în mare parte invizibile în fluxurile controlate de oameni. Starea rețelei se poate schimba între momentul în care agentul ia decizia și momentul în care tranzacția e inclusă în bloc. Unele acțiuni pot produce rezultate parțiale, fără ca agentul să fie notificat automat.
Aprobările de acces la fonduri, pe care utilizatorii le semnează reflex prin interfețe, devin pentru un agent probleme de politică de securitate care necesită evaluare explicită. Selecția rutei de execuție și costurile ascunse, pe care oamenii le delegă implicit routerelor și setărilor prestabilite ale interfeței, trebuie modelate de agent ca parte integrantă a funcției obiectiv.
De ce contează în acest moment?
Convergența dintre inteligența artificială și infrastructura blockchain nu mai e un scenariu ipotetic. În ultimul an au apărut zeci de proiecte care pun agenți AI direct pe lanț, de la manageri autonomi de portofoliu la strategii de yield farming operate integral de sisteme software, fără intervenție umană constantă. Volumul de capital gestionat de aceste sisteme crește, iar consecințele erorilor devin proporțional mai grave.
Raportul Galaxy Digital aduce o contribuție importantă tocmai pentru că nu propune soluții spectaculoase. Identifică probleme structurale reale. Unele dintre ele sunt inerente sistemelor fără permisiuni și vor persista indiferent de progresul tehnologic. Altele reflectă stadiul actual al instrumentelor, standardelor și al modelelor de stimulente, iar acestea se vor atenua pe măsură ce utilizarea agenților crește și protocoalele vor concura pentru a fi mai accesibile sistemelor autonome.
Direcțiile de dezvoltare sunt deja conturate. Se lucrează la middleware care normalizează starea economică a protocoalelor într-un format citibil de mașini. Se explorează servicii de indexare și extensii RPC care expun primitive semantice, precum pozițiile agregate, factorii de sănătate și seturile de oportunități, în loc de stocare brută.
Se discută despre registre care oferă mapări canonice ale contractelor și mecanisme de verificare a autenticității tokenilor. Se dezvoltă cadre de execuție care codifică constrângeri de politică, gestionează fluxuri compuse din pași multipli și verifică programatic dacă obiectivul a fost atins.
O transformare care abia a început
Tendința e limpede. Sistemele autonome vor deveni participanți permanenți în ecosistemele blockchain, nu utilizatori ocazionali care apar și dispar. Dar tranziția de la un om care semnează tranzacții la un agent care gestionează capital autonom nu echivalează cu o simplă automatizare a unor pași existenți. E o reconfigurare a modului în care interpretarea, încrederea și politica se aplică în medii descentralizate.
Dificultatea reală nu stă în a face un agent să semneze o tranzacție. Asta e partea simplă. Dificultatea e să-i oferi modalități fiabile de a îndeplini funcțiile semantice, de verificare și de politică pe care le asigură acum un amestec de software specializat și judecată umană, funcții care se interpun între starea brută a blockchain-ului și decizia de a acționa.
Arhitecturile centrate pe intenție, unde agentul transmite intenții semnate în loc de instrucțiuni brute de apel, iar solveri specializați se ocupă de satisfacerea constrângerilor, pot oferi o punte parțială. Modelele de transmitere proactivă a datelor, unde agentul primește actualizări structurate de stare în loc să interogheze constant sute de contracte, pot reduce risipa de resurse și latența. Registrele de identitate canonică pot simplifica verificarea legitimității.
Toate aceste soluții sunt însă în stadii timpurii de dezvoltare. Între timp, fiecare agent care operează pe un blockchain se confruntă cu o realitate incomodă: lanțul garantează că tranzacțiile se execută corect, dar nu garantează că starea economică e ușor de interpretat, că un contract e ceea ce pretinde a fi, că rutele de execuție reflectă intenția reală sau că oportunitățile relevante pot fi descoperite fără asistență umană.
Aceasta e fricțiunea. Nu e spectaculoasă, nu generează titluri senzaționale, dar e structurală. Modul în care industria o va rezolva va determina cât de departe pot ajunge agenții AI în ecosistemul crypto și cât de repede se va produce tranziția de la experimentare la utilizare la scară largă.
