Anatomia di un rug pull

Master sorgente EN · P07-L08 · durata stimata 45 minuti · needs_review

Obiettivi didattici:

• Ricostruire una sequenza storica riportata dalla fonte senza usare il senno di poi.
• Separare sintomi, meccanismo e attribuzione degli attori.
• Calcolare l’effetto sulla profondità di un prelievo proporzionale fittizio.

Un prezzo che crolla può rivelare un serio cambiamento economico senza rivelarne la causa. Prelievo di liquidità da parte del creatore, compromissione di un conto privilegiato, normale vendita in un pool poco profondo e guasto di routing possono produrre schermate simili. Ricostruire cambiamenti e classificare evidenza prima di assegnare una storia.

«Rug pull» è una conclusione sulla condotta, non un’unità di misura. Descrivere cosa è cambiato, chi poteva compiere l’azione, cosa stabiliscono i record e cosa resta sconosciuto. Un risultato preciso e circoscritto è più utile di un’accusa costruita su un grafico.

Separare sintomo, meccanismo e attore

Partire dal sintomo: riserve diminuite, scambio fallito, autorità cambiata o token trasferiti da un detentore. Verificare poi il meccanismo: prelievo tramite posizione, vendita, esercizio di permesso o interfaccia che non restituisce più dati? Infine valutare l’attribuzione. Il firmatario della transazione identifica la partecipazione di un conto, non la persona che lo usa o se le credenziali fossero compromesse.

Tre colonne: «riserve diminuite» è osservazione se sostenuta da snapshot corrispondenti; «prelievo di liquidità» richiede evidenza delle operazioni; «il creatore ha rubato intenzionalmente» richiede attribuzione e intento oltre al grafico. Se la fonte riporta solo un exploit, preservare l’etichetta anziché trasformarla in condotta illecita del creatore.

Autorità del token e controllo del pool sono superfici separate. Revocare l’autorità di mint non risponde alla possibilità di prelevare una posizione. Un lock della liquidità dichiarato richiede posizione esatta, frazione rilevante, meccanismo, scadenza ed eccezioni. Anche una restrizione verificata su un’azione non dimostra innocuità di tutte le altre. Non sostituire queste domande con un punteggio generale di sicurezza.

Ricostruire lo stato intorno a un evento circoscritto

Specificare rete, asset/protocollo esatto, finestra temporale, fonte e copertura delle misurazioni. Confrontare osservazioni prima/dopo degli stessi oggetti. Riserve token, riserve della valuta di quotazione, posizioni di liquidità e permessi sono variabili diverse. La differenza tra snapshot aggregato di più pool e snapshot di un singolo pool non è variazione valida di un singolo pool.

Una tabella solida contiene tempo dell’evento, localizzatore, azione riportata, conseguenza e limite di certezza. Snapshot mancanti restano mancanti. Non ricavare saldi precedenti da articoli successivi o dashboard attuali. Senza record congelati delle riserve, è possibile ricostruire la cronologia riportata dall’editore, ma non calcolare indipendentemente perdite storiche dei pool o esecuzioni dei trader.

Un grafico da solo non distingue prelievo e vendita. Rimuovere riserve proporzionali può mantenere il rapporto riducendo la profondità; vendere in un pool a prodotto costante cambia il rapporto attraverso un’altra operazione. Cercare transazione e cambiamenti delle posizioni, non solo candele in discesa.

Separare tempo della conoscenza e dell’evento

Il reporting storico ha almeno due orologi: tempo in cui si riporta avvenuta l’azione e tempo in cui l’analista accede all’evidenza. Un articolo domani può descrivere un evento oggi senza rendere il contenuto disponibile oggi.

Questo conta per valutare affermazioni di allarme precoce. Se un postmortem attribuisce successivamente l’evento a un conto privilegiato compromesso, non presumere che un osservatore conoscesse l’attribuzione prima del resoconto. Dire «il resoconto successivo descrive questo evento a questo tempo» e separare ciò che l’osservatore precedente poteva ispezionare. Se si conosce solo la data di pubblicazione, non inventare un’ora precisa.

L’indagine può essere utile senza pretendere potere predittivo. La cronologia di mitigazione mostra controlli riportati come cambiati dopo l’incidente; non dimostra che un allarme lo avrebbe impedito o che protocolli futuri con controlli simili siano sicuri.

Usare con prudenza il caso storico comparativo

