Оновлення щодо апгрейду XRP: активацію Batch на XRPL перенесено на 9 жовтня — що зміниться

Оновлення XRP, яке мало активуватися 29.09, не відбулося. Поправка Batch у XRP Ledger, випущена у виправленій версії BatchV1_1, ненадовго втратила підтримку валідаторів приблизно 25.09. Через це двотижневий відлік обнулився, а найранішу можливу дату активації перенесли на 09.10.2026, приблизно на 14:46 UTC. У цій статті розповідаємо, що саме Batch додає до реєстру, чому короткочасного зниження кількості голосів достатньо, щоб перезапустити відлік, що оператори вузлів і розробники застосунків мають зробити до 09.10, а також як затримка вписується в ситуацію на ринку XRP, де монета торгується поблизу 1,50 $ і все ще на 59% нижче свого максимуму від 07.2025.

Чи активувалося оновлення XRP 29.09?

Ні. Запуск BatchV1_1 був запланований на 29.09 о 14:06 UTC за умови, що протягом двох тижнів поспіль підтримка з боку списку довірених валідаторів перевищуватиме 80%. 25.09 рівень підтримки ненадовго опустився нижче цього порога. Процес активації поправок XRPL не допускає таких спадів: накопичений відлік скидається, а після відновлення підтримки починається нове двотижневе вікно. Того ж дня підтримку знову забезпечували 30 із 35 довірених валідаторів, тому новою найранішою датою активації стало 09.10, а не пізніший термін.

Разом із нею змістилися ще дві пов’язані події. PermissionDelegationV1_1, яка дає обліковому запису змогу делегувати певні дозволи, не передаючи ключі для підпису, також втратила, а потім відновила підтримку 23.09–24.09; тепер її найраніша дата активації — 08.10, приблизно о 21:25 UTC. А 25.09 команда XRP Ledger Operations випустила xrpld 3.4.1 із невеликою додатковою поправкою під назвою fixBatchV1_2. У примітках до випуску зазначено, що виправлення усуває незначну проблему Batch, яка не створює ризику для коштів користувачів. Обидві поправки мають статус default-yes, і очікується, що їх активують у тому самому жовтневому вікні.

Практичний висновок: 09.10 — це найраніша можлива дата, а не гарантований термін. Будь-яке нове зниження підтримки до цього моменту знову перезапустить відлік.

Що саме робить XRPL Batch (BatchV1_1)

Batch, описана в XLS-56, дає користувачеві змогу об’єднати від двох до восьми транзакцій в один підписаний пакет, який реєстр обробляє як єдине ціле. Зараз для свопу, що потребує офера, платежу та зміни довірчої лінії, потрібно надіслати три окремі транзакції, кожна з яких може пройти або не пройти незалежно від інших. Batch усуває цю проблему.

Поправка передбачає чотири режими виконання, і саме вибір режиму визначає гарантії розрахунку:

• Усе або нічого (All or Nothing): усі внутрішні транзакції виконуються успішно, або весь пакет відхиляється і нічого не застосовується. Це режим атомарного розрахунку, про який ідеться в більшості публікацій. Він важливий для сценаріїв «поставка проти платежу», наприклад коли оплата токенізованого активу та його отримання відбуваються одним кроком.
• Лише одна (Only One): реєстр застосовує першу успішну внутрішню транзакцію, а решту пропускає. Такий режим зручний для маршрутизації із резервним варіантом.
• До першої помилки (Until Failure): внутрішні транзакції застосовуються по черзі, доки одна з них не завершиться помилкою; попередні залишаються застосованими.
• Незалежний (Independent): кожну внутрішню транзакцію намагаються виконати незалежно від результатів інших.

Batch також підтримує пакети з кількох облікових записів, коли кілька облікових записів спільно підписують один пакет. Саме ця функція стала причиною відкликання першої версії, і саме тут переписана реалізація має найбільше значення.

Чому Batch відкликали й переписали

За початкову поправку Batch проголосували проти 02.2026 після того, як дослідники безпеки виявили вразливість у механізмі авторизації підписантів під час голосування. У вихідній логіці циклу, якщо код знаходив дійсного підписанта, пов’язаного з новоствореним обліковим записом, він повертав успішний результат, не перевіривши решту підписантів. Зловмисник міг розмістити підроблений запис першим і авторизувати транзакцію жертви без її ключів. Оскільки поправка так і не була активована, кошти не опинилися під загрозою.

