XRP Ledger перевел PermissionDelegationV1_1 в 14-дневный период активации после того, как 29 из 35 доверенных валидаторов сети поддержали обновление разрешений аккаунта.
Краткое содержание
- PermissionDelegationV1_1 может активироваться 5 октября, если поддержка валидаторов останется выше требуемого порога в 80%.
- Обновление позволяет аккаунтам XRPL делегировать определенные разрешения, не предоставляя другому аккаунту полный контроль над своими ключами.
- Делегирование разрешений напрямую не изменяет предложение XRP или токеномику, поэтому любое влияние на цену в значительной степени зависит от принятия и активности сети.
Согласно панели мониторинга поправок XRP Ledger в реальном времени, обратный отсчет начался 21 сентября и может ввести PermissionDelegationV1_1 в действие 5 октября в 11:18 UTC, если поддержка валидаторов останется выше требуемого порога в течение всего периода.
По крайней мере 28 из 35 доверенных валидаторов должны продолжать поддерживать поправку. Если поддержка упадет ниже этого уровня до окончания обратного отсчета, таймер активации сбросится.
PermissionDelegationV1_1 разделяет полномочия аккаунта XRP Ledger
PermissionDelegationV1_1 меняет способ, которым аккаунт XRP Ledger может предоставить другому аккаунту полномочия на выполнение определенных задач.
В текущей структуре аккаунта предприятия, которым нужны разные системы или сотрудники для выполнения операций, могут столкнуться с проблемой предоставления операционному аккаунту больше полномочий, чем ему действительно нужно. Делегирование разрешений предназначено для разделения этих обязанностей.
Аккаунт может, например, авторизовать другой аккаунт для совершения платежей, не давая ему разрешения на изменение ключей основного аккаунта. Эмитент стейблкоина может держать свои основные ключи офлайн, предоставляя подключенной к интернету системе комплаенса разрешение на одобрение клиентов для хранения своего токена.
Каждый делегированный аккаунт может получить до 10 разрешений, при этом аккаунт, предоставляющий полномочия, сохраняет возможность изменять или отзывать их.
Эта схема напоминает разделение обязанностей, обычно используемое финансовыми учреждениями, где платежные, комплаенс- и административные функции не обязательно имеют одинаковый уровень доступа.
PermissionDelegationV1_1 является частью более крупной группы поправок, представленных через xrpld 3.3.0. В выпуск вошли BatchV1_1, ConfidentialTransfer, DynamicMPT и Sponsor вместе с делегированием разрешений, причем несколько функций ориентированы на институциональные транзакции и выпуск токенов.
Sponsor позволил бы другой организации покрывать комиссии за транзакции и резервные требования для пользователей, не контролируя их аккаунты. DynamicMPT дает эмитентам больше гибкости в отношении выбранных свойств многоцелевых токенов (MPT), а ConfidentialTransfer предназначен для сокрытия балансов MPT и сумм платежей от публичного просмотра при сохранении механизмов доступа для авторизованных сторон.
Crypto.news ранее сообщал, что ConfidentialTransfer нацелен на институциональные случаи использования, когда компаниям может потребоваться конфиденциальность транзакций, но при этом предоставление информации аудиторам и другим авторизованным сторонам.
Делегирование разрешений возвращается после более ранней уязвимости безопасности
PermissionDelegationV1_1 — это вторая попытка привнести делегированные разрешения аккаунта в XRP Ledger.
Исходная поправка была остановлена до выхода в основную сеть после того, как тестировщик сообщества сообщил об уязвимости 15 сентября 2025 года.
В затронутой реализации программное обеспечение проверяло, имеет ли аккаунт разрешение на выполнение транзакции, прежде чем должным образом проверить его подпись. Некоторые отклоненные транзакции все еще могли повлечь комиссию.
Таким образом, злоумышленник мог отправить несанкционированные транзакции с намеренно высокими комиссиями и заставить другой аккаунт оплатить их, даже если транзакции не были должным образом подписаны. Повторение процесса могло истощить доступный баланс XRP жертвы.
Валидаторам было рекомендовано не поддерживать поправку после обнаружения уязвимости, что предотвратило активацию затронутой версии в основной сети.
Замена была включена в xrpld 3.3.0 с изменениями в обработке несанкционированных транзакций. Проверка подписи теперь происходит до типа сбоя, который мог бы списать средства с целевого аккаунта.
Делегирование разрешений — не единственная функция из релиза, которая возвращается после работы над безопасностью. BatchV1_1 заменил более раннюю реализацию Batch после того, как разработчики обнаружили отдельную критическую уязвимость подписи. Пересмотренное обновление Batch прошло через голосование валидаторов после исправлений и дополнительной проверки.
Может ли PermissionDelegationV1_1 повлиять на цену XRP?
PermissionDelegationV1_1 напрямую не изменяет предложение XRP, график выпуска или токеномику, не оставляя механических причин для того, чтобы только его активация создала существенный новый спрос на XRP.
Поправка касается разрешений аккаунтов, а не самого токена XRP. Институты, использующие делегированные аккаунты, по-прежнему будут использовать XRP для обычных комиссий и требований к резервам в реестре, но функция не требует от них покупать или держать большие объёмы XRP просто для использования делегированных разрешений.
Недавние события в сети показывают, почему различие между внедрением XRPL и спросом на XRP имеет значение.
Предыдущий анализ подверженности Ripple Prime к XRP показал, что даже существенная институциональная активность внутри экосистемы Ripple не преобразуется автоматически в эквивалентный спрос на XRP. Стейблкоины и другие выпущенные активы могут обрабатывать большую часть передачи базовой стоимости, тогда как XRP сохраняет роли, включая комиссии за транзакции, резервы и некоторые функции маршрутизации.
Аналогичная структура применима к делегированию разрешений. Эмитенты стейблкоинов, поставщики токенизированных активов и другие предприятия могли бы использовать эту функцию, не делая XRP активом, который передаётся.
Возможная связь с ценой вместо этого зависит от того, поможет ли обновление со временем привлечь больше активности в XRP Ledger.
Институциональные эмитенты, которые хотят держать ключи с высокими полномочиями офлайн, могли бы использовать делегированные аккаунты для регулярных платежей или задач соответствия. Если эти возможности будут способствовать тому, что больше предприятий будут выпускать активы и обрабатывать транзакции в XRPL, возникающая в результате активность создаст больше использования сети, где XRP остаётся нативным активом, используемым для комиссий и резервов.
Доказательства на данный момент свидетельствуют о том, что рост сети и цена XRP не всегда движутся вместе. RLUSD и токенизированные активы расширились в XRPL, в то время как XRP переживал периоды ценовой слабости, показывая, что рост активности в реестре не обязательно создаёт немедленное давление покупателей на токен.
Институциональный тест в июне с участием JPMorgan, Mastercard, Ondo Finance и Ripple предоставил ещё один пример. Погашение токенизированных казначейских обязательств использовало XRP Ledger, но XRP не был активом, который погашался. Его прямая роль оставалась связанной с базовой сетевой инфраструктурой.
Таким образом, PermissionDelegationV1_1 мог бы предоставить ещё один элемент инфраструктуры для институциональных пользователей, не становясь крупным самостоятельным катализатором цены XRP.
Реакция рынка вокруг активации остаётся возможной, поскольку трейдеры могут реагировать на обновления сети и ожидания, связанные с внедрением. Однако любой устойчивый ценовой эффект зависел бы от последующего использования функции и других рыночных факторов, а не просто от включения поправки.
XRP Ledger создаёт больше инструментов для институциональных транзакций
Делегирование разрешений движется к активации, в то время как несколько других функций XRP Ledger остаются на разных этапах процесса внесения поправок.
BatchV1_1 предназначен для объединения нескольких операций в скоординированную транзакцию, позволяя каждому включённому действию успешно выполниться или не выполниться вместе. Такая структура может поддерживать процессы расчётов, где актив и его оплата должны перейти из рук в руки одновременно.
ConfidentialTransfer предоставил бы эмитентам Multi Purpose Token возможность скрывать балансы и суммы переводов, оставляя аккаунты видимыми. Уполномоченные стороны по-прежнему могли бы получать информацию, необходимую для соответствия, в рамках предлагаемого дизайна.
Разработчики XRPL продолжили работу после релиза 3.3.0. Версия 3.4.0, выпущенная 16 сентября, представила пересмотр предложенных функций кредитования вместе с очередным пакетом исправлений протокола.
Структура кредитования по-прежнему подчиняется процессу внесения поправок в сети, требующему одобрения валидаторов, прежде чем предложенные функции смогут стать активными в основной сети.