L’exploit di protocollo Raydium di dicembre 2022 confronta compromissione di un conto privilegiato e narrativa di prelievo del creatore. Non è presentato come rug pull del creatore di una memecoin. Il postmortem ufficiale è il resoconto dell’editore primario; il registro non è stato riprodotto indipendentemente.

Un resoconto di prima parte può stabilire cosa ha dichiarato l’editore. Confermare indipendentemente ogni dichiarazione richiede transazioni corrispondenti, stato archiviato e decodifica riproducibile. Preservare la distinzione nel pannello. È accettabile citare un resoconto ufficiale dicendo che la spiegazione proposta dell’intrusione iniziale non è stabilita.

Trasferire il metodo, non un verdetto: quale privilegio è coinvolto, quale rimedio lo avrebbe rimosso/spostato e quale evidenza serve per stabilire perdite e controllo indipendentemente? Applicare le domande a una memecoin solo dopo averne acquisito i record propri.

Modellare la profondità senza fingere di misurare l’incidente

Nel modello fittizio separato usare pool a prodotto costante con due riserve e commissioni zero: riserva base X e di quotazione Y. Input di quotazione q restituisce Xq/(Y+q) unità base. Prezzo marginale di quotazione Y/X. È il modello ristretto introdotto in P07-L03 [S-PRICING], non ricostruzione dei pool Raydium sfruttati.

Un prelievo proporzionale cambia X e Y dello stesso fattore. Il rapporto può restare uguale mentre l’ordine fisso diventa grande rispetto alle riserve residue. Un prezzo visualizzato stabile è quindi evidenza insufficiente di profondità eseguibile stabile. Commissioni, liquidità concentrata, altri percorsi, restrizioni di trasferimento e scambi intermedi richiedono altri calcoli.

Non confondere conclusioni del modello e fatti osservati. Il modello mostra una conseguenza meccanica possibile sotto assunzioni dichiarate. Il resoconto storico fornisce una cronologia. Nessuno fornisce rendimento misurato, consiglio d’investimento o identità di un responsabile di memecoin.

• Sintomo: cambiamento visibile con possibili cause diverse.
• Meccanismo: operazione che collega cambiamento di stato e risultato.
• Attribuzione: collegamento sostenuto tra azione e attore.
• Tempo dell’evento: tempo riportato dell’azione.
• Tempo della conoscenza: quando l’evidenza diventa disponibile a un osservatore.
• Postmortem: resoconto retrospettivo con limiti propri.
• Profondità: riserve disponibili rilevanti per ordine e percorso specifici.

RECORD DELLA FONTE HISTORICAL — HIST-P07-08. Riepilogo editoriale congelato del postmortem ufficiale Raydium [S-INCIDENT], pubblicato il 17 dicembre 2022 e ispezionato il 30 settembre 2026. Tutti i tempi sono tempi UTC degli eventi riportati dall’editore. Nessuna riproduzione delle transazioni, snapshot delle riserve o attribuzione umana indipendente fornita.

L’articolo riporta un exploit con funzioni privilegiate e contabilizzazione delle commissioni. Discute una possibile spiegazione dell’intrusione senza stabilire il vettore iniziale esatto. È confronto di exploit di protocollo, non classificazione documentata di rug pull del creatore.

MODELLO ILLUSTRATIVE — FIX-P07-08. Unità base/quotazione fittizie; nessuna riserva storica Raydium.

Assumere commissioni zero, trasferimenti senza restrizioni, nessun altro percorso o scambio intermedio. Applicare separatamente un input ipotetico di quotazione di 1 unità a ogni stato iniziale.

DICHIARAZIONE DELLA FONTE OBSERVED: H1–H4 sono dichiarazioni ispezionabili del resoconto citato. Tempi riportati dalla fonte, non verificati indipendentemente qui.

INFERRED: in FIX-P07-08 la rimozione proporzionale conserva il rapporto marginale aumentando il sovrapprezzo medio d’esecuzione per l’input specificato. Deriva dal modello fornito, non dall’incidente.

UNKNOWN: snapshot effettivi delle riserve storiche, effetti decodificati indipendentemente di ogni transazione, vettore iniziale esatto e cosa sapeva un osservatore specifico prima della pubblicazione.

