Por Canuto  

El XRP Ledger propone una enmienda para impedir que ciertas cuentas autorizadas a quemar tokens puedan también acuñarlos sin el permiso específico del emisor. La medida recibía el apoyo de 33 de 35 validadores consultados al 2 de noviembre, aunque su activación todavía dependía de mantener el respaldo requerido durante 14 días consecutivos.
***

  • La enmienda busca cerrar una brecha que podría permitir a cuentas con permiso PaymentBurn crear activos emitidos sin contar con PaymentMint.
  • El 2 de noviembre, 33 de 35 validadores de confianza apoyaban la propuesta; el 4 de noviembre era la fecha más temprana posible para activarla.
  • La actualización también corrige cálculos de bóvedas y registros de préstamos que podían reflejar pagos vencidos antes de su fecha contractual.

El XRP Ledger (XRPL) prepara una actualización de seguridad para evitar que ciertas cuentas autorizadas a destruir tokens puedan crear activos emitidos sin aprobación del emisor. La enmienda, incluida en la versión 3.4.0 del software, también incorpora correcciones para cálculos de bóvedas y registros de préstamos, aunque al 2 de noviembre la red todavía no la había activado.

La propuesta aborda un problema en la interacción entre permisos distintos: PaymentBurn permite quemar tokens, mientras que PaymentMint corresponde a la acuñación. Una cobertura de Gate sobre la advertencia para emisores señala que, bajo ciertas condiciones, el permiso PaymentBurn podría permitir crear tokens emitidos adicionales sin contar con PaymentMint. La situación puede ser relevante para emisores de stablecoins que delegan tareas de reembolso en proveedores de pagos.

La enmienda busca separar los permisos de quema y acuñación

En XRPL, las cuentas pueden recibir permisos específicos para operar con activos emitidos, incluidos stablecoins y tokens multipropósito. La vulnerabilidad señalada no implica que cualquier cuenta pueda generar activos a voluntad, sino que ciertas cuentas con el permiso PaymentBurn podrían, bajo condiciones determinadas, acuñar tokens pese a no contar con la autorización PaymentMint que corresponde a esa acción.

La distinción importa porque quemar y acuñar cumplen funciones diferentes en la gestión de un activo. Un proveedor de pagos podría recibir autorización para destruir tokens cuando procesa reembolsos de clientes, pero esa tarea no debería concederle, por sí misma, capacidad para crear nuevas unidades; la enmienda pretende impedir precisamente que un permiso se extienda más allá de su propósito.

La documentación del XRP Ledger recomienda no conceder el permiso delegado PaymentBurn hasta que la corrección esté activa. Esa advertencia se refiere al riesgo asociado con la combinación de permisos descrita y no equivale a afirmar que se haya producido una acuñación no autorizada o que todos los activos emitidos estén comprometidos.

La enmienda busca cerrar esa brecha en activos creados sobre el libro mayor, como stablecoins y tokens multipropósito. El mecanismo afectado no determina la oferta de XRP, de modo que el problema descrito concierne a otros activos emitidos y a la gestión de permisos, no a la creación del token nativo de la red.

El respaldo de validadores todavía debía sostenerse

El 2 de noviembre, 33 de los 35 validadores de confianza registrados en el rastreador de enmiendas XRPLWin apoyaban la propuesta. Ese respaldo superaba el mínimo de 29 validadores de los 35 requerido para alcanzar más del 80%, pero la cifra por sí sola no bastaba: el apoyo debía mantenerse durante 14 días consecutivos.

La fecha más temprana de activación pasó a ser el 4 de noviembre, según el estado reportado para la propuesta. La red aún no había implementado el cambio al 2 de noviembre, por lo que esa fecha representaba una posibilidad sujeta a que continuara el respaldo necesario y concluyera el período de aprobación establecido.

Los desarrolladores habían esperado inicialmente que la actualización se activara el 23 de octubre, después del período de votación. Sin embargo, el apoyo descendió brevemente a 26 validadores el 21 de octubre y ese retroceso reinició la cuenta de 14 días, lo que desplazó el calendario y explica por qué la fecha más temprana se movió a noviembre.

El episodio muestra que el proceso de enmiendas del XRPL no depende solo de alcanzar una mayoría en un momento concreto. La regla de respaldo sostenido obliga a que los validadores mantengan su apoyo durante un plazo definido, de modo que una caída temporal puede alterar la fecha prevista incluso cuando la propuesta vuelve a reunir suficientes votos.

La actualización también corrige errores de bóvedas y préstamos

El paquete de cambios no se limita a los permisos de tokens. También aborda errores en los cálculos relacionados con depósitos, retiros y recuperación de activos dentro de bóvedas, con el objetivo de mejorar el manejo de transacciones en mecanismos que incluyen creadores de mercado automatizados y sistemas de préstamos.

Otra corrección busca evitar que determinados registros de préstamos muestren pagos vencidos antes de que llegue la fecha límite establecida por el contrato. El problema descrito afecta a la representación de obligaciones en esos registros, y la enmienda pretende alinear el estado mostrado con los plazos acordados, en lugar de señalar anticipadamente un incumplimiento.

Los desarrolladores incorporaron fixCleanup3_4_0 en la versión 3.4.0 de XRPL, lanzada en septiembre. La publicación oficial de esa versión indica que los pagos PaymentBurn que cruzan un saldo cero quedan rechazados. La publicación del software no significaba que la enmienda ya estuviera activa en la red: para desplegarla, todavía debía completar el procedimiento de aprobación de validadores y sostener el nivel de respaldo requerido.

Mientras tanto, otras propuestas relacionadas con préstamos y con la Bóveda de Activo Único seguían en revisión. Al momento descrito, la enmienda de préstamos contaba con 19 votos y la de la bóveda con 21; ambas necesitaban apoyo adicional antes de iniciar sus propios períodos de aprobación de 14 días, por lo que permanecían separadas del cambio de permisos aquí analizado.

Qué cambia para emisores y operadores

Para los emisores de stablecoins, el punto central es que delegar una tarea operativa no debería conceder facultades adicionales para emitir unidades. La propuesta busca que los controles distingan con mayor claridad entre destruir tokens durante un reembolso y crear nuevos activos, reduciendo el riesgo de que una autorización limitada tenga efectos que el emisor no pretendía conceder.

La información disponible describe una vulnerabilidad potencial y una respuesta de software, pero no reporta que un socio haya explotado el fallo ni que se hayan acuñado tokens sin aprobación. Mantener esa diferencia es importante: una alerta sobre permisos justifica medidas preventivas, aunque no constituye por sí sola evidencia de pérdidas, incidentes o daños a usuarios.

La activación dependía de que los validadores conservaran durante 14 días consecutivos un respaldo superior al 80%, después del reinicio causado por la caída de votos del 21 de octubre. Por eso, el 4 de noviembre figuraba como la fecha más temprana posible y no como una confirmación de que la red ya hubiera completado la actualización.

La enmienda reúne, así, cambios de seguridad y ajustes de funcionamiento para activos emitidos, bóvedas y registros de préstamos. El siguiente paso era observar el resultado del proceso de validación y la aprobación de las propuestas separadas, sin confundir las correcciones incluidas en la versión 3.4.0 con su activación efectiva en el XRP Ledger.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados