# Guida aggiornamenti in produzione (fondi reali) > Aggiornato 2026-08-31. Soft vs Hard, liquidazioni permissionless, allineamento a buone pratiche tipo Aave. > Solo testo narrativo, senza tabelle. > **Guida completa passo-passo (reti reali / fondi clienti):** > [`GUIDA-UPGRADE-RETI-REALI.md`](./GUIDA-UPGRADE-RETI-REALI.md) > Stessa copia sull’admin panel: `GUIDA-UPGRADE-RETI-REALI.md` · Guida admin → cerca «reti reali». --- ## Principio Le liquidazioni devono restare possibili durante la maggior parte delle manutenzioni. Il keeper è solo il bot automatico (cron Netlify più gli switch in Admin). On-chain le liquidazioni sono permissionless: con keeper spento si può ancora liquidare a mano dall’interfaccia o chiamando direttamente il contratto. Su Leverage, `pause()` blocca anche `liquidate()`. Su LTV, `liquidatePosition` in pratica può restare disponibile anche in pause (comportamento attuale). Un `diamondCut` è atomico: spegnere il keeper non è obbligatorio per ogni upgrade, ma solo se tocchi logica o indirizzi di liquidazione. In produzione il keeper va tenuto preferibilmente sempre attivo come rete di sicurezza (modello ibrido simile ad Aave più bot ufficiale). Su Sepolia, finché non serve, lascia gli switch spenti. L’avviso verso gli utenti si pubblica da Admin → Aggiornamenti → Avviso frontend (barra superiore del sito). Il frontend legge l’API pubblica del banner tramite `NEXT_PUBLIC_LENDZY_ADMIN_URL`. Come su Aave, in routine il protocollo resta liquido; la pause totale è per le emergenze. La differenza Lendzy è che puoi spegnere il bot: usalo di rado. In futuro potranno entrare bot terzi; il keeper resta il backup. --- ## Strumenti In Admin, la sezione Aggiornamenti / Release gestisce la manutenzione Soft (default) e Hard (contratti), più l’Avviso frontend con preset e data/ora. Gli switch del keeper LTV, Leverage e Pool stanno in Parametri tassi e rischio: oggi restano spenti; in produzione andranno tenuti accesi. Emergency espone pause e unpause. La Guida admin (cerca «soft», «banner», «aave», «keeper», «reti reali») riprende questi concetti. Nel repo frontend (`lendzy3.0`) lo strumento CLI è `npm run release-safety`, utile prima e dopo un deploy o un cut. --- ## Soft contro Hard La modalità Soft è quella di default. Si usa per frontend, API, indexer e parametri admin. Non tocca i keeper: restano come li hai lasciati (in produzione dovrebbero restare accesi). Le liquidazioni automatiche e manuali restano disponibili. Si avvia con «Manutenzione soft» oppure `POST /api/release/soft`. La modalità Hard è per `diamondCut`, nuovi flash liquidator e interventi su storage critico. Di solito conviene lasciare i keeper accesi («Hard (keeper ON)»). Li spegni solo se l’upgrade tocca davvero le liquidazioni («Hard + spegni keeper»). Anche in Hard le liquidazioni manuali restano possibili, salvo pause su Leverage. API: `POST /api/release/hard` con eventuale `disableKeepers`. --- ## Quando spegnere il keeper Per soli cambi di interfaccia, testi, Drop Netlify, CDY, fee, whitelist, indexer o CORS resta Soft e keeper acceso. Per un `diamondCut` su facet che non riguardano la liquidazione resta Hard con keeper acceso. Se invece aggiorni facet di posizioni, `liquidate*`, flash liquidator o layout di storage, usa Hard, spegni il keeper per pochi minuti, verifica, poi riaccendi. In emergenza su liquidazioni puoi spegnere il bot o mettere in pause Leverage, consapevole del trade-off. --- ## Workflow Per Soft (frontend o API): apri Manutenzione soft; eventualmente `npm run release-safety -- --phase pre-deploy`; esegui `npm run build` e ridispiega `out/`; chiudi la finestra. Per Hard con keeper acceso (la maggioranza dei diamondCut): apri Hard (keeper ON); lancia `release-safety`; esegui il forge `diamondCut`; sincronizza manifest e ABI; rilancia `release-safety` in fase post-upgrade con verify; chiudi la finestra. Per Hard con keeper spento (solo se tocchi liquidazioni): apri Hard e spegni i keeper (lo snapshot è automatico); fai cut o deploy liquidator in pochi minuti, non in ore; verifica con `verify-sepolia` e i verify di liquidazione; chiudi la finestra; in Parametri riattiva i keeper uno alla volta, nell’ordine LTV, poi Leverage, poi Pool. Usa `pause()` se vuoi bloccare nuove operazioni utente. Non usarla come sostituto delle liquidazioni se ti serve solvenza, soprattutto su Leverage. --- ## Cosa fare e cosa non fare Preferisci Soft. Spegnere il keeper solo quando l’upgrade tocca le liquidazioni. Ricorda che keeper spento non significa liquidazioni impossibili. Se spegni il bot, tieni la finestra stretta (minuti). Gli snapshot Hard finiscono in `server/data/release-snapshots/`. Dopo Hard verifica in sola lettura prima di riaprire. Riattiva i keeper a mano uno alla volta: chiudere la finestra non li riaccende. Allinea `manifest.json`, `.env.local` e la build Netlify, perché `NEXT_PUBLIC_*` è bake-time. Registra i passi in audit (SIWE). Non spegnere i keeper per ogni `diamondCut`. Non lasciare Soft o Hard aperti con keeper spenti per ore o giorni. Non mettere in pause Leverage se vuoi liquidazioni vive lì. Non trattare «keeper OFF» come obbligo di checklist. Non riattivare tutti i keeper insieme dopo un intervento chirurgico. Non ridispiegare `out/` senza rebuild dopo un cambio di env. Non committare `PRIVATE_KEY` o `.env.local`. --- ## Admin: cosa fanno i controlli «Manutenzione soft» apre il banner e la modalità soft senza toccare i keeper. «Hard (keeper ON)» apre la finestra hard lasciando i bot attivi. «Hard + spegni keeper» spegne LTV, Leverage e Pool e salva uno snapshot. «Salva banner» aggiorna solo messaggio e toggle del banner di release. «Chiudi finestra» termina soft o hard e non riaccende i keeper. «Aggiorna checklist» rilegge stato live e la nota sulle liquidazioni permissionless. La card Avviso frontend pubblica sul sito un messaggio con preset e data/ora. I preset tipici dicono, con data e ora dell’evento: manutenzione in corso con liquidazioni soltanto manuali; manutenzione programmata con operazioni limitate; aggiornamento protocollo (auto-liq eventualmente sospese, manuali ok); liquidazioni automatiche sospese; attenzione agli oracoli; rete lenta; nuova funzionalità; oppure un messaggio del tutto personalizzato. In produzione il frontend usa `NEXT_PUBLIC_LENDZY_ADMIN_URL=/admin-api` (proxy Netlify verso Railway, già in `_redirects` e `netlify.toml`). In locale senza proxy punta a `http://127.0.0.1:8787`. Il CORS Railway include griffinx.it e localhost. Setup già fatto in repo: API banner live su Admin Railway; proxy `/admin-api/*`; env Netlify e `.env.local`; build che include i redirect. Resta a te attivare un preset da Admin dopo SIWE quando serve comunicare agli utenti. Endpoint utili: lettura pubblica del banner (`GET /api/site-banner/public`), config e preset (`GET /api/site-banner`), salvataggio SIWE (`POST /api/site-banner`), stato e checklist release, soft, hard, complete, e il vecchio pre-upgrade (compatibile con hard più spegnimento keeper). --- ## CLI Da usare nel repo `lendzy3.0`: `npm run release-safety` per il check completo; con `--phase pre-deploy` prima di un solo frontend; con `--phase post-upgrade --with-verify` dopo un cut; con `--json` se serve output macchina. --- ## Rollback Se è rotto solo il frontend, ridispiega la cartella `out/` precedente. Se è un parametro on-chain, reimposta il valore precedente dalla stessa Admin. Se è una facet sbagliata, fai `diamondCut(Replace)` verso la facet Previous documentata in `DIAMOND-CONTRATTI-DEPLOY.md`. Per i keeper, ripristina dallo snapshot Admin o dalle checkbox in Parametri. --- ## Riferimenti Consulta `docs/GUIDA-UPGRADE-RETI-REALI.md` per la procedura completa su reti reali, `DIAMOND-CONTRATTI-DEPLOY.md` per il registry, le guide `GUIDA-LIQUIDAZIONE-*.md`, `NETLIFY-OPS.md`, `API-GRIFFIN-STATUS.md`, e in Admin la Guida cercando soft, hard, banner, aave, keeper, reti reali.