# NoClipX v2.1.0 — Revisione tecnica preliminare smart contract

**Data:** 15 ottobre 2026. **Ambito:** sorgente Solidity e materiali di compilazione nel pacchetto del progetto; verifica strutturale automatizzata locale. **Non è un audit indipendente** e non certifica che il bytecode on-chain corrisponda ai file analizzati.

## Materiali esaminati

- `docs/NoClipX.sol` (sorgente del token, circa 20 righe)
- `docs/NoClipX_Standard_JSON_Input.json` (input standard con sorgente ERC-20 OpenZeppelin e dipendenze incorporati)
- `docs/NoClipX_Compiled_ABI_Snapshot.json` (ABI + selettori dal precedente artefatto di compilazione del progetto; NON una nuova compilazione)
- `app.js`, `_worker.js`, `mainnet.js` per verificare che la v2.1 mantenga Base Sepolia come unica rete operativa

## Riscontri sul sorgente

| Area | Evidenza | Valutazione | 
|---|---|---|
| Implementazione | `contract NoClipX is ERC20` con import OpenZeppelin 5.6.1 | Pattern standard, favorevole alla semplicità; la dipendenza deve comunque essere verificata |
| Supply | `MAX_SUPPLY = 21_000_000 * 10**18` | 21 milioni di NCLX con 18 decimali |
| Allocazione iniziale | `_mint(msg.sender, MAX_SUPPLY)` una sola volta nel costruttore | Il wallet che esegue il deploy riceve il 100% della supply |
| Nuovo mint | Non è esposta nessun'altra funzione di mint nel contratto; `_mint` di OZ è interno | Nessun percorso di emissione aggiuntiva individuato in questo sorgente |
| Burn | Non esiste una funzione pubblica `burn` nel sorgente NoClipX | Non è previsto un meccanismo di distruzione volontaria integrato |
| Ruoli / amministrazione | Nessuna ereditarietà `Ownable` / `AccessControl`, né funzioni amministrative custom | Nessun ruolo di amministratore esplicito in questo sorgente |
| Pausa / blacklist / tasse | Nessuna funzione per bloccare utenti, sospendere trasferimenti o dedurre commissioni | Nessuna di queste funzioni personalizzate individuata |
| Standard ERC-20 | ABI contiene `transfer`, `transferFrom`, `approve`, `allowance`, `balanceOf`, `totalSupply`, `decimals`, `name`, `symbol`, `MAX_SUPPLY` | L'approvazione a spender esterni rimane possibile: è normale per ERC-20 e va comunicato |
| Upgrade | Non c'è proxy/delegatecall/upgrade path definito da NoClipX | L'implementazione esaminata non è aggiornabile tramite una funzione dedicata |

### Una distinzione importante su `MAX_SUPPLY`

Il nome della costante non applica da solo un limite globale a eventuali nuovi contratti: indica la quantità inizialmente creata. La supply del contratto esaminato resta fissa perché l'unica chiamata a `_mint` è nel costruttore e non c'è un metodo esterno aggiuntivo per richiamarla. Un nuovo deployment su un'altra rete è un altro contratto con nuovo indirizzo e una nuova supply iniziale.

### Rischi e responsabilità ancora aperti

1. **Concentrazione dei token / custodia:** il deployer riceve il 100% dei 21 milioni iniziali. Prima di qualunque lancio pubblico occorrono governance, distribuzione trasparente, protezione delle chiavi e comunicazione sui possibili conflitti d'interesse.
2. **Rischi ERC-20 standard:** l'utente può autorizzare spender tramite `approve`; approvazioni e contratti di terze parti non sono controllati dal token. Preferire limiti adeguati e verificare il destinatario dell'approvazione.
3. **Verifica del bytecode:** questa revisione NON ha eseguito una ricompilazione locale né un confronto indipendente fra bytecode on-chain e sorgente. La precedente verifica BaseScan è un indizio documentale, non sostituisce controlli diretti o audit.
4. **Review indipendente:** necessaria prima dell'uso con denaro reale; includere contratto, app, infrastruttura, dipendenze, operazioni e gestione delle chiavi.
5. **MetaMask:** persiste la classificazione «Malicious site», che non deve essere ignorata o aggirata per eseguire nuove transazioni.
6. **Legale e finanza:** chiarire MiCA, offerta al pubblico, soggetto emittente, disclosure, fiscalità, tokenomics, prezzo/liquidità. La revisione tecnica non autorizza la vendita.
7. **AI futuro:** un chatbot su sito pubblico è soggetto ad abusi e prompt injection; consentire soltanto strumenti blockchain di lettura, applicare rate limit e non usare mai chiavi di firma nel modello.

## Controlli automatizzati inclusi

Il file `tests/contract_source_checks.py` verifica **l'integrità e la struttura** di sorgente, Standard JSON, ABI storica e guardie di rete. I test vengono eseguiti senza rete e non sono test comportamentali dell'EVM. Non provano resistenza a tutte le classi di vulnerabilità, integrità di RPC esterni o provenienza del bytecode on-chain.

**Per completare l'analisi prima di mainnet:** eseguire compilation reproduction con solc 0.8.24/OZ 5.6.1; confrontare bytecode e metadata con BaseScan; predisporre test EVM (fuzz/invariant per trasferimenti e allowances); richiedere un audit indipendente. Base Mainnet resta disabilitata (8453); l'unica rete operativa nel sito è Base Sepolia (84532).