• La activación de BatchV1_1 pasó del 29 de septiembre al 9 de octubre después de que el respaldo de los validadores cayera por debajo del umbral.
• BatchV1_1 mantuvo el respaldo de 30 de 35 validadores de confianza al 25 de septiembre.
• Los Batch agrupan hasta ocho transacciones con una opción de liquidación todo o nada.
La cuenta regresiva de Batch se restablece al 9 de octubre
La actualización insignia de Batch del XRP Ledger ha perdido al menos diez días en su calendario de activación. BatchV1_1, la enmienda que permite a los usuarios agrupar hasta ocho transacciones en una única operación atómica, había estado contando hacia una activación del 29 de septiembre desde el 15 de septiembre, pero el respaldo de los validadores cayó brevemente por debajo del nivel necesario para mantener ese reloj en marcha. Según las reglas de enmienda del libro mayor, un cambio de protocolo debe contar con el respaldo de más del 80% de los validadores de confianza durante dos semanas consecutivas antes de entrar en funcionamiento, y cualquier caída por debajo de esa línea borra el tiempo de espera acumulado, incluso cuando los votos se recuperan en cuestión de horas. El panel de enmiendas del XRPL ahora muestra que BatchV1_1 vuelve a tener 30 de 35 validadores de confianza a partir del 25 de septiembre, restableciendo la activación más temprana posible al 9 de octubre, alrededor de las 14:46 UTC.
Los cambios de Batch afectan a la semántica de ejecución más que a la capacidad bruta de rendimiento. Su opción de todo o nada significa que un comprador que paga por un activo tokenizado puede hacer que el pago y la transferencia del activo se liquiden en una sola operación, de modo que ninguna de las partes de una operación puede completarse por separado: una estructura diseñada directamente para la liquidación de activos tokenizados y el riesgo pago contra entrega. La función también es un segundo intento: la implementación original de Batch fue retirada antes de la activación en la red principal después de que los desarrolladores identificaran una falla crítica en la verificación de firmas, y la versión corregida se envió en agosto con xrpld 3.3.0, el software que ejecuta el ledger. El responsable de ingeniería de RippleX, Ayo Akinyele, ha dicho que algunos proyectos ya se están construyendo pensando en Batch y que la activación acercaría ese trabajo a producción, aunque no ha nombrado socios ni fechas de lanzamiento. El retroceso parece haber durado solo un momento, pero las reglas no dejan margen: el soporte se recuperó rápidamente, el calendario no.
La actualización de delegación también se retrasa
Se descolgó una segunda enmienda en el mismo reloj. PermissionDelegationV1_1, una actualización que permite a un propietario de una cuenta autorizar a otra cuenta para realizar tareas específicas aprobadas sin compartir las claves de firma que controlan sus fondos, perdió su soporte cualificado el 23 de septiembre y lo recuperó un día después. Ese reinicio trasladó su activación más temprana del 5 de octubre al 8 de octubre, aproximadamente a las 21:25 UTC, situando dos de las enmiendas pendientes del ledger encaminadas para entrar en vigor con alrededor de 24 horas de diferencia, siempre que el soporte se mantenga. El registro del panel que revisamos muestra que ambas enmiendas siguieron el mismo patrón: se perdió el soporte, se restauró dentro de un día y el costo completo del calendario fue absorbido por la fecha de activación en lugar de por el propio código.
El mecanismo es lo más importante para las instituciones. Un emisor de tokens en el ledger —una capa 1 diseñada específicamente para pagos— podría asignar la ejecución de pagos y las verificaciones de cumplimiento a cuentas operativas separadas sin exponer nunca la clave maestra que protege su tesorería; la misma separación de funciones que esperan los auditores en las finanzas tradicionales. Combinado con Batch, la delegación abre la puerta a flujos de liquidación atómicos y separados por roles: una cuenta autorizada para entregar activos, otra para liberar el pago, y cada acción se ejecuta o falla junto con la otra. Los validadores, los operadores que verifican transacciones y votan los cambios de la red, efectivamente actuaron como un freno de ambas enmiendas dentro de una sola semana. Eso no es un fallo técnico; es el proceso de activación deliberadamente conservador del ledger funcionando como fue diseñado: cualquier titubeo en el soporte de consenso reinicia una ventana de observación de dos semanas en lugar de forzar un cambio con un respaldo debilitado. Para los participantes del mercado, el efecto práctico es una ventana de mediados de octubre más comprimida en la que dos cambios de gobernanza podrían entrar en vigor de forma consecutiva, cada uno reconfigurando cómo funcionan la liquidación y la autorización de cuentas en una red cuya actividad está anclando cada vez más el ecosistema XRP.
El 8 de octubre y el 9 de octubre son las fechas que importan
Nuestra lectura: el doble reinicio es menos un retroceso que una prueba de que la gobernanza del ledger intercambia velocidad por previsibilidad, y el impacto directo en el precio de XRP debería ser mínimo. Ambas enmiendas ya se incluyen en xrpld 3.3.0, así que los operadores de nodos no necesitan ninguna acción nueva más allá de mantener el soporte estable. Si el consenso se mantiene, el 8 y el 9 de octubre son las fechas a vigilar: Batch más delegación acercan la red a la liquidación atómica y separada por roles que exigen los flujos de activos tokenizados y PayFi. La demanda institucional ha continuado durante el retraso: recientemente, las entradas al ETF de XRP estuvieron lideradas por Bitwise, con 9,91 millones de dólares en compras diarias, mientras que los datos de 30 días muestran que los agentes de IA en XRPL están desplazando la preferencia de liquidación hacia Ripple USD, una recordatorio de que el relato de pagos del ledger sigue evolucionando independientemente de las fechas de actualización.