Enmienda Batch de XRP Ledger aplazada al 9 de octubre de 2026 como muy pronto: qué deben revisar los operadores de nodos

Actualizado el 27 de septiembre de 2026: la primera versión de este artículo, del 18 de septiembre de 2026, daba el 29 de septiembre de 2026, 14:06:41 UTC como fecha de activación. Esa fecha ya no es válida. Entretanto, el apoyo de los validadores a BatchV1_1 cayó por debajo del umbral y el 25 de septiembre se formó una nueva mayoría, con lo que el plazo de dos semanas empezó de nuevo. El objeto Amendments del registro validado (índice de registro 107269984) registra la mayoría desde el 25 de septiembre de 2026, 14:46:02 UTC. La fecha de activación más temprana es, por tanto, el 9 de octubre de 2026, 14:46:02 UTC, siempre que la mayoría se mantenga. Desde el 25 de septiembre de 2026, 14:12:51 UTC, el registro también cuenta el plazo de la corrección fixBatchV1_2, que llegó con xrpld 3.4.1 (notas de la versión del 25 de septiembre de 2026). Si operas un nodo propio, necesitas por tanto la versión 3.4.1. Las secciones siguientes reflejan este estado.

Como muy pronto el 9 de octubre de 2026 a las 14:46:02 UTC, una actualización del protocolo se activará por sí sola en XRP Ledger: la enmienda Batch, cuya denominación interna es BatchV1_1. Si mantienes XRP en un exchange o en una cartera custodiada, no tienes que hacer nada. Si operas un nodo propio, o ejecutas un servicio contra un nodo propio, esta fecha es un plazo firme: a partir de ese momento tu servidor queda fuera de la red.

Este texto explica qué cambia la enmienda, de dónde procede la fecha, cómo comprobar el estado por tu cuenta y qué reservas pesan sobre ese plazo. Todas las cifras de este artículo proceden del registro validado y de la documentación del protocolo, no de anuncios públicos.

Qué es una enmienda en XRP Ledger y por qué no necesita una fecha de apagado

Una enmienda es un cambio en las reglas del protocolo de XRP Ledger que votan los validadores de confianza de la red, en lugar de que una empresa fije su fecha. Justo ahí se distingue el procedimiento de un hard fork clásico con una altura de bloque anunciada: no hay una entrada de calendario que alguien fije, sino una condición que la red cumple o no cumple.

La regla está recogida en la documentación del protocolo y es breve. Una enmienda necesita la aprobación de más del 80 % de los validadores de confianza, y debe mantener esa aprobación de forma ininterrumpida durante dos semanas. Solo entonces se activa. Si la aprobación baja del umbral durante esas dos semanas, aunque sea de forma pasajera, el recuento vuelve a empezar desde cero.

Para ti como lector, eso significa dos cosas. Primero, un plazo así es comprobable, porque figura en el registro y no en una nota de prensa. Segundo, no es inamovible mientras corren las dos semanas. Ambos puntos son el núcleo del asunto en el plazo del que se habla aquí.

Qué cambia técnicamente la enmienda Batch BatchV1_1

Batch es un nuevo tipo de transacción que agrupa varias transacciones individuales en un paquete que se procesa en conjunto. Según la referencia del protocolo, un paquete reúne como mínimo dos y como máximo ocho transacciones internas, que además pueden proceder de cuentas distintas. Hasta ahora, XRP Ledger obligaba a enviar cada paso por separado y a confiar, en cada uno de ellos, en que saliera adelante.

La ganancia práctica está en la garantía de ejecución. Quien hoy envía dos pasos seguidos, por ejemplo una autorización y después un intercambio, asume el riesgo de que el primero salga bien y el segundo falle. Un paquete cierra esa brecha, porque la red conoce la regla de procesamiento y la hace cumplir.

¿Tengo que hacer algo si mis XRP están en un exchange?

