Официальная документация XRP Ledger (XRPL) рекомендует владельцам счетов не делегировать разрешение PaymentBurn, пока поправка fixCleanup3_4_0 не будет активирована в сети. Предупреждение связано с уязвимостью на границе между сжиганием и эмиссией токенов — при определённых обстоятельствах она позволяла делегату с правом только сжигания выпускать новые токены вместо их уничтожения. Уязвимость не может создавать новые XRP, но затрагивает ту самую задачу, которую делегирование разрешений должно было удерживать за офлайн-ключами.

Для чего предназначался делегат с правом только сжигания

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

Два из двенадцати детализированных разрешений реестра касаются эмиссии токенов. PaymentMint охватывает платежи, создающие взаимозаменяемые токены или Multi-Purpose Tokens (MPT). PaymentBurn охватывает платежи, уничтожающие их, и документация точно определяет его границу: сжигание останавливается на нулевом балансе.

Уязвимость находится именно на этой границе. До исправления платёж, отправленный под PaymentBurn, мог при определённых обстоятельствах выйти за ноль и выпустить новые токены доверенных линий или MPT. fixCleanup3_4_0 отклоняет любой делегированный платёж «только сжигание», сумма которого перешла бы границу в эмиссию, если тот же делегат не имеет и PaymentMint. Остальные одиннадцать детализированных разрешений не затронуты.

Это делает баг узким по охвату, но неудобным по тому, чего он касается. Воспользоваться им может только счёт, который эмитент ранее назначил делегатом, но то, что он открывает, — это эмиссия, то есть задача, которую делегирование должно было удерживать за офлайн-ключами.

Холодное хранение не защищает ключи делегата

Делегированные транзакции подписываются мастер-ключом, регулярным ключом или мультисписком самого делегата. Эмитент может полностью держать свои основные учётные данные офлайн и всё равно оказаться под риском, если делегат с PaymentBurn скомпрометирован, настроен неправильно или действует за пределами своих полномочий.

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

Делегирование запустили до того, как его исправление набрало голоса

Это вторая уязвимость, обнаруженная в функции делегирования XRPL. Первоначальная версия была отозвана в 2025 году после того, как тестер из сообщества обнаружил на devnet, что она может начислять комиссии за транзакции счетам, не подписавшим их, а официальное раскрытие информации подтверждает, что она так и не достигла Mainnet. Её замена, PermissionDelegationV1_1, была запущена 8 октября, согласно панели поправок XRPL, в то время как исправление PaymentBurn ещё собирало поддержку валидаторов.

Поэтому риску подвержены отдельные счета: затронуты только эмитенты, выдавшие PaymentBurn с момента запуска. Каждое разрешение публично, поскольку записи Delegate в реестре фиксируют выдающий счёт, делегата и его список разрешений. На момент написания ни документация XRPL, ни опубликованные материалы не называют затронутого эмитента или случаи злоупотреблений.

Само по себе увеличение эмиссии ничего бы не доказало, поскольку эмитент мог намеренно выдать PaymentMint. Объяснения потребовал бы делегат, обладающий только PaymentBurn, чьи платежи добавили токены.

Что эмитенты могут проверить до среды

Опубликованная рекомендация XRPL — прекратить делегирование PaymentBurn до активации исправления. Эмитентам, уже выдавшим его, следует действовать в таком порядке:

1. Извлечь все записи Delegate на счёте эмитента и отметить любой список разрешений, содержащий PaymentBurn.
2. Повторно отправить DelegateSet с полным списком сохраняемых разрешений. Новый список заменяет старый, поэтому всё, что не включено, удаляется.
3. Считать разрешение отозванным только после того, как изменение появится в валидированном реестре.
4. Отдельно проверить прошлые платежи делегата, так как отзыв полномочий останавливает их использование в будущем, но не отменяет прежние транзакции.
5. Вновь делегировать PaymentBurn только после того, как fixCleanup3_4_0 отобразится как активированная в Mainnet.

Почему голосование всё ещё может затянуться

Согласно официальным правилам поправок, для изменения требуется супер большинства доверенных валидаторов, удерживаемое две недели подряд. При 35 валидаторах в отслеживаемом наборе порог составляет 29, и падение ниже него сбрасывает отсчёт. Этот сброс уже происходил один раз; сейчас поддержку исправления дают 33 из 35 доверенных валидаторов.

Даже при сохранении поддержки 14:46 UTC — момент открытия двухнедельного окна. Активация происходит в точке голосования реестра, поэтому изменение может вступить в силу спустя некоторое время после этого.

Валидаторы голосуют не только за это исправление. fixCleanup3_4_0 объединяет 25 изменений, охватывающих хранилища, кредитование, автоматизированные маркет-мейкеры, NFT, эскроу и спонсорство, и исправление PaymentBurn — последний пункт в её списке. Она исправляет код кредитования, не включая сам Lending Protocol, у которого отдельная поправка ещё на голосовании.

Для эмитентов решающее подтверждение — появление fixCleanup3_4_0 в списке активированных в Mainnet. До тех пор разрешение PaymentBurn несёт больше полномочий, чем следует из его названия.

Эта статья впервые появилась на Coindoo.