Конкурс спільноти з аудиту на суму 550 000 доларів виявив дві критичні вразливості у функціях XRP Ledger, які могли спустошити облікові записи користувачів без приватних ключів. Ці знахідки показують, як модель Ripple «аудит перед випуском» різко відрізняється від загальної практики криптоіндустрії «виправлення після експлойту».
Підсумок
- Двотижневий конкурс аудиту Sherlock, який розпочався 13 квітня 2026 року, виявив 96 дійсних вразливостей у п'яти запропонованих поправках до XRP Ledger, включаючи 2 критичні та 6 помилок високої серйозності, до того як будь-яка з них потрапила в основну мережу.
- Ripple виплатила 309 000 доларів у RLUSD з призового фонду в 550 000 доларів, що стало першою співпрацею між Sherlock та Ripple і одним із найбільших конкурсів аудиту 2026 року.
- Найсерйознішою знахідкою була помилка перевірки підпису в поправці Batch, яка дозволила б зловмисникам виконувати транзакції з будь-якого облікового запису без володіння його приватними ключами; вперше її виявили 19 лютого 2026 року дослідник Пранам'я Кешкамат та інструмент ШІ Apex від Cantina.
- Окрема критична помилка в Permission Delegation дозволяла зловмисникам тихо спустошувати баланси XRP через повторні комісії за недійсні делеговані транзакції, оскільки код перевіряв дозволи перед перевіркою підписів.
- Експлойти DeFi перевищили 840 мільйонів доларів у понад 50 інцидентах лише за перші п'ять місяців 2026 року, що на 70% більше порівняно з минулим роком, і 70% експлуатованих контрактів були перевірені, але не мали моніторингу після розгортання.
XRP Ledger версії 3.3.0 вийшов 6 серпня 2026 року, несучи п'ять запропонованих поправок та об'єднаний патч очищення. На папері це виглядало як звичайний реліз інфраструктури. Під капотом оновлення представляло завершення шестимісячного випробування безпеки, яке виявило дві помилки, що спустошують рахунки, повністю переписало дві функції з нуля та виплатило сотні тисяч доларів зовнішнім дослідникам, які знайшли проблеми, пропущені внутрішньою командою. Цей процес ставить гостре питання для всієї блокчейн-індустрії: якщо Ripple може виявляти критичні вади до розгортання, чому так багато криптовалют все ще ставляться до аудиту безпеки як до галочки після запуску?
Ця стаття розбирає, чим на технічному рівні були дві критичні вразливості, досліджує, як конвеєр аудит-голосування-активація порівнюється з моделями безпеки конкуруючих ланцюгів, та оцінює, чи зміцнюють ці знахідки аргументи на користь XRPL як інституційної інфраструктури, чи підривають їх.
Що насправді виявив конкурс Sherlock
Обсяг охоплював п'ять стовпів майбутньої функціональності XRPL: пакетні транзакції, делегування дозволів, інтеграція DEX для багатоцільових токенів (MPT), конфіденційні перекази для MPT та спонсоровані комісії та резерви. Sherlock, фірма з безпеки Web3, яка ранжує дослідників за продуктивністю та структурує заходи як змагальні конкурси, відкрила аудит 13 квітня 2026 року з призовим фондом 550 000 доларів у RLUSD. Сторінка конкурсу на платформі Sherlock вказувала захід як «XRP Ledger – April 2026 Contest – 550,000 RLUSD», що свідчить про те, що Ripple виплатила винагороди у власному стейблкоїні.
Протягом двох тижнів учасники подали звіти, які виявили 96 дійсних знахідок: 2 критичні, 6 високих, 29 середніх та 59 низьких за серйозністю проблем. Ripple розподілила 309 000 доларів у RLUSD серед учасників. Решта фонду покрила операційні витрати Sherlock та знахідки нижчого рівня, які не досягли порогу виплати.
Конкурс став першою офіційною співпрацею між Sherlock та Ripple, і він відбувся в момент, коли конвеєр функцій XRP Ledger розширювався швидше, ніж будь-коли в його історії. П'ять поправок, що випускаються одночасно, означали п'ять різних поверхонь атаки, кожна зі своєю логікою транзакцій, моделлю авторизації та криптографічними вимогами. Для контексту, модель конкурсу аудиту Sherlock раніше використовувалася такими протоколами, як Aave, Euler та Olympus DAO, але захід, що охоплює код рівня протоколу C++ для блокчейну першого рівня, був нетиповим для платформи, яка частіше асоціюється зі смарт-контрактами Solidity.
Розподіл серйозності сам по собі говорить багато про що. 29 знахідок середньої серйозності свідчать про категорію помилок, які не скомпрометують окремі облікові записи, але можуть створити несподівану поведінку за певних послідовностей транзакцій. 59 проблем низької серйозності, ймовірно, включають проблеми якості коду, прогалини в документації та крайові випадки, які можуть посилюватися за несприятливих умов. Однак дві критичні та шість помилок високої серйозності представляли експлуатовані вразливості, які потребували негайного виправлення.
Помилка у поправці Batch, яка могла спустошити рахунки
Найнебезпечніша вразливість з'явилася за два місяці до конкурсу Sherlock. 19 лютого 2026 року дослідник безпеки Пранам'я Кешкамат та автономний інструмент штучного інтелекту Cantina Apex незалежно виявили помилку перевірки підпису в оригінальній поправці Batch, коли вона ще перебувала на етапі голосування валідаторів.
Технічна несправність була точною. Пакетні транзакції дозволяють виконувати до восьми операцій атомарно в рамках однієї зовнішньої транзакції. Код перевірки підпису зовнішньої транзакції містив умову раннього виходу, яку можна було задовольнити без належної перевірки того, хто авторизує внутрішні транзакції. На практиці зловмисник міг створити пакетну транзакцію, що містить внутрішні платіжні операції, спрямовані на рахунок жертви, спустошивши його до резервного балансу, не володіючи приватними ключами цього рахунку. Той самий логічний розрив дозволив би несанкціоновані операції AccountSet, TrustSet або AccountDelete.
Звіт про розкриття вразливості, опублікований на xrpl.org, детально описував механіку: перевірка підпису в зовнішній транзакції могла пройти без підтвердження того, що суб'єкт, який подає пакет, фактично контролює рахунки, згадані у внутрішніх транзакціях. Це означало, що функція атомарності, призначена для покращення взаємодії з користувачем, могла бути використана для спустошення будь-якого рахунку в мережі однією транзакцією.
RippleX відреагував екстреним випуском. Версія rippled 3.1.1, опублікована 23 лютого 2026 року, через чотири дні після виявлення, позначила як оригінальну поправку Batch, так і її супутню fixBatchInnerSigs як непідтримувані, що запобігло голосуванню валідаторів за них або їх активації. Жодні кошти не були втрачені, оскільки поправка ще не подолала 80% поріг валідаторів, необхідний для активації. Заміна, BatchV1_1, вийшла у версії 3.3.0 з видаленою умовою раннього виходу, доданими додатковими захисними перевірками та звуженою областю перевірки підпису для незалежної перевірки кожної внутрішньої транзакції проти правильного підписувача.
Тиха експлуатація витоку комісій у Permission Delegation
Друга критична вразливість діяла через більш тонкий механізм. Розкриття інформації у вересні 2025 року задокументувало, як оригінальна реалізація Permission Delegation дозволяла зловмиснику тихо виснажувати баланс XRP рахунку жертви без доступу до його ключів.
Експлуатація спиралася на особливість обробки транзакцій XRP Ledger, яка існує з найперших днів мережі. На XRPL транзакція, яка завершується помилкою класу «tec», все одно стягує комісію, тоді як помилки, виявлені раніше в конвеєрі, до перевірки підпису, не стягують комісію. Ця відмінність існує, оскільки помилки класу tec вказують на транзакції, які були правильно сформовані та підписані, але не пройшли з бізнес-логічних причин, а комісія запобігає спаму. Оригінальний код Permission Delegation перевіряв, чи має делегований рахунок відповідний дозвіл, до перевірки підпису транзакції. Зловмисник міг багаторазово надсилати недійсні офлайн-підписані транзакції з підвищеними комісіями проти делегованого рахунку, і кожна невдала транзакція все одно списувала комісію з балансу жертви.
Економічний вплив швидко накопичувався. Оскільки зловмисник міг встановлювати довільно високі комісії на ці транзакції, тривала атака могла спустошити рахунок набагато швидше, ніж звичайні комісії за транзакції. Жертва бачила б зменшення свого балансу без відповідних вихідних платежів, що ускладнювало діагностику атаки без вивчення сирих метаданих транзакцій.
Виправлення перекласифікувало відповідну помилку з tec на ter та змінило порядок перевірок, щоб жодна комісія не могла бути списана до проходження перевірки підпису. Замінююча поправка, PermissionDelegationV1_1, має позначення «Ні» за замовчуванням у реєстрі версії 3.3.0, що означає, що валідатори повинні активно голосувати за її ввімкнення. Цей консервативний стандарт відображає чутливість оригінальної помилки: навіть після переписування Ripple вирішив вимагати явної згоди валідаторів для цієї функції.
Чому обидва переписані компоненти вийшли в одному релізі
Упаковка двох поправок із переписаним кодом безпеки разом із трьома абсолютно новими функціями в одній версії була свідомим рішенням. RippleX опублікував xrpld 3.3.0 6 серпня 2026 року, з кодом для всіх шести пропозицій (включаючи об'єднану поправку очищення під назвою fixCleanup3_3_0), але жодна з них не була активована. Згідно з процесом внесення поправок у XRP Ledger, кожна пропозиція повинна отримати понад 80% підтримки валідаторів протягом двох послідовних тижнів, перш ніж вона набуде чинності.
Цей поділ між доступністю коду та активацією функцій є структурною перевагою, якої бракує більшості платформ смарт-контрактів. На Ethereum розгорнутий контракт стає активним у момент його потрапляння в блокчейн. На XRPL код може бути опублікований, пройти подальший перегляд під час періоду голосування і все ще бути заблокованим, якщо валідатори втратять довіру. Переписані компоненти Batch та Permission Delegation вже пережили конкурс Sherlock, повторний аудит Halborn, який виявив нуль критичних або високоризикових проблем, та місяці внутрішнього тестування. Період голосування додає ще один рівень захисту, перш ніж будь-який код торкнеться реальних коштів.
Версія також вивела з обігу п'ять застарілих поправок, включаючи Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve та fixUniversalNumber, видаляючи мертві шляхи коду, які інакше могли б накопичуватися як прихована поверхня атаки з часом.
П'ять функціональних поправок у версії 3.3.0 є найширшим одиничним розширенням можливостей XRPL на сьогодні. Конфіденційні перекази (Confidential Transfers) приносять EC-ElGamal шифрування та докази з нульовим розголошенням для багатоцільових токенів, приховуючи окремі баланси та суми переказів від публічного огляду, зберігаючи при цьому доступ для авторизованих сторін з метою відповідності. Спонсоровані комісії (Sponsored Fees) дозволяють додаткам покривати мережеві витрати від імені користувачів, вирішуючи проблему тертя при онбордингу, яка утримувала споживчі додатки від децентралізованих мереж. DynamicMPT дозволяє емітентам змінювати властивості токенів після створення, підтримуючи мінливі регуляторні та бізнес-вимоги. Разом із переписаними Batch та Permission Delegation ці функції націлені на конкретну аудиторію: регульовані фінансові установи, які потребують конфіденційності, атомарних розрахунків та делегованих операцій без шкоди для аудитованості.
Аудит перед випуском проти виправлення після експлойту
Контраст між підходом Ripple та загальним рівнем безпеки в індустрії є разючим. Експлойти DeFi перевищили 840 мільйонів доларів у понад 50 інцидентах за перші п'ять місяців 2026 року, що на 70% більше порівняно з тим самим періодом 2025 року. Актори, пов'язані з Північною Кореєю, становили 76% глобальних втрат від хакерських атак у криптовалюті за перші чотири місяці року. І найбільш показова статистика: 70% експлуатованих контрактів були проаудовані, але не мали жодної форми моніторингу після розгортання. Лише 4% відстежуваних проєктів поєднували аудити, активні програми винагород за виявлення вразливостей та сторонній моніторинг.
Екосистема Ethereum, де зосереджена найбільша вартість смарт-контрактів, працює за принципово іншою моделлю безпеки. Контракти розгортаються в мейннеті через незмінну транзакцію. Якщо вразливість виявляється пізніше, варіанти обмежені: розгорнути новий контракт і мігрувати користувачів, впровадити шаблон проксі-оновлення, який створює власну поверхню атаки, або прийняти ризик. Злом моста Wormhole у 2022 році коштував 320 мільйонів доларів, оскільки застаріла функція верифікації залишилася у виробничому коді. Експлойт Ronin у серпні 2024 року коштував 12 мільйонів доларів, оскільки оновлення контракту не змогло правильно ініціалізувати ваги операторів. В обох випадках аудити були проведені; збої сталися після розгортання.
Злом KelpDAO 18 квітня 2026 року, який вивів приблизно 293 мільйони доларів, був найбільшим одиничним експлойтом DeFi за рік. Експлойт Drift Protocol на Solana 1 квітня, який коштував приблизно 286 мільйонів доларів, був найбільшим за всю історію цього ланцюга. Ці цифри не є поодинокими випадками. Вони представляють базовий рівень відмов індустрії, яка сукупно втратила 16,69 мільярда доларів через злами, експлойти мостів та інциденти безпеки, згідно з даними DeFiLlama.
Процес голосування за поправки XRPL інвертує цю послідовність. Код випускається в релізі, але функції залишаються неактивними, поки валідатори не схвалять їх. Під час вікна голосування дослідники, оператори вузлів та конкуруючі аудитори можуть вивчати живу кодову базу з повним контекстом. Якщо виникає проблема, валідатори просто утримуються від голосування. Жодних екстрених патчів, жодних міграцій, жодних проксі-контрактів. Баг у Batch у лютому 2026 року пішов саме цим шляхом: поправка була на стадії голосування, вразливість була виявлена, і екстрений реліз запобіг активації. Нульовий ризик для коштів, нульовий вплив на користувачів.
Це не означає, що модель XRPL бездоганна. Процес поправок працює для функцій на рівні протоколу, але не поширюється на додатки, побудовані поверх реєстру. Погано написаний trust line або інтеграція MPT все ще можуть призвести до втрати коштів. А поріг у 80% валідаторів створює власні ризики: якщо занадто мало валідаторів оновляться до нової версії, легітимні патчі безпеки можуть застопоритися. Але для змін у ядрі протоколу конвеєр аудит-голосування-активація представляє суттєво іншу позицію безпеки, ніж "розгорнути і сподіватися".
Що це означає для інституційної пропозиції XRPL
Ripple провів 2026 рік, агресивно будуючи інституційний інфраструктурний стек. Придбання Hidden Road за 1,25 мільярда доларів, мультиактивного прайм-брокера, перейменованого на Ripple Prime, дало компанії регульований вхід для традиційних фінансів. RLUSD досяг ринкової капіталізації у 1,72 мільярда доларів менш ніж за рік і здійснив понад 18 мільярдів доларів транзакційного обсягу лише за перший квартал. Goldman Sachs розкрив позицію у 153,8 мільйона доларів у чотирьох XRP ETF. Ripple отримав повну ліцензію Electronic Money Institution від Люксембургу у лютому, дозволи від Управління фінансової поведінки Великобританії у січні та ліцензію MiCA Crypto-Asset Service Provider 6 липня.
Інституційні функції DeFi, що з'являються у версії 3.3.0, є технічним відповідником цього поштовху до розвитку бізнесу. Конфіденційні перекази вирішують вимоги конфіденційності банків, які не можуть розкривати деталі транзакцій у публічному реєстрі. Спонсоровані комісії вирішують проблему онбордингу, яка утримувала роздрібні банківські додатки від децентралізованих мереж. Делегування дозволів, після того як його перепис пройде процес голосування, дозволяє впроваджувати моделі контрольованого доступу, які вимагають відділи комплаєнсу.
Але інституційне впровадження залежить від довіри, а довіра до блокчейн-інфраструктури в кінцевому підсумку зводиться до історії безпеки. Той факт, що Ripple виявив дві критичні помилки, переписав дві повні реалізації функцій, заплатив зовнішнім дослідникам 309 000 доларів за пошук проблем і все одно доставив усі п'ять функцій вчасно, є сильнішим інституційним аргументом, ніж будь-яка окрема функція. Це свідчить про культуру безпеки, де винагорода за знаходження помилок і де випуск продукту підпорядкований перевірці.
Понад 300 фінансових установ у 55 країнах зараз використовують RippleNet, з активними коридорами On-Demand Liquidity на понад 70 ринках. Для цих установ результати аудиту Sherlock не є абстрактними. Вони є доказом того, що код, який забезпечує їхні транскордонні платежі, був стрес-тестований вороже налаштованими дослідниками з фінансовими стимулами зламати його. Чотирифазний план Ripple щодо квантової стійкості, націлений на завершення до 2028 року, додатково сигналізує про те, що компанія проектує для інституційних часових горизонтів, які вимірюються десятиліттями, а не циклами розгортання.
Протилежний випадок: чому скептики не переконані
Найсильніший аргумент проти того, щоб надавати надто великого значення аудиту Sherlock, йде у двох напрямках.
По-перше, знаходження 96 помилок до релізу можна розглядати як доказ ретельного тестування або як доказ недбалої розробки. І вразливість Batch, і вразливість Permission Delegation були в оригінальних реалізаціях, тобто вони пройшли внутрішню перевірку, перш ніж зовнішні дослідники їх виявили. Баг у Batch у лютому 2026 року був виявлений не власною командою Ripple, а незалежним дослідником та інструментом штучного інтелекту. Якщо зовнішні аудитори є основним запобіжником, внутрішній процес розробки може мати прогалини в якості, які зрештою призведуть до вразливості, яку жоден зовнішній рецензент не встигне виявити вчасно.
По-друге, сила моделі поправок XRPL, здатність запобігати активації під час вікна голосування, також є обмеженням швидкості. Готовність Ethereum розгортати та ітерувати дозволила досягти темпів інновацій, яких XRPL не може наздогнати. П'ять поправок у версії 3.3.0 перебували в циклах розробки та перегляду протягом місяців. Оригінальна поправка Batch була запропонована у 2025 році. Для протоколів, які конкурують за увагу розробників на швидкозмінних ринках, шестимісячний конвеєр безпеки може бути занадто повільним, щоб залучити екосистему розробників, яка стимулює мережеві ефекти.
Також існує ризик концентрації в наборі валідаторів. Поріг активації у 80% означає, що відносно невелика кількість валідаторів, багато з яких керуються організаціями, тісно пов'язаними з Ripple, контролює, чи ввійдуть поправки в дію. Критики стверджують, що це не справді децентралізоване управління, а кураторський процес затвердження, замаскований під консенсус. Коли власний валідатор Ripple проголосував «за» поправки щодо кредитування останніми тижнями, це підкреслило, наскільки великий вплив компанія зберігає над своєю номінально децентралізованою мережею.
Нарешті, виплата у розмірі 309 000 доларів із пулу в 550 000 доларів порушує практичне питання щодо узгодження стимулів. Провідні дослідники безпеки вимагають ставки, які перевищують те, що конкурсні моделі зазвичай платять за годину роботи. Якщо найкваліфікованіші аудитори пропускають конкурси XRPL, оскільки очікувана виплата за знахідку нижча, ніж у приватних замовленнях, то змагальний огляд може бути широким, але недостатньо глибоким, щоб виявити найскладніші вектори атак.
Ці заперечення мають вагу. XRP торгувався близько 1,03 долара наприкінці липня 2026 року, приблизно на 71% нижче свого циклічного максимуму в 3,65 долара, встановленого 17 липня 2025 року, що свідчить про те, що ринок ще не врахував інституційну наратив. Чи перетвориться послужний список безпеки на впровадження, залежить від факторів, що виходять за межі якості коду: регуляторної ясності, конкурентної позиції щодо рішень другого рівня Ethereum, і того, чи турбують інституції більше про передрозгортальні аудити, ніж про розмір екосистеми.
На що звернути увагу
Пороги голосування валідаторів для п'яти поправок 3.3.0: якщо BatchV1_1 та PermissionDelegationV1_1 наберуть 80% підтримки протягом першого циклу голосування, це свідчить про впевненість валідаторів у переписаних версіях. Зупинка свідчила б про занепокоєння щодо переписаного коду.
Звіти про помилки після активації: справжнім тестом ретельності аудиту Sherlock є те, що відбувається після запуску функцій. Відсутність критичних знахідок протягом перших 90 днів підтвердила б модель попереднього випуску; будь-яка вразливість після активації підірвала б всю тезу.
Впровадження RLUSD у конфіденційних переказах: інституційне використання стейблкоїнів на захищених рейках підтвердило б попит на розрахунки з дотриманням конфіденційності. Показники обсягу в першому кварталі після активації будуть найчіткішим сигналом того, чи готові банки здійснювати транзакції в публічному реєстрі з гарантіями конфіденційності.
Наступна співпраця Sherlock з XRPL: чи продовжить Ripple змагальні аудиторські конкурси для майбутніх поправок, чи повернеться до традиційних приватних аудитів, покаже, наскільки глибоко модель попереднього випуску вкорінена в культурі розробки.
Конкуруючі інциденти безпеки в ланцюжках: кожен великий експлойт на Ethereum або Solana, який можна простежити до вразливості після розгортання, посилює аргументи на користь конвеєра XRPL «аудит-голосування-активація». Порівняння є сильним настільки, наскільки галузь продовжує не впроваджувати подібні процеси.
Що виявив аудит Sherlock XRP Ledger?
Двотижневий аудиторський конкурс, який розпочався 13 квітня 2026 року, виявив 96 дійсних вразливостей у п'яти запропонованих поправках XRPL: 2 критичні, 6 високих, 29 середніх та 59 низьких за рівнем серйозності. Ripple виплатила $309,000 у вигляді винагород RLUSD із призового фонду у $550,000. Усі знахідки були усунені до активації будь-яких відповідних функцій в основній мережі.
У чому полягала критична помилка поправки Batch?
Оригінальна поправка Batch містила недолік перевірки підпису, який дозволяв зловмиснику виконувати внутрішні транзакції з будь-якого рахунку, не володіючи його закритими ключами. Помилка полягала в умові раннього виходу в перевірці підпису зовнішньої транзакції, яку можна було задовольнити без належної перевірки авторизації. Дослідник Пранам'я Кешкамат та інструмент ШІ Cantina Apex виявили її 19 лютого 2026 року. RippleX виправив її в екстреному випуску версії 3.1.1 через чотири дні.
Як працювала вразливість делегування дозволів?
Оригінальна реалізація перевіряла дозволи делегата перед перевіркою підписів транзакцій. На XRPL транзакції, які завершуються помилками класу «tec», все одно стягують комісію. Зловмисник міг неодноразово надсилати недійсні транзакції з підвищеною комісією проти делегованого рахунку, виснажуючи його баланс XRP, не володіючи його ключами. Виправлення перекласифікувало тип помилки та змінило порядок перевірок.
Чи були втрачені кошти через ці вразливості?
Жодні кошти не були втрачені. Обидві критичні вразливості були виявлені до активації відповідних поправок в основній мережі. Помилка Batch була виявлена під час фази голосування валідаторів, а недолік делегування дозволів був розкритий і виправлений до активації. Процес внесення поправок XRP Ledger, який вимагає 80% підтримки валідаторів протягом двох послідовних тижнів, забезпечив структурний буфер, який запобіг експлуатації.
Що таке Sherlock і як працює його модель аудиту?
Sherlock — це фірма з безпеки Web3, яка структурує аудити як змагальні конкурси, ранжуючи дослідників за результатами та пропонуючи фінансові стимули через призові фонди. Співпраця з XRP Ledger була першою співпрацею Sherlock з Ripple та одним із найбільших аудиторських конкурсів 2026 року. Модель відрізняється від традиційних приватних аудитів тим, що запрошує широку участь незалежних дослідників безпеки, які змагаються за винагороди, що виявляє ширший спектр векторів атак, ніж може покрити невелика внутрішня команда.
Чим модель безпеки XRPL відрізняється від моделі Ethereum?
Процес внесення поправок XRPL відокремлює розгортання коду від активації функцій. Нові функції постачаються у випуску програмного забезпечення, але залишаються неактивними, поки валідатори не проголосують за їх активацію, створюючи вікно перегляду, в якому вразливості можуть бути виявлені без екстрених виправлень. Смарт-контракти Ethereum працюють одразу після розгортання, і виправлення вразливостей вимагає розгортання нових контрактів, міграції користувачів або впровадження проксі-оновлень. За перші п'ять місяців 2026 року експлойти DeFi перевищили $840 мільйонів, і 70% експлуатованих контрактів були перевірені, але не мали моніторингу після розгортання.
Які функції включає версія 3.3.0 XRP Ledger?
Версія 3.3.0, випущена 6 серпня 2026 року, містить код для п'яти поправок функцій та патч для очищення. Функції включають конфіденційні перекази для багатоцільових токенів з використанням доказів з нульовим розголошенням, переписані пакетні транзакції для атомарних багатоопераційних розрахунків, переписане делегування дозволів для контрольованого доступу до рахунку, спонсоровані комісії, що дозволяють додаткам покривати витрати користувачів, та DynamicMPT, що дозволяє емітентам змінювати властивості токена після створення.
Чи робить цей аудит XRPL безпечною інвестицією?
Аудит Sherlock відображає ретельний процес безпеки перед випуском, але якість коду є лише одним із багатьох факторів, що впливають на інвестиційні результати. XRP торгувався близько $1.03 наприкінці липня 2026 року, приблизно на 71% нижче свого циклічного максимуму, і ринкові показники залежать від регуляторних змін, рівня інституційного впровадження, конкурентної динаміки та макроекономічних умов. Це освітній аналіз, а не інвестиційна порада. **Дисклеймер**: Цю статтю опубліковано 14 серпня 2026 року. Вона призначена лише для освітніх та інформаційних цілей і не повинна розглядатися як фінансова, інвестиційна чи юридична порада. Ринки криптовалют є волатильними і несуть значний ризик. Читачі повинні проводити власне дослідження та консультуватися з кваліфікованими фахівцями перед прийняттям будь-яких інвестиційних рішень.
