Los desarrolladores de XRP Ledger lanzaron la versión 3.3.0 de xrpld el 6 de agosto, acercando varios cambios de protocolo a una posible activación en la red principal (mainnet).
El lanzamiento oficial en GitHub confirma el trabajo en ConfidentialTransfer, BatchV1_1, Sponsor y DynamicMPT, junto con correcciones y otros cambios de protocolo. El lanzamiento del software en sí no activa esas características en la red.
La distinción es importante porque algunos informes describen seis actualizaciones como ya activas. Según el proceso de enmiendas de XRP Ledger, las nuevas características del protocolo requieren el apoyo de los validadores antes de su activación. Una enmienda debe mantener más del 80% de apoyo de los validadores de confianza durante dos semanas consecutivas antes de entrar en vigor.
ConfidentialTransfer está diseñado para añadir privacidad a los Tokens Multiuso (Multi-Purpose Tokens), o MPTs. La documentación de XRPL indica que la enmienda utiliza criptografía para proteger los saldos individuales y los montos de transferencia, preservando al mismo tiempo mecanismos que permiten a las partes autorizadas, incluidos emisores o auditores, verificar la información necesaria para el cumplimiento normativo.
La característica sigue sujeta a la activación de la enmienda, por lo que las transferencias privadas de MPT aún no deben describirse como activas en la red principal (mainnet) de XRPL.
BatchV1_1 es otro componente importante. El estándar XLS-56 permite que múltiples transacciones se empaqueten y procesen juntas, incluyendo transacciones que involucran diferentes cuentas. La ejecución atómica puede ayudar en los flujos de trabajo de liquidación donde varias acciones deben tener éxito juntas en lugar de dejar una parte completada mientras otra falla.
Batch tiene una historia importante. Una versión anterior fue deshabilitada antes de la activación en la red principal (mainnet) después de que se descubriera un problema de seguridad en la lógica de firma de transacciones. La Fundación XRPL se inclinó posteriormente por BatchV1_1 como el reemplazo corregido. Como se informó anteriormente en la cobertura de seguridad de XRPL, los desarrolladores han aumentado la revisión formal en torno a las actualizaciones recientes.
La Delegación de Permisos siguió un camino similar. XRPL reveló en septiembre de 2025 que un error en la enmienda anterior podría haber permitido que una transacción no autorizada cargara tarifas a otra cuenta bajo condiciones específicas. Se aconsejó a los validadores que votaran en contra, y la característica vulnerable nunca se activó. PermissionDelegationV1_1 fue desarrollada como su reemplazo.
El concepto revisado permite que una cuenta otorgue permisos de transacción definidos sin entregar su clave privada principal, lo que respalda las carteras operativas con autoridad limitada.
Sponsor, basado en XLS-68, está diseñado para permitir que otra cuenta cubra las tarifas de transacción o los requisitos de reserva mientras el usuario mantiene el control de la cuenta y las claves. La característica podría permitir a las aplicaciones incorporar usuarios sin que estos necesiten adquirir XRP únicamente para cubrir los costos de la red. La propuesta XLS-68 apoya explícitamente el patrocinio de tarifas y reservas, al tiempo que preserva el control de las claves del usuario.
DynamicMPT se dirige a los emisores de tokens. La propuesta XLS-94 permite a los emisores designar propiedades seleccionadas de MPT como mutables al crear un token, para luego actualizar esos campos permitidos. El estándar tiene como objetivo adaptarse a los requisitos comerciales o de cumplimiento normativo cambiantes sin hacer que todas las propiedades del token sean libremente editables.
Juntas, estas características encajan con el creciente enfoque de XRPL en las finanzas tokenizadas. En una cobertura relacionada con la tokenización, crypto.news informó que JPMorgan, Mastercard, Ondo Finance y Ripple probaron una redención de Tesorería tokenizada utilizando XRPL.
Es necesaria una corrección en torno al ampliamente difundido marco de “seis actualizaciones”. fixCleanup3_2_0 pertenece al ciclo anterior de xrpld 3.2.0, no al paquete de características 3.3.0 recién lanzado. El registro de cambios (changelog) de GitHub 3.3.0, en cambio, muestra el trabajo en LendingProtocolV1_1 y una pista separada de fixCleanup3_3_0 junto con las características principales.
Por lo tanto, el lanzamiento no debe interpretarse como la disponibilidad simultánea de seis capacidades terminadas. Es un hito del software de servidor que proporciona a los validadores y operadores el código necesario para las decisiones de enmienda. Las enmiendas individuales pueden tener diferentes plazos de votación y pueden no activarse si el apoyo cae por debajo del umbral requerido.
Este proceso de gobernanza ha sido importante anteriormente. Las enmiendas originales de Batch y Delegación de Permisos fueron detenidas después de que se identificaran errores antes de la activación en la red principal (mainnet), lo que demuestra que la inclusión en el software o la votación de los validadores no es lo mismo que el despliegue en producción.
Los operadores de nodos ahora deben evaluar la versión 3.3.0 y decidir si actualizar y apoyar las enmiendas individuales. Las fechas exactas de activación dependen de la votación de los validadores, en lugar del lanzamiento del software del 6 de agosto. Las reglas de enmienda de XRPL requieren que la supermayoría persista continuamente durante dos semanas.
Para los titulares de XRP, el cambio inmediato es técnico más que monetario. La versión 3.3.0 amplía el conjunto de herramientas potenciales de la red para la privacidad, la liquidación en varios pasos, la autoridad delegada, la incorporación patrocinada y la emisión de tokens configurables, pero ninguna garantiza una mayor demanda de XRP o una apreciación del precio.
Los próximos hitos verificables serán la adopción de la versión 3.3.0 por parte de los validadores, los niveles de soporte de las enmiendas y las fechas de activación programadas. Hasta que se cumplan esos umbrales, las nuevas capacidades deben describirse como lanzadas en el software de nodo y en proceso de gobernanza, no como características totalmente activas de la red principal (mainnet) de XRP Ledger.
Las decisiones de los validadores, en lugar del marketing de lanzamiento, determinarán cuándo cada característica será utilizable en la red principal (mainnet).
