В XRP Ledger нашли лазейки для ограниченных токенов: какие переводы изменятся

В XRP Ledger обсуждают исправления, которые могут изменить правила получения токенов с ограниченным доступом. Разработчики обнаружили исключения: в отдельных сценариях актив, предназначенный только для одобренных адресов, мог оказаться у получателя без нужного разрешения. Для обычных переводов XRP это не новый запрет. Речь о выпущенных компаниями токенах, эмитенты которых заранее включили режим RequireAuth.

30 октября 2026 года история получила широкую огласку после сообщения CoinDesk о четырёх предложенных изменениях. Однако проверка исходных обсуждений показывает более точную картину: из четырёх вариантов два остаются на рассмотрении, а два были закрыты 28 октября без внедрения. Открытые предложения касаются получения долей пулов ликвидности и проверок переводов по доверительным линиям. Они ещё не действуют в основной сети XRP Ledger.

Для владельцев XRP, RLUSD и других активов важен практический вопрос: не начнут ли кошельки внезапно отклонять транзакции, замораживать деньги или требовать новую проверку личности? На основании опубликованного кода говорить о таком массовом сценарии нельзя. Но владельцам выпущенных токенов и разработчикам финансовых приложений стоит понимать, где проходит граница между разрешённым получением актива и ограничением его последующей отправки.

Какие изменения остались после обсуждения четырёх исправлений

Новая работа ведётся в открытом репозитории rippled - программного обеспечения, которое участвует в обработке транзакций XRP Ledger. Первоначальный набор изменений был связан с обновлением fixCleanup3_5_0. Для удобства проверки код разделили на отдельные запросы на включение изменений, или pull requests (PR). После обсуждения разработчики пересмотрели состав пакета.

• PR #8648 - открыт. Предлагается требовать разрешение на оба актива пула AMM, прежде чем адрес сможет получить LP-токен, представляющий долю такого пула.
• PR #8650 - открыт. Предлагается убрать исключение, при котором дополнительный перевод мог проходить без новой проверки авторизации, если на доверительной линии уже был ненулевой баланс.
• PR #8649 - закрыт 28 октября. Идею разрешать неавторизованному владельцу тратить уже полученный актив исключительно при возврате эмитенту решили не внедрять в этом виде.
• PR #8651 - закрыт 28 октября. Дополнительную проверку-инвариант для всех транзакций сочли избыточной по отношению к проверкам, выполняемым в точках получения актива.

Закрытый PR не означает, что соответствующее исправление уже установлено в сети. Это означает, что конкретное предложение больше не проходит процедуру включения в код. Открытый PR, в свою очередь, ещё не равен принятому обновлению: ему предстоят проверки, возможные правки, включение в выпуск программного обеспечения и отдельная процедура голосования валидаторов. По состоянию на 31 октября ни одно из двух оставшихся изменений не подтверждено как активированное в основной сети.

Почему некоторыми токенами XRPL нельзя владеть без разрешения

В XRP Ledger есть принципиальная разница между нативной монетой XRP и активами, которые выпускает конкретный эмитент. XRP существует как собственный актив сети. А выпущенные токены - например, цифровое представление доллара или финансового требования - связаны с обязательствами и правилами организации, от имени которой создан выпуск.

Эмитент может включить флаг RequireAuth. Тогда для получения его токена адрес должен получить соответствующее разрешение. Обычно это делается через доверительную линию (Trust Line): запись в реестре связывает кошелёк с эмитентом и определяет параметры владения выпущенным активом. Пользователь создаёт линию, а эмитент при необходимости одобряет её. Такой механизм может использоваться в продуктах, где право владеть токеном зависит от регистрации, проверки клиента или соблюдения правил конкретного финансового инструмента.

Представим цифровой фонд, чьи доли разрешено держать только клиентам, прошедшим идентификацию. Если человек не получил одобрения эмитента, приложение не должно позволять ему просто приобрести такую долю через альтернативный маршрут и обойти ограничения. Именно консистентность этих проверок - независимо от типа операции - обсуждается в XRP Ledger.

Важно не смешивать два разных механизма. RequireAuth контролирует право держать и получать выпущенный актив; Freeze используется для ограничения расходования в предусмотренных протоколом случаях. Закрытие PR #8649 связано именно с этим разграничением. Оно не даёт оснований утверждать, что все ранее полученные токены автоматически превратятся в заблокированные остатки.

