Deployer e primi acquirenti

Master sorgente EN · P07-L05 · 45 minuti stimati · needs_review

Obiettivi di apprendimento:

• Mappare separatamente pagatore delle commissioni, inizializzatore, autorità e destinatario dell’allocazione.
• Identificare primi acquisti riusciti da risultati ed effetti dell’esecuzione.
• Riportare i primi acquirenti visibili con limiti espliciti di copertura e attribuzione.

Una transazione di lancio può coinvolgere un pagatore delle commissioni, un inizializzatore del mint, un indirizzo di autorità, un programma e diversi account destinatari. Chiamare un indirizzo «il deployer» può nascondere questi ruoli. Analogamente, ricevere token presto non significa necessariamente acquistarli. Questa lezione insegna una mappa dei ruoli sostenuta dalle transazioni e un elenco dei primi acquirenti con ambito attentamente circoscritto.

Sostituire un’etichetta vaga con ruoli specifici

Definire «deployer» prima di usarlo. Per un memecoin Solana, puoi intendere l’account che paga l’inizializzazione, il firmatario che autorizza l’emissione o l’operatore che usa un launchpad. Quei ruoli non devono essere uguali. La documentazione Solana separa esplicitamente l’autorità del mint dall’account che crea o paga il mint [S-TOKENS]. Un ruolo può anche essere mediato da un programma anziché rivelare un account umano.

Usare etichette di ruolo che descrivano le prove effettive: pagatore delle commissioni, inizializzatore del mint, autorità del mint, destinatario dell’allocazione, account che finanzia il pool e destinatario dello swap. Un campo autorità è un permesso a un’osservazione dichiarata, non prova di chi abbia costruito un sito. Un indirizzo può avere più ruoli, ma ogni relazione richiede un riferimento probatorio.

L’etichetta «creatore» di un explorer può essere un’interpretazione comoda dell’indicizzatore. Confrontarla con istruzione e stato pertinenti. Se non puoi esaminare quei record, riportare l’etichetta come dichiarazione della fonte anziché ruolo verificato. Lo scopo non è diffidare di ogni indicizzatore; è rendere visibile la dipendenza.

Separare intenzione dell’istruzione ed effetti riusciti

Una transazione può contenere un’istruzione di swap ma fallire. Un destinatario può ottenere token tramite allocazione, trasferimento o swap. Esaminare risultato dell’esecuzione e variazioni dei saldi prima di contare operazioni riuscite. La ricerca delle transazioni Solana include metadati del risultato e può restituire null quando un record non è disponibile al livello di conferma richiesto [S-TRANSACTION]. Null non dimostra che un indirizzo non abbia mai agito.

I saldi netti possono fuorviare senza il contesto delle istruzioni. Una transazione può combinare creazione di account, trasferimento, commissioni e scambio. Ricevere token è soltanto un’osservazione; un acquisto economico richiede anche prove di un meccanismo di scambio e dell’asset corrispondente pagato. Registrare esplicitamente importi netti rispetto a lordi se sono coinvolti movimenti intermedi.

Una transazione fallita può comunque provare che sia avvenuto un tentativo e le commissioni possono restare rilevanti. Non è un acquisto riuscito. Separare una tabella dei tentativi dalla tabella degli acquisti riusciti. Questo mantiene intatto il record del lancio senza contaminare la classifica.

Circoscrivere «primo acquirente» a ciò che hai effettivamente cercato

Per affermare «primo», dichiarare sede, asset, tipo di evento, intervallo di osservazione, convenzione di ordinamento e copertura storica. Un acquisto su launchpad e un acquisto successivo sul pool possono appartenere a classifiche diverse. Il primo record visibile nella finestra di un fornitore non è automaticamente la prima operazione sulla blockchain.

La cronologia delle firme di un indirizzo può essere paginata ed è normalmente restituita dalla più recente [S-SIGNATURES]. Un ricercatore non deve interpretare il primo elemento restituito come il primo evento in assoluto. Anche la copertura degli indirizzi referenziati non garantisce che ogni transazione rilevante sia catturata esaminando un solo indirizzo. Mint, mercato, programma e account associati possono avere esigenze d’indicizzazione diverse.

Slot e timestamp visualizzati sono aiuti distinti all’ordinamento. Diversi eventi possono condividere un secondo visualizzato. La granularità del timestamp di un indicizzatore può nascondere l’ordine; usare indici delle transazioni quando disponibili e preservare l’incertezza altrimenti. Se l’ordine è irrisolto, riportare una coorte iniziale anziché inventare un unico primo acquirente.

Interpretare il comportamento iniziale senza inferire motivazioni

Un indirizzo che agisce presto può essere un trader automatizzato, un partecipante che segue eventi pubblici di lancio, un market maker o qualcuno con informazioni privilegiate. Il solo tempismo non distingue queste spiegazioni. Un collegamento a un indirizzo che finanzia il pool può giustificare ulteriori indagini ma non risolve la proprietà umana comune.

Un rapporto utile ha due livelli. Il primo è una tabella fattuale di ruoli/transazioni. Il secondo è un registro di ipotesi circoscritte, che indica possibili interpretazioni e quali prove le rafforzerebbero o indebolirebbero. Non promuovere silenziosamente un’ipotesi nell’etichetta dell’indirizzo mostrata ovunque altrove.

Questi limiti non rendono irrilevante l’attività iniziale. Rendono verificabile la conclusione. «L’indirizzo B1 ha ricevuto 10,000 unità nel primo acquisto riuscito nella finestra della sede fornita» è preciso. «Il creatore ha comprato segretamente per primo» introduce identità, motivazione e accesso che richiedono più della sola transazione.

