Команда XRP Ledger опубликовала технический отчёт об инциденте 30 июля 2026 года, когда поток manifest-сообщений перегрузил обработку этих сообщений в xrpld и вызвал массовые разрывы peer-соединений. Многие узлы быстро потеряли значительную часть соседей, включая отдельные UNL-узлы. При этом базовый реестр не останавливался и не форкался, оставшиеся валидаторы сохраняли консенсус, а разработчики не зафиксировали потерю средств, компрометацию приватных ключей или нарушение целостности данных реестра.
Корневая причина была связана с тем, что протокол пересылал полученные manifests независимо от статуса доверия. Узел, накопивший большой объём мусорных записей, мог повторно разослать их при каждом новом соединении, поэтому обычный churn соединений усиливал нагрузку. В отчёте также говорится о десятках тысяч synthetic revocation-only manifests и большом числе проверенных активных manifests с уникальными ключами, наблюдавшихся во время инцидента.
Разработчики ускорили набор уже тестировавшихся ограничений: лимиты на размер manifest, количество записей в сообщении и объём недоверенного кэша. Эти изменения вошли в экстренный релиз 3.2.1 от 31 июля; операторам рекомендовали после обновления выполнить корректный перезапуск для очистки уже сохранённых недоверенных записей. Позже выяснилось, что первоначальные лимиты были слишком жёсткими для нормального gossip во время продолжающегося flood, поэтому в 3.3.0 границы скорректировали.
Отдельно команда обозначила дальнейшие меры: более универсальную фильтрацию входящего трафика, ограничение и пагинацию исходящего, расширение backpressure-механизмов, а также улучшение метрик, логирования, трассировки и раннего мониторинга. Инцидент классифицируется как проблема доступности и истощения ресурсов, а не как взлом консенсуса или кража активов.