BatchV1_1, випущена в xrpld 3.3.0 06.08.2026, змінює шлях авторизації. Тепер пакет із кількома обліковими записами має містити точний і повний набір BatchSigners — без пропущених, зайвих або повторюваних записів і без порушення їхнього порядку. Кожен підпис прив’язаний до зовнішнього облікового запису, його послідовності або квитка, режиму пакета, хешу кожної внутрішньої транзакції та облікових записів-учасників, що унеможливлює повторне використання підпису в інших пакетах. Переписана версія також запровадила обмеження на кількість транзакцій і захист від повторного відтворення транзакцій у реєстрі.

Про цю історію варто пам’ятати, читаючи заголовки про «оновлення XRP». Те, що функція з’явиться в основній мережі з другої спроби після того, як зовнішній аудит виявив реальну помилку, свідчить про ретельність перевірки реєстру краще, ніж активація з першої спроби. Це також пояснює обережність валідаторів щодо термінів: якщо валідатор на кілька годин припинить голосувати, щоб оновити програмне забезпечення або повторно оцінити випуск, цього може бути достатньо, щоб самостійно перезапустити двотижневий відлік, коли перевага становить лише п’ять валідаторів із 35.

Що мають зробити оператори вузлів і розробники до 09.10

Для інфраструктури активація поправки в XRP Ledger не є необов’язковою. Будь-який сервер xrpld, на якому працює версія без підтримки BatchV1_1, у момент активації буде заблокований через поправку й перестане слідувати за мережею. Мінімальна необхідна версія — 3.3.0; операційна команда наполягає на переході на 3.4.1, оскільки вона також усуває проблеми, які в примітках до випуску названо чутливими з погляду безпеки. Вихідний код обіцяють опублікувати пізніше.

На боці клієнтських застосунків готовність нижча. У матеріалі CryptoSlate від 23.09 описано проблемні місця:

• xrpl.js 5.0.0 створює підписи Batch на основі старого формату даних, тому їх буде відхилено з помилкою temBAD_SIGNATURE; у версії 5.1.0 використовується оновлений формат підпису.
• Гаманці, які не показують чітко внутрішні транзакції пакета, змушують користувачів підписувати набори операцій, які вони не можуть перевірити.
• Експлорери, які неправильно відображають результати пакетів, показуватимуть транзакції по-різному в різних інструментах.
• Зовнішня транзакція Batch може завершитися успішно, навіть якщо внутрішні транзакції не пройшли в неатомарних режимах. Тому застосунки мають перевіряти результати внутрішніх транзакцій, а не лише код зовнішньої.

Керівник інженерного напряму RippleX Аyo Akinyele заявив, що деякі проєкти вже розробляють з урахуванням Batch і що активація дасть змогу наблизити цю роботу до запуску у виробничому середовищі. Це тверезе пояснення попиту: Batch — це інфраструктурна основа для емітентів, кастодіанів та керівників активами, які розробляють рішення на XRPL, а не функція для роздрібних користувачів, яку вони побачать у гаманці в перший же день.

Що затримка означає для ціни XRP

Станом на 30.09.2026 XRP торгується приблизно за 1,49 $ на CoinGecko, піднявшись на 1,6% за понад 24 годин, але знизившись на 5,1% за сім днів. Обсяг торгів за 24 години становить близько 4 млрд $, а ринкова капіталізація — приблизно 94,3 млрд $, що відповідає п’ятому місцю за цим показником. На WEEX спотова пара XRP/USDT того ж дня торгувалася за 1,4996 $. Токен залишається приблизно на 59% нижче історичного максимуму 3,65 $, зафіксованого 07.2025.

Важливіше те, що ринок не відреагував на дату активації Batch ні в один бік. У день, коли CoinDesk повідомив про перенесення на 09.10, XRP змінився менш ніж на половину відсотка. Це відповідає історичній поведінці поправок XRPL: реєстр активував десятки поправок, але жодна з них сама по собі не була надійним каталізатором руху ціни. Batch — це інституційне інфраструктурне оновлення, цінність якого проявиться в тому, що на його основі створять протягом наступних кварталів, а не в моменті закриття реєстру, який уможливлює його роботу.

Досвідчені трейдери XRP натомість зазвичай стежать за тим, чи збігається оновлення з подіями, які змінюють грошові потоки: надходженням коштів в ETF, появою нового емітента токенізованих активів на XRPL або загальноринковим рухом у бік ризику. Тижневе падіння на 5% до затримки було рухом усього ринку, а не специфічною реакцією на XRP. Якщо Batch спричинить переоцінку XRP, то це станеться завдяки запуску помітного продукту на її основі, а такий сценарій найраніше може реалізуватися з жовтня до грудня.

Як торгувати XRP на WEEX у період активації

Якщо ви плануєте тримати XRP або торгувати ним до 09.10, варто заздалегідь підготувати позиції та сповіщення, а не реагувати на заголовки в останній момент.

