XRP Ledger 3.3.0 trae mejoras de privacidad y por lotes

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 mainnet.
Resumen

• XRPL 3.3.0 introduce código de protocolo, pero se requiere la aprobación de los validadores antes de que ocurra cualquier activación en la mainnet.
• ConfidentialTransfer protegería los saldos de MPT y los montos de transferencia mientras preserva el acceso de cumplimiento para las partes autorizadas.
• BatchV1_1 restaura la funcionalidad de transacciones atómicas después de que una versión anterior fue detenida debido a un defecto de seguridad.
• Sponsor permitiría a terceros cubrir tarifas y reservas mientras los usuarios mantienen el control total de la cuenta.
• DynamicMPT permitiría a los emisores modificar propiedades seleccionadas de tokens más adelante, apoyando las necesidades comerciales y de cumplimiento en evolución.

La publicación oficial en GitHub confirma el trabajo en ConfidentialTransfer, BatchV1_1, Sponsor y DynamicMPT, junto con correcciones y otros cambios de protocolo. La propia publicación de software no activa esas características en la red.

La distinción es importante porque algunos informes describen seis mejoras como ya activas. Bajo el proceso de enmienda de XRP Ledger, las nuevas características del protocolo requieren el apoyo de los validadores antes de la activación. Una enmienda debe mantener más del 80% de apoyo de validadores confiables durante dos semanas continuas antes de entrar en vigor.

XRP Ledger 3.3.0 añade herramientas de privacidad y transacciones atómicas

ConfidentialTransfer está diseñado para añadir privacidad a los Tokens Multiusos, o MPTs. La documentación de XRPL dice que la enmienda utiliza criptografía para proteger saldos individuales y montos de transferencia mientras preserva mecanismos que permiten a las partes autorizadas, incluidos emisores o auditores, verificar la información necesaria para el cumplimiento.

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 mainnet de XRPL.

BatchV1_1 es otro componente importante. El estándar XLS-56 permite que múltiples transacciones se empaqueten y procesen juntas, incluidas transacciones que involucran diferentes cuentas. La ejecución atómica puede ayudar a los flujos de trabajo de liquidación donde varias acciones deben tener éxito juntas en lugar de dejar una parte completada mientras otra falla.

Las características revisadas siguen hallazgos de seguridad anteriores

Batch tiene una historia importante. Una versión anterior fue desactivada antes de la activación en la mainnet después de que se descubriera un problema de seguridad en la lógica de firma de transacciones. La Fundación XRPL luego se movió hacia 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 divulgó en septiembre de 2025 que un error en la enmienda anterior podría haber permitido que una transacción no autorizada cobrara 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, apoyando billeteras operativas con autoridad limitada.

Sponsor y DynamicMPT apuntan a la incorporación institucional

Sponsor, basado en XLS-68, está diseñado para permitir que otra cuenta cubra tarifas de transacción o requisitos de reserva mientras el usuario mantiene el control de la cuenta y las claves. La característica podría permitir que las aplicaciones incorporen usuarios sin requerirles adquirir XRP únicamente para cubrir costos de red. La propuesta XLS-68 apoya explícitamente el patrocinio de tarifas y reservas mientras preserva el control de las claves del usuario.

DynamicMPT está dirigido a emisores de tokens. La propuesta XLS-94 permite a los emisores designar propiedades seleccionadas de MPT como mutables al crear un token, y luego actualizar esos campos permitidos más tarde. El estándar está destinado a acomodar los cambiantes requisitos comerciales o de cumplimiento sin hacer que cada propiedad del token sea libremente editable.

Juntas, estas características se alinean 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 un canje de Tesorería tokenizado utilizando XRPL.

No todas las actualizaciones citadas pertenecen a la versión 3.3.0

Es necesaria una corrección en torno al marco de "seis actualizaciones" que ha circulado ampliamente. fixCleanup3_2_0 pertenece al ciclo anterior xrpld 3.2.0, no al paquete de características recién lanzado 3.3.0. El changelog de GitHub de la 3.3.0 muestra en su lugar trabajo en LendingProtocolV1_1 y una pista separada fixCleanup3_3_0 junto a las características principales.

Por lo tanto, el lanzamiento no debe interpretarse como seis capacidades terminadas que se vuelven disponibles simultáneamente. Es un hito de software de servidor que proporciona a los validadores y operadores el código necesario para decisiones de enmienda. Las enmiendas individuales pueden tener diferentes cronogramas de votación y pueden no activarse si el apoyo cae por debajo del umbral requerido.

Este proceso de gobernanza ha sido importante antes. Las enmiendas originales de Batch y Permission Delegation fueron detenidas después de que se identificaron errores antes de la activación en mainnet, mostrando que la inclusión en el software o la votación de validadores no es lo mismo que el despliegue en producción.

¿Qué sucede a continuación para los validadores de XRPL?

Los operadores de nodos ahora necesitan evaluar la versión 3.3.0 y decidir si actualizar y apoyar 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 potencial conjunto de herramientas de la red para la privacidad, liquidación en múltiples pasos, autoridad delegada, incorporación patrocinada y emisión de tokens configurable, pero ninguna garantiza una mayor demanda de XRP o apreciación de precios.

Los próximos hitos verificables serán la adopción de 3.3.0 por parte de los validadores, los niveles de apoyo a 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 del nodo y avanzando a través de la gobernanza, no como características completamente activas de la mainnet de XRP Ledger.

Las decisiones de los validadores, en lugar del marketing de lanzamiento, determinarán cuándo cada característica se vuelve utilizable en mainnet.