. @GMX_SOL Aggiornamento Settimanale [2025-08-10] Ciao a tutti! Questa settimana abbiamo raggiunto i seguenti obiettivi: - Completato il deployment della mainnet dei programmi v0.7. Le commissioni di prestito possono ora coniare GT, consentendo l'uso di GT per incentivare gli OI. Le informazioni di sicurezza per i programmi possono ora essere visualizzate sulla mainnet tramite l'explorer. - Aggiunta la metadata dei token per i token GLV sulla mainnet, che ora possono essere visualizzati nell'explorer e nei portafogli; la verifica di questi token è in corso. - Distribuito un lotto di mercati RWA insieme a un corrispondente GLV, ma sono stati identificati diversi nuovi problemi: - Se un mercato in un GLV è chiuso, tutte le operazioni GLV che coinvolgono quel mercato (soprattutto depositi e prelievi) falliscono. - La rilevazione dei mercati chiusi nella versione attuale è troppo rigida: alcuni mercati con inattività a breve termine potrebbero essere erroneamente contrassegnati come chiusi. Questo è stato corretto e inviato per audit, con la correzione prevista per il deployment la prossima settimana. Per ora, sono abilitati solo i mercati che riteniamo non siano interessati. - Ricercate soluzioni per migliorare il supporto RWA, affrontando i seguenti problemi noti: - Per prevenire la creazione di ordini quando un mercato RWA è chiuso, dobbiamo introdurre un flag is_market_open per mercato, che si comporta in modo simile al flag ADL, aggiornato dal keeper. - Oltre a bloccare la creazione di ordini, dovrebbero essere introdotti parametri temporanei negli stati di mercato chiuso per ridurre il rischio per LP e trader, ad esempio, aumentando le commissioni di prestito e i minimi rapporti di collaterale. - Per evitare problemi causati da ritardi nella raccolta delle commissioni di finanziamento (che possono portare a debito di mercato), i keeper dovrebbero essere autorizzati a eseguire liquidazioni quando i mercati sono chiusi. Attualmente, questo è parzialmente mitigato aumentando i minimi rapporti di collaterale. - I controlli di liquidazione attuali consentono ai profitti di compensare le commissioni, il che può portare a posizioni altamente redditizie che accumulano grandi commissioni di finanziamento. Nei mercati RWA, dove i gap di prezzo all'apertura del mercato sono comuni, alti profitti non realizzati possono scomparire istantaneamente, esponendo improvvisamente grandi commissioni di finanziamento e causando un collaterale insufficiente, potenzialmente portando a debito di mercato. Proponiamo di introdurre un nuovo meccanismo ADL per gestire tali posizioni alla chiusura del mercato (ad esempio, riduzione forzata parziale della posizione per pagare le commissioni di finanziamento accumulate). Questi problemi sono previsti per la risoluzione nella v0.8; date le attuali relativamente alte proporzioni di collaterale, il rischio immediato è basso. - Regolato l'algoritmo di calcolo delle performance annualizzate GLV/GM basato sulle informazioni di Kalcrypto per allinearsi con l'approccio di GMX. - Completato il supporto per il deployment distribuito e lo sviluppo parziale dell'API per il nuovo sistema di keeper; lo sviluppo rimanente dell'API di sottoscrizione è previsto per completarsi la prossima settimana. - Aggiornato il frontend per i programmi v0.7 (soprattutto supporto GT e RWA); integrato l'API dei prezzi di Chainlink, sostituendo parzialmente l'API di GMX (per i token non coperti da GMX, il frontend ora utilizza i prezzi di Chainlink per i calcoli e il rendering dei grafici). - Ricercata una soluzione JIT (Just-In-Time) off-chain, che può ridurre i costi di sviluppo offrendo al contempo protezioni più ricche e una maggiore efficienza di esecuzione rispetto all'approccio on-chain. L'idea principale è rendere l'esecuzione degli ordini atomica con i cambiamenti GLV, con il keeper che decide se consentire tali azioni (ad esempio, rifiutandole se l'impatto di prezzo stimato è troppo alto). Per ottimizzare l'esperienza dell'utente, la creazione di ordini JIT può anche essere gestita tramite l'API del keeper: se l'ordine verrebbe rifiutato, il keeper può negarne la creazione in anticipo. Grazie a tutti!