
XRP Ledger a mutat PermissionDelegationV1_1 în perioada sa de activare de 14 zile după ce 29 dintre cei 35 de validatori de încredere ai rețelei au susținut upgrade-ul privind permisiunile conturilor.
Potrivit dashboard-ului live pentru amendamentele XRP Ledger, numărătoarea inversă a început pe 21 septembrie și ar putea pune PermissionDelegationV1_1 în aplicare pe 5 octombrie la 11:18 UTC dacă sprijinul validatorilor rămâne peste pragul necesar pe toată durata perioadei.
Cel puțin 28 dintre cei 35 de validatori de încredere trebuie să continue să susțină amendamentul. Dacă sprijinul scade sub acest nivel înainte de încheierea numărătorii inverse, cronometrul de activare se va reseta.
PermissionDelegationV1_1 schimbă modul în care un cont din XRP Ledger poate acorda altui cont autoritatea de a efectua sarcini specifice.
În structura actuală a conturilor, companiile care au nevoie de sisteme sau angajați diferiți pentru a desfășura operațiuni se pot confrunta cu problema de a acorda unui cont operațional mai multă autoritate decât are de fapt nevoie. Permission Delegation este conceput pentru a separa aceste responsabilități.
De exemplu, un cont ar putea autoriza un alt cont să efectueze plăți fără a-i acorda permisiunea de a schimba cheile contului principal. Un emitent de stablecoin și-ar putea păstra cheile principale offline, oferind în același timp unui sistem de conformitate conectat la internet permisiunea de a aproba clienții să dețină tokenul său.
Fiecare cont delegat poate primi până la 10 permisiuni, în timp ce contul care acordă autoritatea își păstrează capacitatea de a le modifica sau revoca.
Aranjamentul seamănă cu separarea responsabilităților utilizată frecvent de instituțiile financiare, unde funcțiile de plată, conformitate și administrare nu împart neapărat același nivel de acces.
PermissionDelegationV1_1 face parte dintr-un grup mai amplu de amendamente introduse prin xrpld 3.3.0. Versiunea a inclus BatchV1_1, ConfidentialTransfer, DynamicMPT și Sponsor alături de Permission Delegation, mai multe dintre aceste funcționalități fiind orientate către tranzacții instituționale și emiterea de tokenuri.
Sponsor ar permite unei alte entități să acopere comisioanele de tranzacție și cerințele de rezervă pentru utilizatori fără a le controla conturile. DynamicMPT oferă emitenților mai multă flexibilitate asupra anumitor proprietăți ale Multi Purpose Token, în timp ce ConfidentialTransfer este conceput pentru a ascunde soldurile MPT și sumele plăților de privirea publicului, păstrând în același timp mecanisme de acces pentru părțile autorizate.
Crypto.news a relatat anterior că ConfidentialTransfer vizează cazuri de utilizare instituționale în care companiile pot avea nevoie de confidențialitate pentru tranzacții, continuând totodată să furnizeze informații auditorilor și altor părți autorizate.
PermissionDelegationV1_1 reprezintă a doua încercare de a aduce permisiuni delegate pentru conturi în XRP Ledger.
Amendamentul original a fost oprit înainte de a ajunge pe rețeaua principală după ce un tester din comunitate a raportat o vulnerabilitate pe 15 septembrie 2025.
În implementarea afectată, software-ul verifica dacă un cont avea permisiunea de a efectua o tranzacție înainte de a-i verifica în mod corect semnătura. Anumite tranzacții respinse puteau totuși genera un comision.
Prin urmare, un atacator ar fi putut trimite tranzacții neautorizate cu taxe intenționat ridicate și ar fi putut determina un alt cont să le plătească, deși tranzacțiile nu erau semnate corespunzător. Repetarea procesului ar fi putut epuiza soldul XRP disponibil al victimei.
Validatorilor li s-a recomandat să nu susțină amendamentul după descoperirea vulnerabilității, împiedicând astfel activarea versiunii afectate pe mainnet.
Versiunea de înlocuire a fost inclusă în xrpld 3.3.0, cu modificări privind modul în care sunt tratate tranzacțiile neautorizate. Verificarea semnăturii are loc acum înainte de tipul de eroare care ar putea taxa contul vizat.
Permission Delegation nu este singura funcționalitate din această versiune care revine după lucrări de securitate. BatchV1_1 a înlocuit o implementare Batch anterioară după ce dezvoltatorii au găsit o vulnerabilitate critică separată legată de semnare. Upgrade-ul Batch revizuit a trecut prin votul validatorilor după remedieri și o analiză suplimentară.
PermissionDelegationV1_1 nu modifică direct oferta de XRP, calendarul de emitere sau economia tokenului, astfel că nu există un motiv mecanic pentru care activarea sa, de una singură, să creeze o nouă cerere substanțială pentru XRP.
Amendamentul se referă la permisiunile conturilor, nu la tokenul XRP în sine. Instituțiile care folosesc conturi delegate ar continua să utilizeze XRP pentru comisioanele obișnuite ale registrului și cerințele de rezervă, însă funcționalitatea nu le obligă să cumpere sau să dețină cantități mari de XRP doar pentru a folosi permisiunile delegate.
Evoluțiile recente din rețea arată de ce distincția dintre adopția XRPL și cererea pentru XRP este importantă.
O analiză anterioară a expunerii Ripple Prime la XRP a constatat că nici măcar o activitate instituțională semnificativă în ecosistemul Ripple nu se traduce automat într-o cerere echivalentă pentru XRP. Stablecoin-urile și alte active emise pot gestiona o mare parte din transferul subiacent de valoare, în timp ce XRP își păstrează roluri precum comisioane de tranzacție, rezerve și anumite funcții de rutare.
O structură similară se aplică și în cazul Permission Delegation. Emitenții de stablecoin-uri, furnizorii de active tokenizate și alte companii ar putea utiliza această funcționalitate fără ca XRP să fie activul transferat.
Posibila legătură cu prețul depinde, în schimb, de măsura în care upgrade-ul ajută la aducerea unei activități mai intense în XRP Ledger în timp.
Emitenții instituționali care doresc să păstreze offline cheile cu autoritate ridicată ar putea folosi conturi delegate pentru plăți recurente sau sarcini de conformitate. Dacă aceste capabilități contribuie la creșterea numărului de companii care emit active și procesează tranzacții pe XRPL, activitatea rezultată ar genera o utilizare mai mare a rețelei, unde XRP rămâne activul nativ folosit pentru comisioane și rezerve.
Dovezile de până acum sugerează că expansiunea rețelei și prețul XRP nu evoluează întotdeauna împreună. RLUSD și activele tokenizate s-au extins pe XRPL, în timp ce XRP a traversat perioade de slăbiciune a prețului, ceea ce arată că o creștere a activității în registru nu produce neapărat o presiune imediată la cumpărare pentru token.
Un test instituțional din iunie, care a implicat JPMorgan, Mastercard, Ondo Finance și Ripple, a oferit un alt exemplu. Răscumpărarea tokenizată a titlurilor de Trezorerie a folosit XRP Ledger, însă XRP nu a fost activul răscumpărat. Rolul său direct a rămas legat de infrastructura subiacentă a rețelei.
Prin urmare, PermissionDelegationV1_1 ar putea furniza încă o componentă de infrastructură pentru utilizatorii instituționali, fără a deveni un catalizator major de sine stătător pentru prețul XRP.
O reacție a pieței în jurul activării rămâne posibilă, deoarece traderii pot răspunde la upgrade-urile de rețea și la așteptările privind adopția. Totuși, orice efect susținut asupra prețului ar depinde de utilizarea ulterioară a funcționalității și de alți factori de piață, nu doar de simpla activare a amendamentului.
Permission Delegation avansează spre activare, în timp ce alte câteva funcționalități ale XRP Ledger se află încă în etape diferite ale procesului de amendare.
BatchV1_1 este conceput pentru a grupa mai multe operațiuni într-o tranzacție coordonată, permițând ca toate acțiunile incluse să reușească sau să eșueze împreună. O astfel de structură poate susține procese de decontare în care un activ și plata aferentă trebuie să își schimbe proprietarul simultan.
ConfidentialTransfer le-ar oferi emitenților de Multi Purpose Token opțiunea de a ascunde soldurile și sumele transferate, lăsând în același timp conturile vizibile. Părțile autorizate ar putea în continuare să primească informațiile necesare pentru conformitate, conform designului propus.
Dezvoltatorii XRPL și-au continuat activitatea și dincolo de versiunea 3.3.0. Versiunea 3.4.0, lansată pe 16 septembrie, a introdus revizuiri ale funcțiilor de lending propuse, alături de un alt pachet de remedieri ale protocolului.
Cadrul de lending rămâne supus procesului de amendare al rețelei, fiind necesară aprobarea validatorilor înainte ca funcțiile propuse să poată deveni active pe mainnet.








