XRP Ledger ha llevado PermissionDelegationV1_1 a su período de activación de 14 días después de que 29 de los 35 validadores de confianza de la red respaldaran la actualización de permisos de cuenta.
Según el panel en vivo de enmiendas de XRP Ledger, la cuenta regresiva comenzó el 21 de septiembre y podría poner en vigor PermissionDelegationV1_1 el 5 de octubre a las 11:18 UTC si el respaldo de los validadores se mantiene por encima del umbral requerido durante todo el período.
Al menos 28 de los 35 validadores de confianza deben seguir respaldando la enmienda. Si el apoyo cae por debajo de ese nivel antes de que termine la cuenta regresiva, el temporizador de activación se reiniciará.
PermissionDelegationV1_1 cambia la forma en que una cuenta de XRP Ledger puede otorgar a otra cuenta autoridad para realizar tareas específicas.
Bajo la estructura actual de cuentas, las empresas que necesitan distintos sistemas o empleados para ejecutar operaciones pueden enfrentarse al problema de dar a una cuenta operativa más autoridad de la que realmente necesita. Permission Delegation está diseñada para separar esas responsabilidades.
Una cuenta podría, por ejemplo, autorizar a otra cuenta a realizar pagos sin darle permiso para cambiar las claves de la cuenta principal. Un emisor de stablecoins podría mantener sus claves principales fuera de línea mientras da a un sistema de cumplimiento conectado a internet permiso para aprobar a clientes para mantener su token.
Cada cuenta delegada puede recibir hasta 10 permisos, mientras que la cuenta que otorga la autoridad conserva la capacidad de modificarlos o revocarlos.
La disposición se asemeja a la separación de responsabilidades utilizada habitualmente por las instituciones financieras, donde las funciones de pagos, cumplimiento y administración no necesariamente comparten el mismo nivel de acceso.
PermissionDelegationV1_1 forma parte de un grupo más amplio de enmiendas introducidas a través de xrpld 3.3.0. La versión incluyó BatchV1_1, ConfidentialTransfer, DynamicMPT y Sponsor junto con Permission Delegation, con varias de estas funciones orientadas a transacciones institucionales y a la emisión de tokens.
Sponsor permitiría que otra entidad cubra las comisiones de transacción y los requisitos de reserva para los usuarios sin controlar sus cuentas. DynamicMPT ofrece a los emisores más flexibilidad sobre propiedades seleccionadas de los Multi Purpose Token, mientras que ConfidentialTransfer está diseñado para ocultar al público los saldos de MPT y los montos de los pagos, conservando al mismo tiempo mecanismos de acceso para las partes autorizadas.
Crypto.news informó anteriormente que ConfidentialTransfer apunta a casos de uso institucionales en los que las empresas pueden necesitar privacidad en las transacciones mientras siguen proporcionando información a auditores y otras partes autorizadas.
PermissionDelegationV1_1 es el segundo intento de llevar permisos delegados de cuenta a XRP Ledger.
La enmienda original se detuvo antes de llegar a la red principal después de que un tester de la comunidad reportara una vulnerabilidad el 15 de septiembre de 2025.
Bajo la implementación afectada, el software verificaba si una cuenta tenía permiso para realizar una transacción antes de verificar correctamente su firma. Ciertas transacciones rechazadas aún podían generar una comisión.
Por lo tanto, un atacante podría haber enviado transacciones no autorizadas con comisiones deliberadamente altas y hacer que otra cuenta las pagara aunque las transacciones no estuvieran correctamente firmadas. Repetir el proceso podría haber agotado el saldo disponible de XRP de la víctima.
Se recomendó a los validadores no respaldar la enmienda después de descubrirse la vulnerabilidad, impidiendo que la versión afectada se activara en mainnet.
El reemplazo se incluyó en xrpld 3.3.0 con cambios en la forma en que se manejan las transacciones no autorizadas. La verificación de firmas ahora se realiza antes del tipo de fallo que podría cargar una comisión a la cuenta objetivo.
Permission Delegation no es la única función de esta versión que regresó tras trabajos de seguridad. BatchV1_1 reemplazó una implementación anterior de Batch después de que los desarrolladores encontraran una vulnerabilidad crítica de firma independiente. La actualización revisada de Batch avanzó en la votación de validadores después de las correcciones y una revisión adicional.
PermissionDelegationV1_1 no cambia directamente la oferta de XRP, su calendario de emisión ni la economía del token, por lo que no existe una razón mecánica para que su activación por sí sola genere una nueva demanda sustancial de XRP.
La enmienda trata sobre permisos de cuenta en lugar del propio token XRP. Las instituciones que utilicen cuentas delegadas seguirían usando XRP para las comisiones normales y los requisitos de reserva del ledger, pero la función no les exige comprar o mantener grandes cantidades de XRP simplemente para usar permisos delegados.
Los desarrollos recientes en la red muestran por qué importa la distinción entre la adopción de XRPL y la demanda de XRP.
Un análisis previo de la exposición de Ripple Prime a XRP concluyó que incluso una actividad institucional significativa dentro del ecosistema de Ripple no se traduce automáticamente en una demanda equivalente de XRP. Las stablecoins y otros activos emitidos pueden manejar gran parte de la transferencia de valor subyacente, mientras XRP conserva funciones que incluyen comisiones de transacción, reservas y algunas funciones de enrutamiento.
Una estructura similar se aplica a Permission Delegation. Los emisores de stablecoins, los proveedores de activos tokenizados y otras empresas podrían usar la función sin convertir a XRP en el activo transferido.
La posible conexión con el precio depende, en cambio, de si la actualización ayuda a atraer más actividad a XRP Ledger con el tiempo.
Los emisores institucionales que quieran mantener fuera de línea las claves de alta autoridad podrían usar cuentas delegadas para pagos recurrentes o tareas de cumplimiento. Si esas capacidades contribuyen a que más empresas emitan activos y procesen transacciones en XRPL, la actividad resultante generaría un mayor uso de la red, donde XRP sigue siendo el activo nativo utilizado para comisiones y reservas.
La evidencia hasta ahora sugiere que el crecimiento de la red y el precio de XRP no siempre se mueven juntos. RLUSD y los activos tokenizados se han expandido en XRPL mientras XRP ha atravesado períodos de debilidad en el precio, lo que demuestra que el aumento de la actividad del ledger no necesariamente produce presión de compra inmediata para el token.
Una prueba institucional de junio en la que participaron JPMorgan, Mastercard, Ondo Finance y Ripple ofreció otro ejemplo. El rescate de bonos del Tesoro tokenizados utilizó XRP Ledger, pero XRP no fue el activo rescatado. Su papel directo siguió ligado a la infraestructura subyacente de la red.
Por lo tanto, PermissionDelegationV1_1 podría aportar otra pieza de infraestructura para usuarios institucionales sin convertirse en un gran catalizador independiente para el precio de XRP.
Sigue siendo posible una reacción del mercado en torno a la activación, ya que los traders pueden responder a las actualizaciones de la red y a las expectativas sobre la adopción. Sin embargo, cualquier efecto sostenido en el precio dependería del uso posterior de la función y de otros factores de mercado, en lugar de limitarse a que la enmienda simplemente se active.
Permission Delegation avanza hacia su activación mientras varias otras funciones de XRP Ledger permanecen en diferentes etapas del proceso de enmienda.
BatchV1_1 está diseñado para agrupar múltiples operaciones en una transacción coordinada, permitiendo que cada acción incluida tenga éxito o falle en conjunto. Esa estructura puede respaldar procesos de liquidación en los que un activo y su pago deben cambiar de manos al mismo tiempo.
ConfidentialTransfer daría a los emisores de Multi Purpose Token la opción de ocultar saldos y montos de transferencia mientras las cuentas siguen siendo visibles. Las partes autorizadas aún podrían recibir la información necesaria para el cumplimiento bajo el diseño propuesto.
Los desarrolladores de XRPL han continuado su trabajo más allá de la versión 3.3.0. La versión 3.4.0, publicada el 16 de septiembre, introdujo revisiones a las funciones de préstamo propuestas junto con otro paquete de correcciones del protocolo.
El marco de préstamos sigue sujeto al proceso de enmienda de la red, y se requiere la aprobación de los validadores antes de que las funciones propuestas puedan activarse en mainnet.
XRP