Stato reale delle versioni
La nuova politica a più muri fissi è in corso di implementazione e validazione. Non è stata ridistribuita su Sepolia. La dapp collegata usa ancora una versione precedente con commissioni LP dello 0,30%.
Questa edizione della guida è datata 10 settembre 2026. Si basa sulle fonti e sui rapporti del repository, senza eseguire una nuova attestazione di rete in tempo reale.
Tre stati distinti
| Ambito | Stato descritto da questa edizione |
|---|---|
| Specifica richiesta | Acquisto 3% team; vendita 15% (12% muri, 3% team); fee LP 100 = 0,01%; obiettivo all’istante T; muri fissi; base 7k da calibrare in ETH |
| Workspace Solidity | Nuova implementazione e API in sviluppo; compilazione riportata, validazione completa ancora in corso |
| Sepolia collegato alla dapp | Vecchia versione: acquisto 15%, vendita 3%, fee LP 3000 = 0,30%, con registro V2 e moduli sostituibili |
La nuova ripartizione delle tasse sostituisce quella della revisione di codice 991fca9 citata nelle fonti. I risultati di quella revisione non validano questa modifica. Modificare le fonti locali non cambia i contratti già distribuiti. Sincronizzare la documentazione non sposta i fondi di un vecchio pool.
Cosa attestano i rapporti storici
Il rapporto Sepolia descrive il deployment di una versione precedente, verifiche di runtime e collegamenti, acquisti e vendite di collaudo, un collocamento del muro e controlli del rifiuto di azioni inammissibili.
Queste prove appartengono a quella versione. Non testano automaticamente l’indice dei tick, la conservazione di più muri, i loro residui o le interfacce della nuova politica.
I numeri di test pubblicati in roadmapdev.md e nei vecchi rapporti non vengono quindi mostrati come contatori di validazione del workspace attuale.
Cosa non costituisce una validazione completa
Una compilazione riuscita verifica la produzione di bytecode. Da sola non dimostra gli invarianti contabili, il comportamento di un insieme di muri attraversati, la coerenza del frontend o una transazione sulla rete scelta.
Allo stesso modo, confrontare hash dei runtime non significa che le fonti siano state pubblicate su un explorer. I test automatizzati del frontend non sostituiscono un collaudo con un wallet browser o mobile reale.
Condizioni ancora aperte
La nuova versione deve avere risultati propri per scenari, invarianti, integrazione e deployment. Durante questa redazione sono state riportate una compilazione e prime prove mirate; non completano l’intera campagna. Calibrazione della base 7k, librerie collegate, ABI e viste del frontend devono essere coerenti con i risultati finali.
Alla revisione 991fca9, la suite Solidity completa conta 133 test superati e 15 falliti su 148. I 7 test mirati a più muri passano in una campagna distinta. Risultati e limiti sono riportati nel rapporto sullo stato pubblicato.
Prima dell’apertura in produzione restano inoltre da stabilire le validazioni operative, la revisione indipendente dello strict-burn e dei permessi, i percorsi wallet, la compatibilità degli aggregatori e l’assorbimento in un ambiente di rete o fork canonico.
Il progetto non viene dichiarato pronto per la mainnet in questa guida.
Quale fonte seguire
Il punto di partenza è il rapporto francese della revisione 991fca9. Il suo avviso sulla nuova revisione prevale sulle descrizioni storiche successive.
I manifest pubblici in contracts/deployments/ identificano i deployment; indirizzi e metadati vanno confrontati con lo stato on-chain. La guida non inventa un manifest per una versione non pubblicata.
La pagina Fonti precisa l’ordine di lettura e i documenti diventati storici.