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