XRP Ledger (XRPL) está cada vez más cerca de activar una mejora que permitiría a las organizaciones dividir el control de una sola cuenta entre varias cuentas delegadas, limitando el poder de cualquier clave operativa individual.

PermissionDelegationV1_1 está diseñada para organizaciones que procesan transacciones con frecuencia pero no desean claves capaces de controlar una cuenta completa dentro de los sistemas operativos cotidianos. Un emisor de stablecoins, por ejemplo, puede necesitar un sistema para aprobar las trust lines de los clientes (el mecanismo del ledger para mantener activos emitidos), otro para procesar pagos y una configuración más protegida para gestionar la seguridad de la cuenta. La enmienda permitiría dividir esas tareas entre cuentas XRPL separadas.

Su elemento de "estilo bancario" es la separación de responsabilidades. No implica aprobación regulatoria ni adopción confirmada por parte de un banco. Un delegado comprometido podría seguir siendo objeto de abuso dentro de su rol asignado, pero el atacante no recibiría automáticamente todos los poderes de la cuenta principal, reduciendo el daño potencial de una única clave operativa expuesta.

XRPL aplicaría cada permiso en la cadena

Según la especificación XLS-75, la cuenta que asigna la autoridad es el delegador. Este envía una transacción DelegateSet que nombra una segunda cuenta y las acciones que esa cuenta puede realizar. La relación se almacena en una entrada de ledger Delegate.

El delegado firma con sus propias claves, identifica la cuenta en cuyo nombre actúa y paga la tarifa de la transacción. XRPL rechaza las solicitudes fuera de la autoridad registrada, y el delegador puede posteriormente actualizar o eliminar esa autoridad.

La documentación oficial enumera permisos por tipo de transacción y permisos granulares más específicos, y cada delegado puede recibir un máximo de diez. Los controles granulares disponibles están predefinidos, por lo que las organizaciones no pueden crear cualquier restricción que deseen. Los delegados también deben mantener cuentas con fondos, y cada delegación crea un objeto en la cadena que aumenta el requisito de reserva del propietario del delegador, es decir, el XRP mínimo que una cuenta debe mantener por cada objeto de que posee.

Los poderes sensibles, incluido el cambio de claves de firma o el nombramiento de nuevos delegados, no pueden delegarse. Las transacciones que no puedan entrar de inmediato en el ledger abierto también fallan en lugar de entrar en la cola.

Veintinueve votos iniciaron una cuenta regresiva condicional

PermissionDelegationV1_1 entró en su período de activación de 14 días el 21 de septiembre con el respaldo de 29 de los 35 validadores de confianza de XRP Ledger, según el rastreador de enmiendas en vivo. Las enmiendas son el mecanismo integrado del ledger para cambiar sus reglas, y el respaldo sostenido de los validadores es lo que lleva el nuevo código de protocolo a la mainnet. Al menos 28 validadores deben continuar apoyándola, y caer por debajo de ese nivel reiniciaría el reloj. CoinDesk informó una hora de activación proyectada del 5 de octubre a las 11:18 UTC, siempre que el respaldo se mantenga sin interrupciones.

El código ya existe en el software del servidor de XRPL, pero no puede usarse en la mainnet antes de la activación. La enmienda separada Batch V1.1 sigue el mismo proceso de dos semanas, aunque se refiere a transacciones vinculadas en lugar de autoridad de cuentas.

La delegación no reemplaza a la multifirma

La multifirma determina cuántas partes aprobadas deben autorizar una acción, mientras que la delegación de permisos limita qué acciones puede solicitar una cuenta operativa. Una organización podría combinarlas restringiendo a un delegado a pagos mientras requiere que varias personas aprueben cada pago.

Tras un compromiso de claves, la multifirma puede impedir que un firmante robado alcance el umbral de aprobación, mientras que la delegación puede restringir los tipos de transacción disponibles para el atacante incluso después de que la cuenta delegada sea comprometida. Ninguno de los dos controles verifica que la instrucción de negocio sea legítima.

La versión original falló antes de llegar a la mainnet

Un probador de la comunidad descubrió que la primera implementación de PermissionDelegation podía, bajo ciertas condiciones, cobrar una tarifa de transacción a otra cuenta incluso cuando la transacción delegada estaba firmada incorrectamente. Envíos repetidos de tarifas altas podrían haber reducido el saldo de XRP de la víctima sin revelar su clave privada.

La falla se detectó durante las pruebas, y la enmienda nunca se activó en la mainnet. La divulgación oficial de vulnerabilidad reportó ninguna pérdida de fondos de usuarios reales.

Coindoo examinó previamente por qué Permission Delegation regresó en forma revisada con las enmiendas de xrpld 3.3.0. La nueva votación muestra que los validadores ahora están dispuestos a considerar la activación del reemplazo.

La activación no establecerá la adopción institucional

Las billeteras y proveedores de custodia aún deben crear interfaces para crear, revisar y revocar la autoridad delegada. se ha anunciado ningún despliegue bancario específico, y las instituciones siguen siendo responsables de decidir qué cuentas reciben cada permiso.

Las decisiones de cumplimiento también permanecerían fuera del ledger. Una empresa seguiría realizando verificaciones de identidad, filtros de sanciones y revisiones de riesgo a través de sus propios sistemas. XRPL aplicaría qué delegado puede presentar la autorización resultante; no determinaría si el cliente debía haber sido aprobado.

El uso de la función sería visible a través de las entradas Delegate públicas, aunque vincular una dirección a una empresa puede requerir divulgación voluntaria. Las cuentas delegadas también necesitan XRP para reservas y tarifas, pero la activación no establece ningún volumen de uso ni demanda automática del token.

El uso en producción será la próxima prueba

Si el respaldo de los validadores se mantiene, la evidencia provendrá de integraciones de billeteras, nuevas entradas Delegate y despliegues con nombres específicos. Esas señales mostrarán si las organizaciones necesitan separación a nivel de protocolo entre la propiedad de la cuenta y las operaciones cotidianas.

La votación hace posible el acceso limitado a cuentas. Su valor dependerá de qué tan estrictamente configuren las organizaciones esos permisos y de si usan la función más allá de las demostraciones.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero, legal ni de seguridad. El respaldo de los validadores y los tiempos de activación pueden cambiar.