La enmienda PermissionDelegationV1_1 de XRP Ledger ya está activa en la mainnet, según el rastreador de enmiendas de XRPL, que registra que la funcionalidad entró en vigor el 8 de octubre en el ledger 107,524,865. La enmienda completó su período de aprobación por validadores a fines de septiembre, y ese proceso ha producido ahora una herramienta de control de cuentas activa para el ledger. Según el proceso de enmiendas de XRPL, las funcionalidades llegan a la mainnet solo después de que los validadores las aprueben por consenso, por lo que esta activación es el punto a partir del cual las herramientas están disponibles para uso en producción.

La activación hace que Permission Delegation esté disponible para las instituciones, aunque ningún banco, emisor de stablecoins ni gestor de fondos ha confirmado públicamente una implementación hasta ahora. Las empresas ya pueden construir estas estructuras de permisos directamente en XRPL, mientras que los detalles prácticos siguen siendo responsabilidad de sus proveedores de billeteras, custodios y equipos internos de seguridad. La necesidad que aborda la enmienda es de larga data en las operaciones institucionales con activos digitales, donde la autoridad de firma para transacciones rutinarias normalmente se mantiene separada de las credenciales maestras que controlan una tesorería. Permission Delegation traslada parte de esa separación al propio ledger en lugar de dejarla completamente en software externo.

Un emisor de stablecoins puede dividir el trabajo rutinario entre cuentas

Un emisor de stablecoins, por ejemplo, puede necesitar un equipo para aprobar clientes elegibles y otro para procesar transferencias rutinarias. Bajo el nuevo modelo, la cuenta principal del emisor puede permanecer bajo una custodia más estricta, mientras que una cuenta de cumplimiento recibe la autoridad para aprobar trust lines tras verificaciones KYC y una cuenta de operaciones obtiene autoridad de pagos. Cada cuenta solo ejerce el rol que se le asignó, lo que limita el daño que puede causar una clave diaria comprometida.

Una empresa podría dividir las funciones de la billetera de la siguiente manera:

• Cuenta principal: Crea, modifica o revoca roles delegados mientras su clave permanece bajo una custodia más estricta.
• Cuenta de cumplimiento: Recibe autoridad para una tarea definida de aprobación de clientes.
• Cuenta de operaciones: Recibe autoridad para enviar una categoría aprobada de transacciones, como un pago.

XRPL registra cada asignación en una entrada Delegate del ledger. La cuenta que recibe la asignación firma con sus propias credenciales y paga la tarifa de transacción desde su propio saldo, mientras que la acción autorizada surte efecto para la cuenta principal. La documentación de XRPL describe este esquema como control de acceso basado en roles que puede funcionar junto con la multifirma.

Dónde termina la autoridad delegada

Una empresa puede otorgar autoridad sobre tipos de transacciones específicas o funciones granularesdefinidas. Cada delegado puede tener hasta 10 permisos, y la cuenta principal puede actualizarlos o revocarlos mediante otra transacción DelegateSet.

Algunos poderes permanecen exclusivamente en la cuenta principal. Un delegado no puede cambiar sus claves criptográficas, crear nuevas delegaciones ni enviar una transacción fuera de los permisos que ha recibido. Cada delegación también crea un objeto en el ledger que cuenta para el requisito de reserva de la cuenta principal.

El conjunto de permisos no incluye una función personalizada de políticas de pago. Una empresa no puede usar Permission Delegation por sí sola para aplicar reglas como "solo pagos inferiores a $10,000" o "transferencias solo a estas direcciones". Esos controles siguen correspondiendo al software de la billetera, los flujos de aprobación o los sistemas de cumplimiento.

Los permisos del ledger y las decisiones de cumplimiento se mantienen separados

Permission Delegation determina qué cuenta envía una acción XRPL aprobada, nada más. Las verificaciones KYC, el filtrado de sanciones, los registros de inversionistas, los documentos de fondos y la responsabilidad legal permanecen con el emisor y sus proveedores de servicios. La enmienda divide la autoridad técnica; no automatiza la decisión de cumplimiento subyacente.

El programa piloto de registro de fondos de XRPL con el CSD BR de Brasil sigue un principio similar: el ledger puede respaldar un flujo de trabajo controlado, mientras que la infraestructura de mercado establecida sigue siendo responsable del registro oficial de propiedad. Permission Delegation podría dar a los proyectos que usan ese modelo más flexibilidad sobre qué cuenta ejecuta cada acción autorizada en el ledger.

Un permiso delegado lleva una advertencia publicada

La documentación de XRPL aconseja a las empresas no delegar el permiso granular PaymentBurn hasta que una enmienda separada, fixCleanup3_4_0, se active. Hasta que llegue esa corrección, la documentación indica que un delegado con autoridad PaymentBurn también podría emitir tokens fungibles en ciertas circunstancias. Los demás permisos granulares no se ven afectados.

La advertencia aplica a un solo permiso y no a la enmienda en su conjunto, pero ilustra por qué los emisores deben revisar cada rol delegado antes de trasladar funciones rutinarias a cuentas en línea separadas.

Qué pueden hacer las empresas con la nueva funcionalidad

Permission Delegation ofrece a los emisores de XRPL una forma de dividir responsabilidades entre billeteras sin compartir las credenciales que controlan su cuenta principal. Su valor práctico dependerá de las políticas que se construyan a su alrededor: qué tareas se delegan, con qué rapidez se pueden revocar los permisos y si los proveedores de billeteras convierten esta funcionalidad del protocolo en un sistema de control empresarial utilizable. Las señales más cercanas son observables más que especulativas: si los proveedores de billeteras y custodia agregan soporte para las nuevas transacciones y entradas de delegación, y si fixCleanup3_4_0 alcanza la activación, la condición que la documentación de XRPL establece antes de que PaymentBurn pueda delegarse.

Este artículo tiene fines informativos únicamente y no constituye asesoramiento legal, financiero ni de inversión. Las empresas deben revisar la documentación técnica actual de XRPL y sus propias políticas de seguridad antes de usar permisos delegados.