Первая лазейка: как LP-токен может обойти ограничение эмитента

На децентрализованных рынках XRP Ledger существуют автоматические маркетмейкеры - AMM. В таком пуле находятся два актива, а алгоритм обеспечивает обмен между ними. Участник, который предоставляет пулу ликвидность, может получить LP-токен: он представляет долю в пуле и соответствующие права на его активы.

Если один из активов доступен только одобренным адресам, проверка при обычном внесении денег в пул уже имеет смысл: участник не должен обходить правила эмитента. Проблема состоит в том, что LP-токен способен переходить между пользователями отдельно от первоначального внесения ликвидности. Его можно получить не только через стандартную операцию пополнения AMM, но и через различные платёжные или торговые механизмы, включая некоторые сделки с NFT.

В описании PR #8648 разработчики разобрали сценарий, при котором адрес без разрешения получает LP-токен и косвенное право на актив пула, хотя он не должен был получать сам ограниченный токен. Дополнительные операции с пулом, в частности возврат активов в рамках процедур эмитента, делают этот обход не просто формальным. Поэтому предлагается проверять разрешение на оба базовых актива при приобретении LP-токена через поддерживаемые маршруты.

Важно не делать обратный вывод: каждое владение LP-токеном не является нарушением, а все пулы XRPL не станут закрытыми. Новое правило относится к ситуациям, где один из базовых активов имеет включённые требования авторизации. Для обычной открытой пары смысл предложения иной: сохранить существующий доступ и не создать дополнительных ограничений там, где их не установил эмитент.

Разработчики также отдельно рассматривают возможность безопасного выхода из позиции. Предложение не должно превращаться в ловушку, при которой владелец доли не может отказаться от LP-токена. В коде предусмотрено различие между получением доли и её возвратом в AMM или выводом базового актива.

Вторая лазейка: почему ненулевой баланс меняет проверку перевода

Второй открытый запрос, PR #8650, касается менее заметной детали платёжной логики. В одной из проверок наличие разрешения контролировалось только тогда, когда баланс доверительной линии был точно равен нулю. Если же на ней уже находилось некоторое количество выпущенного токена, проверка могла не сработать на очередном поступлении.

Для пользователя это может выглядеть странно. Например, на адресе уже числится 10 единиц ограниченного актива, однако разрешение на его получение отсутствует. По логике эмитента увеличение такого баланса до 20 единиц не должно проходить без авторизации. Но если код проверяет только переход с нулевого остатка, повторное зачисление получает исключение. Предложение #8650 направлено на устранение именно этой неоднозначности.

Ещё одна тонкость возникает при переходе баланса через ноль. В XRP Ledger доверительная линия отражает взаимные обязательства сторон, поэтому направление платежа и знак баланса имеют значение. Разработчики хотят сохранить разрешённые погашения и не допустить, чтобы операция сначала обнулила старую позицию, а затем незаметно создала новый неавторизованный остаток.

В описании предложения фигурируют коды ошибок tecNO_AUTH и tecPATH_PARTIAL. Для обычного пользователя их практическое значение такое: если после будущей активации адрес попытается получить токен без требуемого одобрения, транзакция должна завершиться ошибкой вместо создания нового неподтверждённого баланса. Но конкретное поведение будет зависеть от операции, маршрута и итоговой реализации изменения. Пока код находится в стадии рассмотрения, нельзя объявлять эти коды новым обязательным результатом для всех переводов.

Почему разработчики закрыли два других предложения

Изначальный пакет выглядел шире: помимо проверки получения, обсуждалось, как обращаться с остатками, уже оказавшимися у адресов без одобрения эмитента. PR #8649 предлагал сделать их доступными для расходования только по направлению к самому эмитенту. Так можно было бы разрешить погашение, одновременно заблокировав продажи другим пользователям и использование в некоторых торговых операциях.

Однако при рецензировании участники напомнили об устройстве протокола. RequireAuth не предназначен для общего запрета расходовать полученное ранее. Для контроля расходов существует механизм заморозки Freeze. Изменение общего правила могло бы повлиять на привычные операции и нарушить принципиальное разделение полномочий эмитента. 28 октября автор PR #8649 закрыл предложение, сославшись на согласованную позицию рецензентов: уже имеющийся неавторизованный баланс остаётся расходуемым в рамках действующих правил, а контроль новых поступлений решается оставшимися запросами.