No. Es la situación más frecuente y la menos aparatosa. Si tus XRP están en una plataforma de negociación o en una cartera custodiada, el proveedor es quien opera la infraestructura y la obligación de actualizar le corresponde a él. No tienes que mover saldos, ni vender, ni cambiar de dirección. Mover posiciones con prisas por una fecha del protocolo genera sobre todo comisiones y, en caso de duda, una operación con efectos fiscales que nadie necesitaba.

La ocasión sigue sirviendo para un inventario tranquilo que nada tiene que ver con el plazo. ¿Sabes en qué proveedor está cada parte de tu saldo, cuánto cuesta allí la comisión de retirada y si ese proveedor está supervisado en la Unión Europea? Al margen de la fecha del protocolo, esas preguntas pesan más.

Qué revisar si custodias tú mismo tus XRP

También en la custodia propia el caso suele ser sencillo. Una cartera hardware guarda tu clave privada y firma transacciones con ella; por regla general se dirige a la red a través de los servidores del proveedor de la cartera. Las claves en sí nunca se ven afectadas por una enmienda, porque una enmienda cambia las reglas de la cadena, no tu dirección ni tu acceso.

Lo que sí puedes hacer es mantener actualizado el software con el que accedes a la cartera y comprobar una vez antes del plazo que tus palabras de recuperación están donde supones. Es higiene básica y conviene hacerlo con independencia del 9 de octubre. Si todavía dudas al elegir dispositivo, te ayuda nuestra comparativa de carteras hardware.

Amendment-blocked: qué le pasa a un nodo xrpld desactualizado el 9 de octubre

Amendment-blocked es el estado en el que cae un servidor que desconoce una regla del protocolo ya activada. La documentación del protocolo describe las consecuencias sin ambigüedad: un servidor bloqueado ya no puede validar registros, ni enviar o procesar transacciones, ni participar en el consenso, ni votar sobre futuras enmiendas.

La frase decisiva está justo al lado: la configuración de voto de un servidor no influye en ello. Quien haya configurado su xrpld para votar en contra de la enmienda queda tras la activación igual de bloqueado que quien votó a favor. Se bloquea a aquel a quien le falta el código capaz de entender la nueva regla. Contra una decisión mayoritaria ya activada no se puede seguir funcionando.

El servidor no se cae durante el proceso ni lanza un mensaje de error llamativo. Sigue respondiendo, solo que ya no con datos válidos de la cadena en curso. Eso es precisamente lo que hace peligroso este estado para los servicios que consultan en segundo plano un nodo propio: la aplicación parece sana y entrega un estado de datos que se ha quedado parado.

De dónde sale la fecha del 9 de octubre de 2026 y cómo se calcula

El plazo está calculado, ni deducido ni estimado. En el registro validado hay un objeto que lleva el estado de todas las enmiendas. Contiene un campo Majorities, y allí se anota, para cada enmienda que ha alcanzado el umbral, el momento a partir del cual corre el plazo de dos semanas.

Esta redacción consultó ese objeto por primera vez el 18 de septiembre de 2026 (índice de registro 107058182). El campo Majorities contenía entonces exactamente una entrada: la enmienda con el identificador 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 y el valor CloseTime 842796401. En la nueva consulta del 27 de septiembre de 2026 hacia las 12:01 UTC (índice de registro 107269984), el mismo identificador mostraba el valor 843662762. La mayoría había caído entretanto y se había formado de nuevo.

El cómputo del tiempo de XRP Ledger arranca el 1 de enero de 2000. El valor antiguo corresponde al 15 de septiembre de 2026, 14:06:41 UTC, y habría llevado a la activación el 29 de septiembre. El nuevo valor da el 25 de septiembre de 2026, 14:46:02 UTC como inicio del plazo. Dos semanas después queda el 9 de octubre de 2026, 14:46:02 UTC. El 27 de septiembre, la contraprueba mediante la consulta feature siguió devolviendo para el mismo identificador el nombre BatchV1_1 junto con los valores enabled: false y supported: true. La enmienda es, por tanto, conocida y admitida por la red, pero todavía no está activa. Desde el 25 de septiembre de 2026, 14:12:51 UTC, el mismo objeto recoge también la corrección fixBatchV1_2 (identificador que empieza por 14A2B45E48A4), activable como muy pronto el 9 de octubre de 2026, 14:12:51 UTC.

