. @GMX_SOL Actualización Semanal [2025-08-10] ¡Hola a todos! Esta semana logramos lo siguiente: - Completamos el despliegue en mainnet de los programas v0.7. Las tarifas de préstamo ahora pueden acuñar GT, lo que permite que GT se utilice para incentivar OIs. La información de seguridad para los programas ahora se puede ver en mainnet a través del explorador. - Se agregó metadatos de token para los tokens GLV en mainnet, que ahora se pueden ver en el explorador y en las billeteras; la verificación de estos tokens está en progreso. - Desplegamos un lote de mercados RWA junto con un GLV correspondiente, pero identificamos varios problemas nuevos: - Si algún mercado en un GLV está cerrado, todas las operaciones de GLV que involucren ese mercado (especialmente depósitos y retiros) fallan. - La detección de mercados cerrados en la versión actual es demasiado estricta; algunos mercados con inactividad a corto plazo podrían ser marcados erróneamente como cerrados. Esto se ha corregido y se ha enviado para auditoría, con la corrección esperada para ser desplegada la próxima semana. Por ahora, solo se habilitan los mercados que creemos que no están afectados. - Investigamos soluciones para mejorar el soporte RWA, abordando los siguientes problemas conocidos: - Para prevenir la creación de órdenes cuando un mercado RWA está cerrado, necesitamos introducir un flag is_market_open por mercado, que se comporte de manera similar al flag ADL, actualizado por el keeper. - Además de bloquear la creación de órdenes, se deberían introducir parámetros temporales en los estados de mercado cerrado para reducir el riesgo de LP y traders, por ejemplo, aumentando las tarifas de préstamo y las proporciones mínimas de colateral. - Para evitar problemas causados por la recolección tardía de tarifas de financiamiento (que pueden llevar a deudas de mercado), se debería permitir a los keepers ejecutar liquidaciones cuando los mercados están cerrados. Actualmente, esto se mitiga parcialmente aumentando las proporciones mínimas de colateral. - Las verificaciones de liquidación actuales permiten que las ganancias compensen las tarifas, lo que puede resultar en posiciones altamente rentables acumulando grandes tarifas de financiamiento. En los mercados RWA, donde las brechas de precio al abrir el mercado son comunes, las altas ganancias no realizadas pueden desaparecer instantáneamente, exponiendo repentinamente grandes tarifas de financiamiento y causando colateral insuficiente, lo que puede llevar a deudas de mercado. Proponemos introducir un nuevo mecanismo ADL para manejar tales posiciones cuando el mercado cierra (por ejemplo, reducción forzada parcial de posiciones para pagar tarifas de financiamiento acumuladas). Estos problemas están planeados para ser resueltos en v0.8; dado que las proporciones de colateral actuales son relativamente altas, el riesgo inmediato es bajo. - Ajustamos el algoritmo de cálculo del rendimiento anualizado de GLV/GM basado en información de Kalcrypto para alinearlo con el enfoque de GMX. - Completamos el soporte para el despliegue distribuido y el desarrollo parcial de la API para el nuevo sistema de keepers; se espera que el desarrollo restante de la API de suscripción termine la próxima semana. - Actualizamos el frontend para los programas v0.7 (especialmente el soporte para GT y RWA); integramos la API de precios de Chainlink, reemplazando parcialmente la API de GMX (para tokens no cubiertos por GMX, el frontend ahora utiliza precios de Chainlink para cálculos y renderizado de gráficos). - Investigamos una solución JIT (Just-In-Time) fuera de la cadena, que puede reducir los costos de desarrollo mientras ofrece protecciones más ricas y mayor eficiencia de ejecución en comparación con el enfoque en cadena. La idea principal es hacer que la ejecución de órdenes sea atómica con los cambios de GLV, con el keeper decidiendo si permitir tales acciones (por ejemplo, rechazándolas si el impacto de precio estimado es demasiado alto). Para optimizar la experiencia del usuario, la creación de órdenes JIT también puede ser manejada a través de la API del keeper: si la orden sería rechazada, el keeper puede negar su creación de antemano. ¡Gracias a todos!