PR #8651 добавлял дополнительный инвариант - проверку состояния всей операции, которая страховала бы от появления неразрешённых остатков. Идея на первый взгляд выглядит полезной: независимая проверка на последнем этапе могла бы поймать то, что пропустил отдельный тип транзакции. Но такой универсальный барьер должен учитывать исключения, например технические псевдоаккаунты AMM и легитимные операции возврата активов. Рецензент отметил, что проверки в местах получения токена уже охватывают необходимые случаи, тогда как глобальный инвариант усложнил бы обслуживание будущих функций. Предложение тоже закрыли 28 октября.

Следовательно, формулировка «XRPL готовит четыре обязательных запрета» сегодня неверна. Речь о двух рассматриваемых исправлениях на получение активов и двух отклонённых вариантах расширения контроля.

Что известно об ущербе: это не сообщение о краже XRP

Из-за слов «обход ограничений» легко представить массовый взлом кошельков. Но такой картины в доступных первоисточниках нет. XRP Ledger Foundation сообщила CoinDesk, что не знает случаев, когда посторонний участник воспользовался оставшимися исключениями для создания неавторизованного баланса. Ранее обнаруженные подобные остатки, по объяснению организации, связаны с действиями самих эмитентов или адресов, прежде получавших разрешение.

Это заявление не превращает код в доказательство абсолютной безопасности и не отменяет необходимости исправлений. Оно лишь означает, что обнаруженный путь потенциального обхода и подтверждённая атака с ущербом - не одно и то же. Разработчики исследуют поведение протокола, проверяют пограничные сценарии и вносят изменения до того, как проблема станет поводом для инцидента.

Новая тема также не связана с компрометацией seed-фраз, приватных ключей или взломом приложения-кошелька. Пользователям XRP не предлагают создавать новые адреса из-за этих PR. Переводы нативного XRP не становятся запрещёнными, поскольку RequireAuth относится к выпущенным активам. Ошибочно распространять такое предупреждение на весь рынок XRP или на каждый стейблкоин вне зависимости от его правил выпуска.

Затронет ли это RLUSD и другие токены XRP Ledger

Вопрос возникает особенно часто из-за популярности долларовых токенов. В XRP Ledger уже используются регулируемые платёжные инструменты, а поддержка RLUSD расширяется и на другие сети. Однако наличие стейблкоина в экосистеме не означает, что все его владельцы в обязательном порядке подпадают под обсуждаемый режим авторизации.

Для оценки конкретного актива нужно выяснить, кто является его эмитентом в нужной сети, какие флаги и разрешения применяются к выпуску, предусмотрены ли отдельные проверки и что именно поддерживает используемый кошелёк или сервис. Это особенно важно, когда один бренд существует сразу в нескольких блокчейнах. Например, переводы RLUSD в XRP Ledger, Ethereum и Base используют разную техническую инфраструктуру, а условия доступа могут зависеть от конкретной платформы.

Сам факт нового PR не доказывает, что конкретная операция с RLUSD будет заблокирована после обновления. Более того, владелец токена не может определить его подлинность только по тикеру или изображению. Перед переводом полезно проверить настоящий RLUSD, сеть и реквизиты эмитента. Такой контроль защищает от совершенно другого класса ошибок, который не исчезнет после исправления RequireAuth.

В перспективе строгие правила владения имеют значение для токенизированных депозитов, фондов и ценных бумаг. Операторам требуется не просто блокчейн, где актив можно передать, а механизм, который сохраняет ограничения при обмене, работе пулов и расчетах между посредниками. С этой точки зрения обсуждение XRPL перекликается с развитием токенизации акций через DTCC, хотя юридические модели и технология в этих проектах существенно отличаются.

Когда два исправления могут заработать в основной сети XRPL

Это не единственное изменение, которое обсуждают разработчики сети. Например, проект кошельков XRP Ledger без начального резерва XRP решает задачу открытия аккаунта с помощью спонсора, а не проблему разрешений на получение токенов. Смешивать эти инициативы и обещать владельцам XRP немедленные изменения было бы ошибкой.

В XRP Ledger изменение правил проверки транзакций нельзя включить только публикацией кода в GitHub. Для этого используется система поправок - amendments. После проверки предложения должны попасть в соответствующий выпуск программного обеспечения; затем валидаторы голосуют за принятие новой версии правил.

По официальной документации XRPL, для активации требуется более 80% поддержки доверенных валидаторов в течение двух последовательных недель. Если порог не выдержан, изменение не включается автоматически. Кроме того, само наличие PR или даже готового кода ещё не означает, что процедура голосования началась. Поэтому назначать дату, когда конкретные переводы начнут отклоняться, сейчас нельзя.

У двух открытых изменений остаются технические вопросы для рецензирования. Например, при работе с AMM необходимо аккуратно обрабатывать исключения для служебных псевдоаккаунтов, не ломать законные выходы из пула и следить за тем, чтобы новая проверка не затронула операции, на которые её вообще не собирались распространять. Это нормальная часть инженерной проверки, а не доказательство, что сеть сейчас работает неправильно целиком.

Отдельно следует отличать обновление протокола от обновления интерфейса кошелька. Даже после будущего голосования обычному пользователю не обязательно понадобится устанавливать новое приложение вручную: многое зависит от реализации конкретного кошелька и его подключения к сети. Но разработчикам сервисов стоит заранее тестировать сценарии работы с ограниченными активами и LP-токенами, чтобы новая проверка не стала неожиданностью для их клиентов.

Что делать пользователям XRP Ledger прямо сейчас

Первое - не предпринимать необоснованные операции. Сообщения о PR #8648 и #8650 не сопровождаются подтверждённой потерей пользовательских XRP и не содержат требования перевести монеты на новый адрес. Если кто-то предлагает «обязательную миграцию», просит приватный ключ или seed-фразу ради исправления fixCleanup3_5_0, это повод проверить источник сообщения, а не следовать инструкции.

• Если вы держите обычный XRP, следите за официальными изменениями сети, но не связывайте их с обязательной блокировкой ваших монет.
• Если вы используете выпущенные токены, проверяйте эмитента, настройки актива и требования платформы к Trust Line перед крупной операцией.
• Если вы работаете с AMM и LP-токенами, обращайте внимание на условия обоих базовых активов пула, особенно если один из них предназначен для ограниченного круга владельцев.
• Если ваша транзакция получила ошибку, сохраняйте хеш и проверяйте результат через обозреватель, а не повторяйте перевод вслепую.
• Не путайте отказ в получении токена по правилам эмитента с AML-проверкой кошелька или происхождения средств: это разные уровни контроля.

Особенно важно проверять, когда именно произошло изменение. Приложение может ссылаться на ещё не действующее предложение, создавать ложную срочность или использовать технические слова «обновление сети» и «авторизация» для выманивания средств. Знание реального статуса PR помогает распознать такую манипуляцию.

Почему два исправления важнее громких заголовков о четырёх запретах

Работа над fixCleanup3_5_0 показывает характерную для блокчейн-инфраструктуры проблему: проверять право владения токеном недостаточно только в одном очевидном месте. Прямой перевод, получение доли пула, сделка через книгу заявок и операция с NFT могут приводить к экономически сходному результату через разные участки программного кода. Если ограничения эмитента должны действовать независимо от маршрута, согласованность всех этих участков критически важна.

Но развитие технологии означает не только добавление блокировок. Иногда правильное инженерное решение - отказаться от слишком широкого ограничения, чтобы не нарушить ранее определённые права владельца. Именно это произошло с идеей запретить расходование уже имеющегося остатка через RequireAuth. Разработчики разделили две задачи: не допускать новых неразрешённых поступлений и не менять без достаточного основания правила использования существующих активов.

На 31 октября 2026 года картина такова: предложения #8648 и #8650 остаются открытыми, #8649 и #8651 закрыты; подтверждений массового ущерба нет, дата активации в основной сети не объявлена. Для пользователей это повод понимать технические особенности выпущенных токенов, а для разработчиков - внимательно следить за итоговым кодом и голосованием валидаторов. Это история о корректировке правил XRP Ledger, а не о взломе всех кошельков XRP.

Материал основан на публичных обсуждениях изменений в репозитории XRPLF/rippled (#8648, #8649, #8650, #8651), документации XRP Ledger об авторизованных доверительных линиях и поправках сети, а также комментариях XRP Ledger Foundation, опубликованных CoinDesk 30 октября 2026 года. Статусы PR проверены 31 октября. Сведения о будущем поведении транзакций относятся к предложениям и могут измениться до активации.

Автор

Barbados