Cómo comprobar tú mismo el estado de la enmienda

No necesitas un nodo propio para ello. Un punto de acceso público de XRP Ledger responde a la pregunta con una sola consulta. Quien se maneje con la línea de comandos envía una consulta feature con el identificador citado arriba a un nodo público y lee tres campos de la respuesta:

• enabled: si aquí figura false, la enmienda todavía no está activa. En cuanto el valor salta a true, la activación se ha producido.
• supported: si aquí figura true, el software del nodo consultado ya conoce la regla. Si figura false, será justamente ese nodo el que quede bloqueado en la activación.
• majority: la marca de tiempo a partir de la cual corre el plazo de dos semanas. Si ese campo vuelve a desaparecer, la mayoría ha caído y la cuenta atrás se ha reiniciado.

Ese tercer punto es justamente el motivo por el que conviene mirar el estado otra vez poco antes del plazo, en vez de apuntar la fecha y darla por zanjada. Para el nodo propio vale el mismo camino con una diferencia importante: lanza la consulta feature contra tu servidor, no contra uno ajeno. Solo la respuesta de tu propio nodo te dice algo sobre tu propio nodo.

Qué versión del software trae la nueva regla

El software de servidor de XRP Ledger se llama xrpld y se publica como software abierto. La versión actual es la 3.4.1, publicada el 25 de septiembre de 2026 con la corrección fixBatchV1_2, que rechaza las transacciones internas de un Batch con un envoltorio incorrecto. Antes estaban la 3.4.0 del 17 de septiembre y la 3.3.0 del 6 de agosto de 2026 (fechas de las notas de la versión 3.4.1 y del archivo oficial de código fuente). Según las notas de la versión, un nodo sin la 3.4.1 queda bloqueado por enmienda en cuanto se active fixBatchV1_2.

Copiar un número de versión de un artículo sigue siendo el peor camino. La información fiable te la da tu propio servidor a través del campo supported: responde a la pregunta de si el software en marcha conoce realmente la regla. Qué versión creas estar ejecutando no cuenta aquí. Consúltalo para BatchV1_1 y para fixBatchV1_2. Si en alguno de los dos figura false, solo ayuda una actualización a la 3.4.1, y ha de hacerse antes del 9 de octubre.

Por qué la fecha está sujeta a reserva

El plazo de dos semanas corre mientras la aprobación se mantenga por encima del 80 %. Si cae por debajo, el contador se reinicia y el 9 de octubre decae, como ya ocurrió con el 29 de septiembre calculado en un principio. Esa cláusula no es un adorno teórico; es el mecanismo de seguridad incorporado al procedimiento. Deja a los validadores la posibilidad, hasta el último momento, de detener un cambio si entretanto aparece un problema.

Para tu planificación se deriva de ello una postura sencilla. Trata el 9 de octubre como el plazo para el que te preparas, y da su llegada por incierta. Quien actualiza un nodo no pierde nada si la cuenta atrás se reinicia. Quien aplaza la actualización porque la fecha aún podría caerse se queda, en el caso contrario, con un sistema aislado de la cadena.

Los cuatro modos de un paquete Batch y qué significan en el día a día

Al enviarse, un paquete recibe un modo que determina cómo trata la red los fallos. La referencia del protocolo menciona cuatro:

• AllOrNothing: cada una de las transacciones del paquete tiene que salir bien. Si una falla, falla el paquete entero. Es el modo para secuencias que solo tienen sentido completas.
• OnlyOne: en cuanto la primera transacción sale bien, las restantes se omiten. Permite enviar alternativas de las que solo una debe surtir efecto.
• UntilFailure: las transacciones se ejecutan por orden hasta que una falla; todo lo posterior se descarta. Encaja con secuencias que se apoyan unas en otras.
• Independent: todas las transacciones se procesan con independencia unas de otras, fallen o no algunas. Es la agrupación pura, sin encadenamiento.

Como titular rara vez fijarás tú mismo estos modos. La diferencia se vuelve visible allí donde las aplicaciones la aprovechan: en interfaces de cartera que reúnen varios pasos en una sola confirmación y en aplicaciones de negociación, donde una secuencia ejecutada a medias era hasta ahora el caso más incómodo.

Qué deben aclarar ahora servicios, proveedores de carteras y procesadores de pago

Queda afectado todo el que accede a XRP Ledger mediante infraestructura propia y no a través de un proveedor ajeno. Entran ahí los servicios de pago, las aplicaciones de negociación, las herramientas de contabilidad con consulta propia y cualquier cartera cuyo proveedor opere un nodo. Para ese grupo hay tres preguntas que responder antes del plazo.

1. ¿La consulta va contra un nodo propio o contra un punto de acceso ajeno? Con un punto de acceso ajeno la obligación recae en su operador, y conviene preguntarle a él antes que actuar por cuenta propia.
2. ¿Informa tu propio nodo del valor supported: true para BatchV1_1? Si no lo hace, toca actualizar, con la antelación habitual para pruebas y ventana de mantenimiento.
3. ¿Se notaría siquiera en tu supervisión un estado de datos detenido? Un nodo bloqueado sigue respondiendo. Una supervisión que solo comprueba la disponibilidad no se entera de nada. Quien vigila la distancia entre el último registro validado y la hora actual lo detecta de inmediato.

La experiencia dice que todo se juega en la tercera pregunta. Una caída disfrazada de funcionamiento normal se descubre tarde, y entretanto los apuntes y las pantallas siguen trabajando con datos viejos.

Cómo encaja esta fecha en la serie de enmiendas anteriores

El procedimiento es rutina en XRP Ledger y se repite varias veces al año. La última vez describimos, el 9 de septiembre de 2026, la activación de la enmienda anterior; quien quiera releer el desarrollo desde el principio lo encuentra en nuestro artículo sobre qué puntos revisar en cartera, nodo y posición. La mecánica es la misma, solo que esta vez van unidas a ella una fecha concreta y una condición abierta.

Para situar la red en su conjunto, la mirada a lo que se construye encima sigue siendo más reveladora que cualquier paso aislado del protocolo. Un ejemplo de febrero de 2026 es la stablecoin en euros de Société Générale, emitida sobre XRP Ledger. Aplicaciones así son la razón por la que se demandan paquetes de transacciones con ejecución garantizada: quien automatiza flujos de pago no quiere cadenas ejecutadas a medias.

Enmienda Batch de XRP Ledger: qué te llevas de todo esto

1. Si tus XRP están en un proveedor, no haces nada. Aprovecha el plazo, como mucho, para revisar con calma si ese proveedor te sigue encajando: el panorama de los mejores exchanges de criptomonedas pone comisiones y vías de retirada una al lado de la otra.
2. Si custodias tú mismo, revisa acceso y recuperación, no el protocolo. Tus claves no se ven afectadas por una enmienda. Qué dispositivo sirve para ello lo muestra la comparativa de carteras hardware.
3. Si operas un nodo propio, lanza la consulta feature para BatchV1_1 y fixBatchV1_2 antes del 9 de octubre. Si en alguno de los dos figura supported: false, actualiza a xrpld 3.4.1. Quien además necesite una visión de conjunto de sus posiciones y de su registro fiscal encontrará las herramientas entre el software fiscal de criptomonedas y los seguidores de cartera.

Las fuentes primarias de este artículo: la descripción del procedimiento de enmienda y la referencia de protocolo de la transacción Batch, ambas en la documentación oficial de XRP Ledger.

(Actualizado a 27 de septiembre de 2026, primera versión del 18 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)