XRP Ledger перевів PermissionDelegationV1_1 у 14-денний період активації після того, як 29 із 35 довірених валідаторів мережі підтримали оновлення дозволів облікових записів.
Згідно з панеллю відстеження поправок XRP Ledger у реальному часі, зворотний відлік почався 21 вересня і може ввести PermissionDelegationV1_1 у дію 5 жовтня о 11:18 UTC, якщо підтримка валідаторів упродовж усього періоду залишатиметься вище необхідного порога.
Щонайменше 28 із 35 довірених валідаторів мають і надалі підтримувати цю поправку. Якщо рівень підтримки опуститься нижче цього значення до завершення відліку, таймер активації буде скинуто.
PermissionDelegationV1_1 змінює спосіб, у який обліковий запис XRP Ledger може надавати іншому акаунту повноваження для виконання конкретних завдань.
За поточної структури акаунтів компанії, яким потрібні різні системи або співробітники для виконання операцій, можуть стикатися з проблемою надання операційному акаунту ширших повноважень, ніж йому фактично потрібно. Permission Delegation покликана розділити ці обов’язки.
Наприклад, акаунт може уповноважити інший акаунт здійснювати платежі, не надаючи йому права змінювати ключі основного акаунта. Емітент стейблкоїна може зберігати свої основні ключі офлайн, водночас надавши підключеній до інтернету комплаєнс-системі дозвіл схвалювати клієнтів для володіння його токеном.
Кожен делегований акаунт може отримати до 10 дозволів, тоді як акаунт, що надає повноваження, зберігає можливість їх змінювати або відкликати.
Така модель нагадує розподіл обов’язків, який зазвичай використовують фінансові установи, де платіжні, комплаєнс- і адміністративні функції не обов’язково мають однаковий рівень доступу.
PermissionDelegationV1_1 є частиною ширшої групи поправок, запроваджених через xrpld 3.3.0. До релізу, окрім Permission Delegation, увійшли BatchV1_1, ConfidentialTransfer, DynamicMPT і Sponsor, причому кілька з цих функцій орієнтовані на інституційні транзакції та випуск токенів.
Sponsor дасть змогу іншій стороні покривати комісії за транзакції та резервні вимоги для користувачів без контролю над їхніми акаунтами. DynamicMPT надає емітентам більше гнучкості щодо окремих властивостей Multi Purpose Token, тоді як ConfidentialTransfer призначений для приховування балансів MPT і сум платежів від публічного перегляду зі збереженням механізмів доступу для уповноважених сторін.
Crypto.news раніше повідомляв, що ConfidentialTransfer націлений на інституційні сценарії використання, де компаніям може бути потрібна конфіденційність транзакцій із одночасним наданням інформації аудиторам та іншим уповноваженим сторонам.
PermissionDelegationV1_1 — це друга спроба впровадити делеговані дозволи акаунтів у XRP Ledger.
Початкову поправку зупинили до її виходу в основну мережу після того, як 15 вересня 2025 року тестувальник зі спільноти повідомив про вразливість.
У проблемній реалізації програмне забезпечення перевіряло, чи має акаунт дозвіл на виконання транзакції, до належної перевірки її підпису. Деякі відхилені транзакції все одно могли обкладатися комісією.
Отже, зловмисник міг подати неавторизовані транзакції з навмисно завищеними комісіями та змусити інший акаунт сплатити їх, хоча транзакції не були належним чином підписані. Повторення цього процесу могло б виснажити доступний баланс XRP жертви.
Після виявлення вразливості валідаторам порадили не підтримувати поправку, що не дозволило ураженій версії активуватися в mainnet.
Заміну включили до xrpld 3.3.0 зі змінами в обробці неавторизованих транзакцій. Тепер перевірка підпису відбувається до того типу збою, який міг би списати комісію з цільового акаунта.
Permission Delegation — не єдина функція з цього релізу, що повернулася після доопрацювань із безпеки. BatchV1_1 замінила попередню реалізацію Batch після того, як розробники виявили окрему критичну вразливість підписування. Переглянуте оновлення Batch пройшло голосування валідаторів після виправлень і додаткової перевірки.
PermissionDelegationV1_1 не змінює напряму пропозицію XRP, графік емісії або економіку токена, тому сама по собі її активація не створює механічних причин для суттєвого нового попиту на XRP.
Поправка стосується дозволів акаунтів, а не самого токена XRP. Установи, що використовують делеговані акаунти, як і раніше, застосовуватимуть XRP для стандартних комісій і резервних вимог реєстру, але ця функція не вимагає від них купувати або утримувати великі обсяги XRP лише для використання делегованих дозволів.
Нещодавні події в мережі показують, чому відмінність між впровадженням XRPL і попитом на XRP має значення.
Попередній аналіз XRP-експозиції Ripple Prime показав, що навіть значна інституційна активність усередині екосистеми Ripple не автоматично трансформується у відповідний попит на XRP. Стейблкоїни та інші випущені активи можуть забезпечувати значну частину базового перенесення вартості, тоді як XRP зберігає ролі, зокрема, як засіб сплати комісій, резервний актив і інструмент для окремих маршрутів переказу.
Схожа структура застосовується і до Permission Delegation. Емітенти стейблкоїнів, постачальники токенізованих активів та інші бізнеси можуть використовувати цю функцію без того, щоб XRP був активом, який переказується.
Можливий зв’язок із ціною натомість залежить від того, чи допоможе оновлення з часом привести до зростання активності в XRP Ledger.
Інституційні емітенти, які хочуть тримати ключі з високим рівнем повноважень офлайн, можуть використовувати делеговані акаунти для регулярних платежів або комплаєнс-завдань. Якщо ці можливості сприятимуть тому, що більше компаній випускатимуть активи та оброблятимуть транзакції в XRPL, така активність збільшить використання мережі, де XRP залишається нативним активом для сплати комісій і забезпечення резервів.
Наявні на сьогодні дані свідчать, що зростання мережі та ціна XRP не завжди рухаються синхронно. RLUSD і токенізовані активи розширили свою присутність у XRPL, тоді як XRP переживав періоди цінової слабкості, що показує: зростання активності в реєстрі не обов’язково одразу створює тиск на купівлю токена.
Інституційний тест у червні за участю JPMorgan, Mastercard, Ondo Finance і Ripple дав ще один приклад. Викуп токенізованих казначейських активів відбувався з використанням XRP Ledger, але XRP не був активом, який викуповувався. Його пряма роль залишалася прив’язаною до базової мережевої інфраструктури.
Отже, PermissionDelegationV1_1 може стати ще одним елементом інфраструктури для інституційних користувачів, не перетворившись при цьому на великий самостійний каталізатор ціни XRP.
Ринкова реакція навколо активації все ж можлива, оскільки трейдери можуть реагувати на оновлення мережі та очікування щодо впровадження. Однак будь-який стійкий ціновий ефект залежатиме від подальшого використання цієї функції та інших ринкових чинників, а не від самого факту ввімкнення поправки.
Permission Delegation рухається до активації, тоді як кілька інших функцій XRP Ledger залишаються на різних етапах процесу внесення поправок.
BatchV1_1 призначений для об’єднання кількох операцій в одну скоординовану транзакцію, дозволяючи всім включеним діям або успішно виконатися разом, або разом завершитися невдачею. Така структура може підтримувати розрахункові процеси, де актив і платіж за нього мають переходити одночасно.
ConfidentialTransfer надасть емітентам Multi Purpose Token можливість приховувати баланси та суми переказів, залишаючи при цьому самі акаунти видимими. Уповноважені сторони все одно зможуть отримувати інформацію, необхідну для комплаєнсу, відповідно до запропонованої моделі.
Розробники XRPL продовжили роботу й після релізу 3.3.0. Версія 3.4.0, випущена 16 вересня, запровадила зміни до запропонованих функцій кредитування разом із ще одним пакетом виправлень протоколу.
Фреймворк кредитування, як і раніше, підпадає під процес внесення поправок у мережі, і для активації запропонованих функцій у mainnet потрібне схвалення валідаторів.
XRP
