Puntos Clave de la Noticia:
- El mecanismo introduce un objeto de registro llamado ReservedTxns que almacena un índice con un límite estricto de hasta 32 identificadores de transacciones por bloque.
- Los usuarios que deseen asegurar un espacio de ejecución prioritario deberán registrar una transacción tipo TxnReserve con una tarifa mínima equivalente al doble del costo estándar de la red.
- La ventana temporal para aplicar la reserva está restringida a un máximo de 16 ledgers hacia el futuro en relación con el bloque analizado en tiempo real.
El cofundador de XRP Ledger y CTO Emérito de Ripple, David Schwartz, presentaron una propuesta técnica para mitigar los riesgos de manipulación de transacciones en la red. El mecanismo introduce una infraestructura de reserva de transacciones diseñada específicamente para bloquear las actividades de front-running y los ataques de tipo sandwich dentro del exchange descentralizado (DEX) nativo y los creadores de mercado automatizados (AMM) de la plataforma. La iniciativa surge como respuesta directa a las preocupaciones analíticas sobre la visibilidad de las operaciones prioritarias en el libro de órdenes.
Concerns have been raised about the possibility of front running or transaction sandwich attacks on XRPL payments and offer crossing.
For the reasons I've explained, I'm not that concerned about this issue. But I have a proposal for a fairly simple scheme that would eliminate… https://t.co/lnhTv1bhBK
— David 'JoelKatz' Schwartz (@JoelKatz) June 29, 2026
Funcionamiento técnico del sistema antibloqueo en XRPL
El esquema diseñado por Schwartz plantea dos componentes principales en la estructura de consenso del protocolo. El primer elemento, el objeto de registro ReservedTxns, guarda de forma predeterminada el número de secuencia objetivo del ledger junto al vector de transacciones autorizadas. El reporte técnico indica que, una vez que el bloque específico entra en ejecución, todas las operaciones listadas que formen parte del conjunto de consenso reciben prioridad absoluta, procesándose antes de cualquier otra transferencia comercial en la red.
El segundo componente se integra mediante el tipo de transacción TxnReserve. Esta modalidad faculta a los operadores financieros a reclamar una ranura de ejecución mediante el pago indexado de una tarifa regulada por el dinamismo de la red. De acuerdo con las especificaciones técnicas provistas, para evitar que el sistema sea utilizado como una herramienta de saturación maliciosa o spam, el software del servidor de XRPL retiene las transacciones reservadas y restringe su divulgación masiva. El sistema libera los datos únicamente en la proximidad inmediata del cierre del ledger anterior, comprimiendo la ventana de visibilidad previa a la validación.
El problema del front-running y el debate de la gobernanza
La vulnerabilidad señalada originalmente por la firma de análisis XRPresso.io radica en las transacciones pendientes que permanecen en la cola pública de XRPL antes del cierre de cada bloque. Debido a que el orden de ejecución en este ecosistema se rige por fórmulas deterministas basadas en hashes, agentes de mercado con nodos de alta conectividad pueden enviar transacciones de forma repetitiva para posicionarse de manera ventajosa frente a un intercambio minorista grande.
Aunque Schwartz estipula que todos los nodos cuentan con el mismo acceso técnico a esta cola pública de datos y que el riesgo real requiere un escenario complejo de baja y alta liquidez simultánea, la propuesta busca dotar al sistema de una capa de integridad económica rígida.
Cabe destacar que este planteamiento se encuentra actualmente bajo evaluación comunitaria y no ha adquirido el estatus de enmienda oficial. En el diseño de gobernanza de XRP Ledger, cualquier modificación estructural requiere el voto favorable de una supermayoría de validadores de la red antes de su despliegue definitivo en la mainnet.
