Mint e identità esatta

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

Obiettivi di apprendimento:

• Risolvere l’identità dell’asset usando identificatori completi di rete e mint.
• Distinguere ruoli di mint, account token, pool e wallet.
• Scrivere una conclusione circoscritta sull’identità senza inferire frode o sicurezza.

Un’analisi può essere matematicamente corretta e descrivere comunque l’asset sbagliato. Nomi, ticker, immagini e profili social sono etichette di presentazione copiabili. Prima di interpretare un grafico di liquidità o una tabella dei detentori, stabilire esattamente rete e mint a cui si riferiscono le prove. Questa lezione allena la risoluzione dell’identità e la capacità di fermarsi quando resta ambigua.

Separare l’identificatore dalla storia che lo accompagna

Nell’analisi dei token Solana, rete più indirizzo mint identifica l’asset indagato. Un account token contiene unità associate a un mint; non è il mint stesso [S-TOKENS]. Indirizzi di wallet, pool e mint possono apparire nella stessa pagina di explorer, ma rispondono a domande diverse. Il logo che sembra corretto non rimedia all’uso del tipo di account sbagliato.

Un registro d’indagine sicuro indica quindi blockchain/cluster, identificatore completo dell’asset, tipo atteso di account/programma, fonte e contesto dell’osservazione. Non ridurlo a un indirizzo troncato. Il troncamento è utile per la visualizzazione ma inadatto a confrontare identificatori simili. Memorizzare il valore completo e mostrare una stringa copiabile e isolata quando una futura interfaccia supporta il record.

L’account on-chain dimostra che un particolare asset esiste secondo determinate regole. Non stabilisce che un progetto, comunità o marchio lo approvi. Viceversa, una pagina del progetto può dichiarare un indirizzo senza dimostrare ogni campo tecnico di quell’indirizzo. Tenere identità tecnica e affiliazione dichiarata come affermazioni separate, con fonti separate.

Incrociare le fonti senza contare due volte dichiarazioni copiate

Immagina tre siti che ripetono lo stesso indirizzo. Possono essere pubblicazioni indipendenti, oppure copiare tutti un unico flusso compromesso. Tre apparizioni non fanno automaticamente tre conferme indipendenti. Scrivere una catena di provenienza: chi dichiarò originariamente l’identificatore, quando la dichiarazione era disponibile e quale record tecnico il ricercatore ha esaminato.

Una fonte raggiunta tramite un annuncio di ricerca o un messaggio inoltrato non è automaticamente il canale ufficiale dell’organizzazione. Esaminare dominio esatto e origine del riferimento. Grafie simili, un account rinominato o un sottodominio estraneo possono fuorviare. Anche quando un canale ufficiale è stabilito, etichettare la sua dichiarazione d’indirizzo DECLARED salvo che le verifiche indipendenti pianificate siano state effettivamente eseguite.

Anche «verificato» è ambiguo. Un badge può riferirsi a un account social, una voce di explorer o un invio di metadati. Dichiarare cosa è stato controllato anziché usare il badge come approvazione generale dell’asset. Una conclusione utile è «l’identificatore completo dichiarato corrisponde al mint esaminato sulla rete specificata», non «questo token è legittimo».

Permessi e metadati rispondono a domande più ristrette

Un’autorità di mint e un’autorità di congelamento rappresentano permessi specifici. Rimuovere un’autorità selezionata non cancella ogni possibile rischio [S-AUTHORITY]. Metadati ed estensioni dei token richiedono un esame proprio; i soli campi di base non esauriscono il comportamento aggiuntivo del token [S-EXTENSIONS]. Un analista dovrebbe preservare queste distinzioni anziché combinarle in un’etichetta verde di sicurezza.

Per questa lezione non serve svolgere un audit di sicurezza del contratto. Serve verificare che le prove che intendi usare appartengano effettivamente all’asset dichiarato. Se una fonte descrive un token standard ma un account esaminato usa un altro programma o estensioni non esaminate, registrare la discrepanza ed evitare ipotesi sul comportamento di trasferimento.

Rifiutare di completare prematuramente un’identificazione è un risultato utile. UNKNOWN indica che un fatto rilevante non è stato ottenuto. INSUFFICIENT EVIDENCE indica che i fatti raccolti non possono sostenere una particolare affermazione. Non sono intercambiabili con «falso». Una mancata corrispondenza può giustificare il rifiuto di un candidato come asset esatto dichiarato senza giustificare un’accusa di frode contro il suo creatore.

Rendere la decisione riproducibile