INSUFFICIENT EVIDENCE: i record non stabiliscono rug pull del creatore di memecoin, allarme predittivo precedente o sicurezza dopo il rimedio. Il calcolo di riserve fittizie non stabilisce perdite reali.

Etichettare rug pull da grafico in discesa; credenziali compromesse come prova d’intento del creatore; confondere pubblicazione ed evento; calcolare riserve storiche da dati fittizi; rapporto invariato come profondità invariata.

Dati H1–H4 e FIX-P07-08. Lavorare senza rete o connessione wallet.

1. Ordinare i quattro eventi e mantenere tempi approssimativi.
2. Valutare «Alle 11:00 UTC del 16 dicembre, l’analista conosceva già l’attribuzione del postmortem ufficiale». Usare solo record forniti.
3. Calcolare output base e prezzo medio per q=1 nei due stati fittizi. Confrontare ogni media con il prezzo marginale iniziale.
4. Scrivere conclusione circoscritta in tre frasi ed elencare record aggiuntivi necessari per verificare indipendentemente un prelievo di liquidità.

• Separare oggetto, meccanismo e attribuzione.
• Registrare fonte, tempo dell’evento e limiti del tempo della conoscenza.
• Confrontare stati prima/dopo corrispondenti.
• Preservare cause sconosciute e spiegazioni alternative.
• Separare matematica illustrativa e misurazione storica.
• Riportare conclusione circoscritta senza segnale finanziario.

Ricostruire un incidente preserva la catena fonte/evento/cambiamento di stato. Il postmortem insegna il metodo senza dimostrare rug pull del creatore. Gli esiti storici non forniscono retroattivamente evidenza a osservatori precedenti.

Un’etichetta non sostituisce un meccanismo. Prezzo marginale stabile può coesistere con minore profondità. Attribuzione dell’editore, verifica indipendente e intento umano restano distinti.

Creare cronologia UTC H1–H4 usando il resoconto dell’editore; separare corsia del tempo degli eventi e data di pubblicazione, etichettare H4 come approssimativo e l’attribuzione come riportata dalla fonte. Aggiungere un riquadro separato esplicitamente illustrativo per FIX-P07-08 con rapporti marginali uguali e output q=1. Mai rappresentare riserve fittizie come misurazioni storiche dell’incidente.

Regole visual: navy/nero scuro, accenti ciano/blu elettrico/viola, unità e incertezza esplicite. Grafici/SVG deterministici, non schermate inventate. A 390 px impilare annotazioni e fornire tabella testuale alternativa; verificare successivamente 768 px e desktop. In arabo localizzare etichette/layout RTL nativi, isolando indirizzi/hash LTR e mantenendo direzioni reali dei trasferimenti e cronologia. Solo logo ufficiale BlockAssay fornito se si aggiunge il marchio. Nessun visual o rendering mobile/RTL dichiarato pronto.

Usare RADAR solo quando rete, asset e campi necessari esatti sono supportati con provenienza visibile. Ispezione didattica in sola lettura, non trading o lancio token. Se accesso/dati mancano, usare dataset senza rete; informazioni mancanti restano sconosciute. Una futura azione Open in BlockAssay richiede routing runtime e copertura delle fonti validati. Nessuna CTA eseguibile per identificatori illustrativi. Partecipazione Academy e stato commerciale non cambiano mai osservazioni Radar.

• Raydium Detailed Post-Mortem and Next Steps — Incidente e mitigazione di dicembre 2022 riportati dall’emittente; non attribuzione indipendente o conclusione di rug pull di memecoin. Verificata 2026-09-30.
• Uniswap v2 Pricing — Prezzi di pool a prodotto costante con due riserve; non modello per ogni lancio/pool. Verificata 2026-09-30.
• Solana Set Authority — Ruoli specifici di autorità e rimozione di un’autorità selezionata. Verificata 2026-09-30.

Tabelle e dati dell’esercizio sono materiale didattico originale salvo designazione HISTORICAL. Gli identificatori fittizi sono deliberatamente invalidi come indirizzi blockchain. La documentazione sostiene definizioni dei meccanismi, non valori inventati. L’ispezione delle fonti è ricerca editoriale, non misurazione della blockchain in tempo reale. Le fonti possono cambiare; rivederle prima della pubblicazione.

P07 completato. Rivedere cronologia, modello di liquidità e limiti dell’evidenza, poi tornare alla dashboard Academy. I laboratori separati mantengono i prerequisiti elencati.