Поправка PermissionDelegationV1_1 в XRP Ledger теперь работает в основной сети, согласно трекеру поправок XRPL, который фиксирует вступление функции в силу 8 октября на уровне книги 107 524 865. Поправка завершила период одобрения валидаторами в конце сентября, и в результате этого процесса появился действующий инструмент управления счетами в реестре. В соответствии с процессом внесения поправок XRPL функции попадают в основную сеть только после их одобрения валидаторами консенсусом, поэтому данная активация означает, что инструмент стал доступен для промышленного использования.

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

Эмитент стейблкоинов может распределить рутинную работу между счетами

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

Компания могла бы распределить обязанности по кошелькам следующим образом:

• Основной счёт: создаёт, изменяет или отзывает делегированные роли, при этом его ключ остаётся под более строгой опекой.
• Комплаенс-счёт: получает полномочия для определённой задачи одобрения клиентов.
• Операционный счёт: получает полномочия отправлять одобренную категорию транзакций, например платёж.

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

Границы делегированных полномочий

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

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

Набор полномочий не включает функции пользовательских платёжных политик. Компания не может использовать одно лишь делегирование полномочий для введения правил вроде «только платежи ниже $10 000» или «переводы только на эти адреса». Такой контроль по-прежнему относится к программному обеспечению кошельков, процессам одобрения или комплаенс-системам.

Полномочия в реестре и комплаенс-решения остаются раздельными

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

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

Одно делегируемое полномочие сопровождается официальным предупреждением

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

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

Что компании могут делать с новой функцией

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

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