Usare una matrice d’identità con una riga per candidato. Registrare identificatore completo, rete, tipo di account, corrispondenza alla dichiarazione e domande irrisolte. La regola decisionale dovrebbe essere fissata prima di guardare popolarità o performance di mercato: un candidato deve corrispondere alla rete richiesta e al mint completo, e il suo tipo deve essere interpretabile. Se restano più candidati, descrivere l’ambiguità e richiedere dichiarazione o record tecnico mancante.

Questa procedura evita una trappola comportamentale comune: scegliere un candidato perché il suo grafico sembra più plausibile. L’andamento del prezzo non può disambiguare un identificatore di asset. Il lavoro sull’identità precede anche l’unione dei record di più fornitori. Un ticker condiviso non autorizza a combinare il profilo social di un candidato con la distribuzione dei detentori di un altro.

• Identità esatta: identificatore completo di rete e asset, non corrispondenza del ticker.
• Mint: account identificativo del token nell’ambito Solana di questa lezione.
• Account token: account con saldo associato a un mint.
• Dichiarazione: affermazione di una fonte su affiliazione o identità.
• Riscontro: verifica incrociata descritta esplicitamente, con provenienza.
• Autorità: permesso specifico, non identità generale di persona/progetto.

ESEMPIO ILLUSTRATIVE — FIX-P07-02. MINT-A e MINT-B sono etichette fittizie di indirizzo deliberatamente invalide. Non incollarle mai in un explorer come indirizzi reali.

La dichiarazione fornita del progetto fittizio è «training-cluster-A / MINT-A». Il candidato A corrisponde a questo materiale. B è un mint diverso, C non supera la verifica della rete e D ha il ruolo di account sbagliato. Nessuna riga stabilisce l’operatore umano o la qualità d’investimento.

OBSERVED: A corrisponde alla dichiarazione completa e al record del tipo di account forniti nel materiale.

INFERRED: A è il record appropriato per questa analisi definita in modo ristretto, a condizione che la dichiarazione fornita sia il riferimento inteso.

UNKNOWN: Se la dichiarazione del progetto fittizio sia stata autorizzata da un’organizzazione reale; autenticità della fonte oltre il materiale fornito.

INSUFFICIENT EVIDENCE: La corrispondenza di un identificatore non può stabilire sicurezza del progetto, distribuzione equa, onestà del creatore o rendimento futuro. Un candidato diverso non è automaticamente fraudolento.

Usare la ricerca per ticker come identificazione finale; confrontare soltanto i primi/ultimi caratteri; unire dati tra reti; confondere account token e mint; contare dichiarazioni copiate come verifiche indipendenti; e trattare la rimozione dell’autorità come verifica completa di sicurezza.

Dato FIX-P07-02, selezionare il candidato corrispondente e scrivere una conclusione circoscritta di una frase. Spiegare ogni candidato rifiutato. Poi riscrivere «B è una truffa» e «A è verificato sicuro» in affermazioni sostenute dal materiale. Elencare le due verifiche necessarie prima di usare una dichiarazione ufficiale reale.

• Far corrispondere rete e identificatore completo.
• Confermare il ruolo mint/account prima di leggere le metriche.
• Tenere distinte dichiarazione e prove tecniche.
• Registrare indipendenza delle fonti e contesto dell’osservazione.
• Dichiarare identità irrisolta e domande su autorità/estensioni.

L’identità esatta è un prerequisito per ogni misurazione successiva. Risolvere l’asset con identificatori completi e ruoli espliciti degli account, poi descrivere affiliazione e controlli tecnici come affermazioni probatorie separate.

Un ticker non è una chiave d’identità. L’accordo con una dichiarazione è una corrispondenza circoscritta, non un verdetto di sicurezza. L’ambiguità dovrebbe fermare l’unione di dati non correlati.

Disegnare quattro schede di confronto da FIX-P07-02. Evidenziare rete, identificatore sintetico completo e tipo di account; segnare campi corrispondenti separatamente dalle affermazioni di affiliazione. Non mostrare scudi di sicurezza o indizi di prezzo. Un secondo pannello deve spiegare perché l’account token D non è il mint.

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 RADAR 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: impostare l’autorità — Ruoli specifici delle autorità e rimozione di un’autorità selezionata. Verificato 2026-09-30.
• Estensioni dei token Solana — Il comportamento aggiuntivo dei token richiede un esame specifico delle estensioni. 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-L03; proseguire dopo aver completato l’esercizio e rivisto ogni spiegazione del quiz.