El pasado 15 de junio de 2026, la XRP Ledger Foundation publicó la versión 3.2.0 del software de referencia del protocolo, xrpld. A fecha de hoy, 10 de julio, la red presenta un cuadro que merece un análisis detallado: el 89% de los validadores de la Unique Node List (UNL) predeterminada —31 de 35— ya ejecutan la nueva versión.
Sin embargo, la enmienda asociada a esta actualización, fixCleanup3_2_0, apenas cuenta con el respaldo de 19 de esos 35 validadores (≈54%), muy lejos del 80% necesario para su activación definitiva.
Esta divergencia no es un fallo del sistema. Es el sistema funcionando exactamente como fue diseñado. Pero invita a una reflexión forzosa sobre la gobernanza de las redes descentralizadas y, en particular, sobre la frágil relación entre la adopción de software y la voluntad política de los actores que sostienen la red.
Dos procesos, una misma red
La confusión actual proviene de una premisa errónea que se repite en foros y redes sociales: asumir que instalar un nuevo binario es equivalente a votar a favor de sus cambios. En el XRP Ledger, la actualización del software y la activación de una enmienda son procesos independientes que operan en planos completamente distintos.
El primero es puramente técnico: los operadores de nodos descargan, compilan y ejecutan el nuevo binario. Esto es voluntario y no requiere consenso más allá de la decisión individual de cada operador. El segundo es gobernanza: los validadores deben emitir un voto explícito a favor de cada enmienda contenida en ese software.
Una enmienda no se activa automáticamente por el mero hecho de que el código esté presente en el disco duro del validador; requiere que más del 80% de los validadores de la UNL voten afirmativamente y mantengan ese apoyo durante dos semanas consecutivas.
Este diseño no es caprichoso. Responde a una lógica de seguridad bien documentada: separar la capacidad técnica de implementar un cambio de la voluntad política de adoptarlo. Un validador puede tener el software instalado y, sin embargo, votar en contra de una enmienda porque considera que no ha sido suficientemente auditada, porque afecta a sus intereses operativos o simplemente porque aún no ha consolidado su decisión. El proceso de consenso de XRP Ledger exige, por tanto, una supermayoría no solo técnica, sino también política.
La brecha entre validadores y nodos generales
Más allá de la votación de la enmienda, existe una segunda brecha que merece atención: la que separa a los validadores de la UNL del resto de los nodos de la red. Mientras que los primeros han adoptado mayoritariamente v3.2.0, solo el 43% de los aproximadamente 833 nodos activos han realizado la actualización. El 51% restante sigue ejecutando v3.1.3, lo que revela una adopción fragmentada en la capa de infraestructura base.
Esta disparidad no es inusual en los ciclos de actualización del XRP Ledger, pero la magnitud de la diferencia sugiere que una parte significativa de los operadores está adoptando una estrategia de espera deliberada. No actualizan hasta que la enmienda asociada haya sido aprobada.
Desde una perspectiva de gestión de riesgos operativos, es comprensible: invertir tiempo y recursos en una actualización cuyos cambios fundamentales aún no han recibido el respaldo necesario resulta prematuro y costoso.
Sin embargo, esta estrategia conlleva sus propios riesgos sistémicos. Cuando la enmienda fixCleanup3_2_0 finalmente se active —si es que lo hace—, los nodos que aún ejecuten versiones anteriores quedarán en un estado de amendment-blocked. En ese estado, el servidor deja de poder determinar la validez de un ledger, procesar transacciones o participar en el consenso.
No es un bloqueo permanente, pero implica una interrupción del servicio hasta que el operador realice la migración forzosa, generando una ventana de inestabilidad para los servicios que dependen de esos nodos específicos.
¿Qué contiene realmente fixCleanup3_2_0?
La enmienda no es un cambio cosmético ni una modificación controversial de la economía del token. fixCleanup3_2_0 agrupa correcciones estrictamente técnicas para funcionalidades introducidas en ciclos anteriores: ajustes de precisión y redondeo para Single Asset Vaults y el Lending Protocol, correcciones de invariantes para el permissioned DEX, validación de cantidades no canónicas en Multi-Purpose Tokens, y una nueva comprobación para evitar que cuentas eliminadas dejen artefactos accesibles en el estado global.
Adicionalmente, retira más de 30 enmiendas que llevaban activas más de dos años, limpiando el código base de legados obsoletos. Es, en definitiva, una actualización de mantenimiento que resuelve problemas conocidos y reduce la deuda técnica acumulada de la red.
Que una enmienda de este perfil —técnicamente necesaria y no controvertida en su contenido— tenga dificultades para alcanzar el quórum es un dato que merece ser interpretado como un síntoma de fatiga o cautela extrema en la gobernanza actual.
El voto de Ripple y la UNL
Ripple, cuyos fundadores crearon el XRP Ledger, ha votado a favor de la enmienda. También lo han hecho Bitso, Peersyst y un grupo de validadores universitarios. Sin embargo, 19 votos afirmativos sobre 35 no son suficientes; se necesitan al menos 28 para alcanzar la supermayoría reglamentaria. La UNL de 35 validadores no es un órgano monolítico ni está sujeta a una disciplina de voto única.
Cada operador tiene su propia evaluación de riesgos, sus propios incentivos comerciales y, en muchos casos, sus propias obligaciones fiduciarias con los usuarios que dependen de su infraestructura.
Que una enmienda no alcance el 80% no significa necesariamente que haya oposición activa; puede significar simplemente que hay indecisión, falta de coordinación o prioridades divergentes entre los operadores. El proceso está diseñado para requerir una supermayoría precisamente para evitar que una minoría activa imponga cambios a una mayoría pasiva.
Pero el reverso de esta medalla es que una minoría pasiva —validadores que no votan, que retrasan su decisión o que no han configurado su servidor para emitir un voto automático— puede bloquear indefinidamente una actualización. El sistema no distingue entre un «no» activo y un «no» por omisión, y esta asimetría es la que actualmente mantiene el estancamiento.
Para los operadores de infraestructura, el mensaje derivado de este episodio es claro y debe ser internalizado. La actualización del software es necesaria pero no suficiente; la gobernanza del XRP Ledger exige participación activa y sostenida en las votaciones, no solo una actualización técnica pasiva.
Los nodos que esperen a que la enmienda se active para actualizar corren el riesgo de quedar temporalmente fuera de la red, en un momento en que la actividad transaccional podría estar en su punto más alto.
Para los desarrolladores y proponentes de cambios, el estancamiento de fixCleanup3_2_0 plantea una pregunta estructural más amplia: ¿está el proceso de enmiendas del XRP Ledger volviéndose excesivamente conservador y lento para las correcciones de mantenimiento? La barrera del 80% durante dos semanas es intencionalmente alta, y esa es una fortaleza del sistema frente a cambios radicales.
Pero si las enmiendas de mantenimiento —las que corrigen errores y mejoran la estabilidad sin alterar la economía del protocolo— encuentran resistencia o indiferencia, el costo de la gobernanza podría empezar a pesar sobre la evolución técnica de la red, desincentivando futuras propuestas de optimización.
El estado actual del XRP Ledger no es un fracaso
Es una ilustración rigurosa de cómo funciona la gobernanza descentralizada en la práctica: con ruido, con retrasos operativos, con actores que toman decisiones basadas en sus propios incentivos y con procesos que exigen paciencia, pero también vigilancia activa.
La adopción del software por parte de los validadores ha superado el umbral técnico; la votación de la enmienda, no. Esa discrepancia no es un problema que deba «resolverse» con prisas o parches de emergencia; es el síntoma de un ecosistema que aún está encontrando el equilibrio entre la eficiencia técnica y la prudencia gobernanza.
La actualización v3.2.0 ya está en los servidores, pero el verdadero consenso para activarla sigue estando en manos de unos pocos validadores que, por ahora, se mantienen al margen.
Para los observadores del sector y los gestores de riesgos, la lección operativa es que en las redes descentralizadas, la actualización del código es solo el primer paso. El verdadero consenso —el que cambia las reglas de validación de la red— requiere algo más que instalar un binario.
Requiere que los actores con poder de veto ejerzan ese poder de manera deliberada y coordinada. Y eso, como muestra el caso de fixCleanup3_2_0, no siempre ocurre al mismo ritmo que la descarga de un archivo.