1. Відкрийте спотову пару XRP/USDT на WEEX і перевірте глибину книги ордерів перед визначенням розміру позиції, адже в дні важливих новин спреди часто ненадовго розширюються.
2. Ще не знайомі з цим активом? У посібнику з купівлі XRP описано, як поповнити рахунок і розмістити перший ринковий або лімітний ордер.
3. Трейдери, яким потрібна спрямована або хеджована позиція без переміщення активів на спотовому ринку, можуть скористатися безстроковими ф’ючерсами XRP/USDT на WEEX із кредитним плечем до 300x. Відомі дати подій — не найкращий час для високого плеча: тижневий рух на 5% при плечі 20x означає ліквідацію, а не просто просідання.
4. Налаштуйте цінові сповіщення на рівнях 1,40 $ і 1,60 $, які обмежують нещодавній діапазон, а також створіть нагадування в календарі на 08.10–09.10 UTC, щоб перевірити в експлорері XRPL, чи підтримка валідаторів усе ще перевищує 80%.
5. Переглядайте сторінку ціни XRP на WEEX, щоб швидко перевірити денну ціну, обсяг торгів і ринкову капіталізацію, не відкриваючи торговий термінал.

Погляд на ринок: Batch — каталізатор для розробників, а не трейдерів

Batch важлива, оскільки робить XRPL придатною для сценаріїв «поставка проти платежу» та багатоетапних операцій, які інституційні учасники очікують від розрахункової інфраструктури. Для XRP як активу причинно-наслідковий ланцюжок довгий: активація 09.10, потім оновлення застосунків до xrpl.js 5.1.0, далі запуск емітентами продуктів із пакетами «Усе або нічого» і, можливо, збільшення активності в реєстрі, для комісій і переказів між мережами в якій потрібен XRP. На кожному етапі можливі затримки. Перенесення з 29.09 на 09.10 нагадує, що навіть перший крок не є гарантованим.

Поширені запитання

1. Чи відбулося оновлення XRP 29.09.2026?

Ні. BatchV1_1 ненадовго втратила підтримку валідаторів 25.09, через що двотижневий відлік до активації скинувся. Тепер найраніша дата активації — 09.10.2026, приблизно о 14:46 UTC. Вона може знову зміститися, якщо підтримка впаде нижче 80%.

2. Що таке XRPL BatchV1_1?

BatchV1_1 — це виправлена версія поправки Batch (XLS-56). Вона дає змогу об’єднати від двох до восьми транзакцій в один підписаний пакет із чотирма режимами виконання, зокрема атомарним розрахунком «Усе або нічого». Проти початкової версії Batch проголосували 02.2026 через помилку в авторизації підписантів; переписану версію випустили в xrpld 3.3.0 у 08.2026.

3. Чи підвищить оновлення Batch ціну XRP?

Немає доказів, що це станеться саме по собі. У день повідомлення про затримку ціна XRP змінилася менш ніж на 0,5%, а попередні поправки XRPL не були надійними каталізаторами ціни. Будь-який вплив на ціну з’явиться пізніше — завдяки продуктам, створеним на основі Batch.

4. Що станеться з вузлами, які не оновляться до 09.10?

Їх заблокує поправка, і вони припинять синхронізацію з мережею. Операторам потрібна щонайменше xrpld 3.3.0; рекомендована версія — 3.4.1, оскільки вона також містить fixBatchV1_2 і виправлення безпеки.

5. Чи fixBatchV1_2 — це те саме, що BatchV1_1?

Ні. fixBatchV1_2 — це невелика додаткова поправка, представлена в xrpld 3.4.1 25.09.2026 для виправлення незначної проблеми Batch, яка не створює ризику для коштів. Очікується, що її активують у тому самому жовтневому вікні разом із BatchV1_1.

Попередження про ризики

XRP — волатильний актив, який може втратити значну частину вартості за кілька днів; позиція може призвести до часткової або повної втрати коштів. Дата активації поправки Batch залежить від голосів валідаторів і може знову змінитися, тому торгові стратегії, побудовані на фіксованій даті 09.10, несуть ризик, пов’язаний із термінами події. Ф’ючерси XRP із кредитним плечем збільшують як прибутки, так і збитки, а звичайного тижневого руху на 5% достатньо, щоб ліквідувати позицію з високим плечем. Сама Batch під час розгортання створює нові операційні ризики: застарілі вузли блокуються через поправку, старіші клієнтські бібліотеки генерують відхилені підписи, а в неатомарних режимах зовнішня транзакція може повідомити про успіх, хоча внутрішні транзакції не пройшли. XRP також залишається вразливим до регуляторних змін, що стосуються Ripple, і до концентрації пропозиції в ескроу під контролем Ripple. Цей матеріал не є інвестиційною порадою.