• Pagatore delle commissioni: account che paga la commissione di rete della transazione.
• Autorità: account autorizzato a consentire un’operazione specifica.
• Destinatario dell’allocazione: account che riceve unità distribuite senza prove d’acquisto.
• Acquisto riuscito: scambio verificato con risultato riuscito ed effetti pertinenti.
• Finestra di copertura: storia circoscritta effettivamente esaminata.
• Attribuzione del ruolo: associare un ruolo operativo osservato a un indirizzo.

ESEMPIO ILLUSTRATIVE — FIX-P07-05. Le sei righe sono un materiale completo per VENUE-A tra T+0 e T+5 relativi. ID e quantità sono fittizi.

Questi effetti delle operazioni sono record fittizi forniti, non output derivati dal pool della lezione 3. Qui non è fornito alcun modello delle riserve; non importarne uno.

OBSERVED: Il materiale assegna ruoli diversi d’inizializzazione a F, C e A. B1 ha il primo acquisto riuscito nella finestra VENUE-A fornita e appare due volte.

INFERRED: Una mappa dei ruoli è una rappresentazione utile di queste relazioni osservate; non identifica i loro controllori umani ultimi.

UNKNOWN: Sedi/eventi precedenti fuori dal materiale, proprietà umana, comunicazioni private e privilegi d’accesso.

INSUFFICIENT EVIDENCE: L’allocazione di R non è un acquisto. BUY-FAIL non è un acquisto riuscito. Il tempismo di B1 non può stabilire accesso da insider o una relazione con C.

Equiparare pagatore delle commissioni e creatore; elencare il destinatario dell’allocazione come primo acquirente; ignorare risultati falliti; contare transazioni come acquirenti distinti; interpretare al contrario record dalla più recente; e nominare un insider umano dal tempismo del lancio.

Costruire la mappa dei ruoli d’inizializzazione e classificare eventi d’acquisto riusciti nella finestra fornita. Contare indirizzi distinti di acquirenti riusciti, sommare spesa di quotazione e token ricevuti da B1 e riscrivere «B1 era il primo acquirente insider del progetto».

• Definire esplicitamente ogni ruolo operativo.
• Verificare risultato, istruzione ed effetti pertinenti sui saldi.
• Separare allocazione, trasferimento, tentativo e scambio riuscito.
• Dichiarare copertura di sede/tempo/storia per ogni affermazione «primo».
• Contare indirizzi unici separatamente dagli eventi di transazione.

Un’indagine del lancio dovrebbe preservare ruoli distinti ed effetti riusciti. «Primo acquirente» ha significato soltanto entro un ambito documentato di ricerca e un indirizzo iniziale non è automaticamente creatore o insider.

Usare mappe dei ruoli anziché un’etichetta ambigua di deployer. Preservare tentativi falliti separatamente. Il tempismo sostiene la cronologia, non la motivazione.

Tracciare ruoli INIT-A come archi etichettati verso un nodo mint; usare una cronologia separata per allocazione, tentativo fallito e swap riusciti. Mostrare B1 ripetuto senza creare un nuovo nodo di indirizzo. Allegare effetti di quotazione e token dal materiale e un limite visibile di copertura VENUE-A.

Regole di consegna delle visualizzazioni: blu navy scuro/nero, accenti ciano/blu elettrico/viola, unità e incertezza etichettate esplicitamente. Usare grafici deterministici o SVG, non schermate inventate. A 390 px impilare annotazioni e fornire la tabella dei dati come alternativa testuale; verificare 768 px e desktop in seguito. In arabo localizzare etichette e disposizione con RTL nativo, isolando indirizzi/hash in LTR e mantenendo la direzione reale dei trasferimenti e la cronologia. Usare soltanto il logo ufficiale BlockAssay fornito se viene aggiunto il marchio. Nessuna risorsa visiva o rendering mobile/RTL è dichiarato pronto.

Usare WALLET_INTELLIGENCE soltanto quando rete esatta, asset e campi necessari sono supportati e la loro provenienza è visibile. È un esame educativo in sola lettura, non un’operazione di trading o un lancio di token. Usare il dataset offline fornito se accesso o dati non sono disponibili; le informazioni mancanti restano sconosciute. Una futura azione Apri in BlockAssay richiede instradamento runtime e copertura delle fonti convalidati. Non è fornita alcuna CTA di asset eseguibile per identificatori illustrativi. La partecipazione all’Academy e lo stato commerciale non cambiano mai le osservazioni di Radar.

• Asset Solana: mint e account token — Identità del mint, proprietà degli account token e ruoli distinti di mint/creazione. Verificato 2026-09-30.
• Solana getTransaction — Ricerca di transazioni confermate e risultati di transazione/tempo/meta che possono essere null. Verificato 2026-09-30.
• Solana getSignaturesForAddress — Firme degli indirizzi referenziati dalla più recente e parametri di paginazione. Verificato 2026-09-30.
• Strutture JSON RPC Solana — Firmatari delle transazioni, istruzioni e metadati di saldi/risultati. Verificato 2026-09-30.

Le tabelle e i materiali degli esercizi sono contenuti educativi originali salvo designazione esplicita HISTORICAL. Gli identificatori fittizi sono deliberatamente invalidi come indirizzi blockchain. La documentazione sostiene definizioni dei meccanismi, non i valori inventati degli esercizi. L’esame delle fonti è ricerca editoriale, non una misurazione della blockchain dal vivo. Le fonti possono cambiare; riesaminarle prima della pubblicazione.

P07-L06; proseguire dopo aver completato l’esercizio e rivisto ogni spiegazione del quiz.