. @GMX_SOL Mise à jour hebdomadaire [2025-08-10] Salut à tous ! Cette semaine, nous avons accompli les éléments suivants : - Déploiement de la version principale des programmes v0.7 terminé. Les frais d'emprunt peuvent désormais générer des GT, permettant d'utiliser les GT pour inciter les OIs. Les informations de sécurité pour les programmes peuvent désormais être consultées sur le réseau principal via l'explorateur. - Ajout de métadonnées de jetons pour les jetons GLV sur le réseau principal, qui peuvent désormais être consultées dans l'explorateur et dans les portefeuilles ; la vérification de ces jetons est en cours. - Déploiement d'un lot de marchés RWA avec un GLV correspondant, mais plusieurs nouveaux problèmes ont été identifiés : - Si un marché dans un GLV est fermé, toutes les opérations GLV impliquant ce marché (en particulier les dépôts et les retraits) échouent. - La détection des marchés fermés dans la version actuelle est trop stricte : certains marchés avec une inactivité à court terme pourraient être faussement signalés comme fermés. Cela a été corrigé et soumis à audit, avec un déploiement de la correction prévu pour la semaine prochaine. Pour l'instant, seuls les marchés que nous croyons non affectés sont activés. - Recherche de solutions pour améliorer le support RWA, abordant les problèmes connus suivants : - Pour empêcher la création de commandes lorsque un marché RWA est fermé, nous devons introduire un drapeau is_market_open par marché, se comportant de manière similaire au drapeau ADL, mis à jour par le gardien. - En plus de bloquer la création de commandes, des paramètres temporaires devraient être introduits dans les états de marché fermé pour réduire le risque pour les LP et les traders, par exemple, en augmentant les frais d'emprunt et les ratios de collatéral minimum. - Pour éviter les problèmes causés par le retard dans la collecte des frais de financement (ce qui peut entraîner une dette de marché), les gardiens devraient être autorisés à exécuter des liquidations lorsque les marchés sont fermés. Actuellement, cela est partiellement atténué en augmentant les ratios de collatéral minimum. - Les vérifications de liquidation actuelles permettent aux profits de compenser les frais, ce qui peut entraîner des positions très rentables accumulant de gros frais de financement. Dans les marchés RWA, où les écarts de prix à l'ouverture du marché sont courants, de hauts profits non réalisés peuvent disparaître instantanément, exposant soudainement de gros frais de financement et causant un collatéral insuffisant, ce qui peut entraîner une dette de marché. Nous proposons d'introduire un nouveau mécanisme ADL pour gérer de telles positions lors de la fermeture du marché (par exemple, réduction partielle forcée de la position pour payer les frais de financement accumulés). Ces problèmes sont prévus pour être résolus dans la v0.8 ; étant donné les ratios de collatéral relativement élevés actuels, le risque immédiat est faible. - Ajustement de l'algorithme de calcul de performance annualisée GLV/GM basé sur les informations de Kalcrypto pour s'aligner sur l'approche de GMX. - Support complet pour le déploiement distribué et développement partiel de l'API pour le nouveau système de gardien ; le développement de l'API d'abonnement restant devrait se terminer la semaine prochaine. - Mise à jour de l'interface pour les programmes v0.7 (en particulier le support GT et RWA) ; intégration de l'API de prix de Chainlink, remplaçant partiellement l'API de GMX (pour les jetons non couverts par GMX, l'interface utilise désormais les prix de Chainlink pour les calculs et le rendu des graphiques). - Recherche d'une solution JIT (Just-In-Time) hors chaîne, qui peut réduire les coûts de développement tout en offrant des protections plus riches et une efficacité d'exécution plus élevée par rapport à l'approche sur chaîne. L'idée principale est de rendre l'exécution des commandes atomique avec les changements de GLV, le gardien décidant s'il faut autoriser de telles actions (par exemple, les rejetant si l'impact sur le prix estimé est trop élevé). Pour optimiser l'expérience utilisateur, la création de commandes JIT peut également être gérée via l'API du gardien : si la commande devait être rejetée, le gardien peut refuser sa création à l'avance. Merci à tous !