Enmienda Batch de XRP Ledger: por qué el 29 de septiembre de 2026 es un plazo firme para los operadores de nodos

El 29 de septiembre de 2026 a las 14:06:41 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 29 de septiembre. 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 29 de septiembre

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 29 de septiembre 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 el 18 de septiembre de 2026 hacia las 00:35 UTC a través de un nodo público de XRP Ledger (índice de registro 107058182, respuesta HTTP 200). El campo Majorities contenía exactamente una entrada: la enmienda con el identificador 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 y el valor CloseTime 842796401.

El cómputo del tiempo de XRP Ledger arranca el 1 de enero de 2000. Al convertir ese valor resulta el 15 de septiembre de 2026, 14:06:41 UTC como inicio del plazo. Dos semanas después queda el 29 de septiembre de 2026, 14:06:41 UTC. La contraprueba mediante la consulta feature en ese mismo nodo devolvió 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.

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.0, publicada el 17 de septiembre de 2026; antes estaba la 3.3.0 del 6 de agosto de 2026 (ambas fechas proceden de las fechas de publicación del archivo oficial de código fuente, consultado el 18 de septiembre de 2026).

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í. Si allí figura false, solo ayuda una actualización, y ha de hacerse antes del 29 de septiembre.

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 29 de septiembre decae. 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 29 de septiembre 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 antes del 29 de septiembre. Si allí figura supported: false, actualiza el software. 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.

(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.)