Età e comportamento del wallet

Master della fonte EN · P09-L05 · 45 minuti stimati · needs_review

Una pagina che mostra «età del wallet 25 giorni» può significare in realtà25 giorni dal primo record restituito da un indicizzatore. L’account potrebbe essere esistito o aver agito prima. Un grafico quieto può anche riflettere un intervallo mancante anziché inattività.

Questa lezione sostituisce etichette vaghe di età e comportamento con finestre di osservazione definite, conteggi di eventi e descrizioni corrette per la copertura. Non trasforma mai l’età osservata nel vero momento di creazione o l’attività in un giudizio su una persona.

Definire precisamente la prima osservazione

La prima osservazione richiede fonte, query, rete, soggetto considerato e regola di attività. Prima firma, primo trasferimento riuscito, prima azione in uscita e primo evento dell’account di token possono verificarsi in punti diversi. Nominare la regola selezionata prima di riportare un’età.

Le query delle firme Solana restituiscono cronologia dell’indirizzo citato dalla più recente con paginazione [S09-SIGNATURES]. La riga restituita più vecchia è soltanto il primo record visibile sotto quella query. Anche una paginazione riuscita non stabilisce automaticamente cronologia precedente completa per ogni account associato o periodo di conservazione del fornitore.

Una vera affermazione di creazione dell’account necessita di meccanismo ed evidenza pertinenti. Una chiave può esistere privatamente prima di apparire nei record; il momento di distribuzione di un contratto riguarda il contratto, non la generazione della chiave del creatore o il primo wallet di una persona. Il momento di creazione di un account di token riguarda quell’account specifico, non necessariamente l’esistenza del suo proprietario.

Separare orologi e contesti

Contesto del registro, tempo dichiarato dell’evento, tempo di acquisizione della fonte e tempo dell’analisi sono diversi. Le risposte delle transazioni Solana possono avere blockTime null [S09-TRANSACTION]. Se il tempo dell’evento è assente, conservare il contesto dello slot senza inventare un timestamp di calendario.

I dati didattici forniscono scostamenti artificiali in giorni di calendario per l’aritmetica. Non sono state raccolte osservazioni reali dell’orologio e observedAt rimane null. SIM-DAY6 non è una data reale codificata. Sottrarre scostamenti forniti produce soltanto giorni trascorsi sintetici.

Un intervallo dal giorno6 al giorno29 è di 23 giorni trascorsi. Contare gli estremi etichettati di calendario darebbe24 posizioni di date, una quantità diversa. Specificare se si misuri tempo trascorso, si contino date o si definisca un intervallo semiaperto. Non alternare convenzioni per far apparire maggiore l’attività.

Pubblicare la copertura prima dei tassi

Usare finestre semiaperte come [5,31): includere il giorno5 ed escludere il giorno31. Ciò rende non sovrapposte finestre adiacenti. Una lacuna [15,21) toglie sei giorni alla copertura fornita. Non etichettarla «inattiva» quando la fonte non l’ha osservata.

Se gli intervalli coperti sono stipulati completi per la regola selezionata, il conteggio di eventi diviso per giorni coperti è un tasso descrittivo corretto per la copertura. Non è una stima di quanto avvenuto nei giorni mancanti. Dividere per l’intera finestra risponde invece a una domanda diversa e dovrebbe essere nominato esplicitamente.

Un tasso di 0.25 eventi riusciti per giorno coperto significa cinque eventi forniti in venti giorni coperti. Non significa che una transazione sia avvenuta ogni quarto giorno. Il raggruppamento nei giorni conta e l’attività non è ipotizzata uniforme.

Scegliere misure di comportamento

Contare gli eventi riusciti separatamente dai tentativi. Contare giorni attivi distinti separatamente dagli eventi. Più transazioni in un giorno possono produrre un alto conteggio di eventi lasciando invariato il numero di giorni attivi.

Definire asset e direzione. Un record di sola ricezione non è necessariamente iniziativa attiva del soggetto considerato. Eventi che citano un indirizzo non provano una firma. Se la misura comportamentale chiede transazioni avviate, serve evidenza di firmatario o mittente anziché semplice attività che coinvolge l’indirizzo.

La variazione netta del saldo non può misurare competenza di trading. Un wallet può ricevere allocazioni, effettuare trasferimenti o custodire asset per altri. Questa lezione usa soltanto conteggi descrittivi, senza classificazioni di profitto, sofisticazione o strategia.

Gestire onestamente osservazioni parziali

Un primo evento visibile dentro la finestra richiesta produce un’affermazione delimitata: osservato da quell’evento nell’ambito disponibile. Se la copertura inizia dopo che l’account aveva già fondi, anche il primo finanziamento visibile non è evidenza completa dell’origine.

Nessuna riga in un intervallo interamente verificato potrebbe supportare «nessun evento corrispondente restituito sotto questa regola». Ciò comunque non stabilisce assenza di attività su un’altra rete, mint o account collegato. Dati mancanti del fornitore non supportano tale affermazione di assenza a livello di intervallo.

Non estrapolare nelle lacune. Un wallet senza eventi restituiti durante un’interruzione nota non può essere descritto come dormiente allora. Un grafico dovrebbe disegnare una regione sconosciuta esplicitamente ombreggiata anziché una barra di altezza zero simile a uno zero misurato.

Evitare etichette comportamentali di persone

«Adottante precoce», «bot», «trader esperto» o «persona nuova» richiedono definizioni ed evidenze più forti. Schemi temporali possono motivare ipotesi, ma non provano automazione o identità. Cadenza uguale può derivare da azioni programmate dell’applicazione o granularità dell’indicizzazione.

L’account può cambiare la sua configurazione di controllo nel tempo. Continuità dell’attività pubblica non prova che la stessa persona abbia operato ogni evento. Azioni mediate da contratto ed esecuzione delegata complicano l’ipotesi di un utente manuale [S09-ETHACCOUNTS; S09-DELEGATION].

Non classificare affidabilità per età. Una cronologia osservata più vecchia stabilisce un periodo visibile più lungo sotto una fonte dichiarata, non onestà. Un record di prima osservazione più recente non stabilisce né utente principiante né operatore malevolo.

Scrivere una descrizione delimitata dell’attività

Un rapporto utile nomina regola, finestra, lacune, primo e ultimo evento corrispondente visibile, conteggio e convenzione temporale. Poi dichiara esplicitamente i limiti su creazione e controllo.

Preferire «cinque eventi riusciti di trasferimento citato in quattro giorni attivi coperti; cronologia precedente e sei giorni mancanti irrisolti» a «un wallet attivo esperto». Il primo è riproducibile. Consente anche a un revisore successivo di ricalcolare quando arriva copertura migliore.

• Prima osservazione: primo evento corrispondente visibile secondo una fonte/regola specificata.
• Intervallo osservato: tempo trascorso tra primo e ultimo evento fornito.
• Giorno coperto: giorno incluso nell’ambito verificato dei dati.
• Giorno attivo: data coperta con evento corrispondente.
• Finestra semiaperta: include l’inizio, esclude la fine.
• Tasso descrittivo: conteggio diviso per un denominatore di osservazione dichiarato.

ILLUSTRATIVE — FIX-P09-05. SIM-CHAIN-A / W. Gli scostamenti SIM-DAY sono etichette inventate di giorni di calendario. Finestra della query[5,31), copertura completa per la regola di trasferimento elencata tranne lacuna[15,21). Cronologia prima del giorno5 indisponibile. Termine dell’analisi giorno31.

Gli importi sono unità normalizzate di un asset fittizio. Non sono forniti campi di firmatari, record di creazione precedente o evidenze d’identità. La regola per l’attività riuscita include entrambe le direzioni, escludendo tentativi falliti.

OBSERVED nei dati didattici: I record corrispondenti riusciti avvengono nei giorni 6,10,22,29; giorno12 è un tentativo fallito; sei giorni mancano di copertura.

INFERRED: Cinque successi in quattro giorni attivi coperti; intervallo trascorso dal primo all’ultimo di 23 giorni;25 giorni dal primo successo visibile al giorno31 di analisi.

UNKNOWN: Vero momento di creazione, attività prima del giorno5/nella lacuna, iniziativa/firmatari e continuità umana.

INSUFFICIENT EVIDENCE: L’età osservata 25 non può essere riportata come età effettiva di creazione dell’account. L’intervallo mancante non può stabilire inattività; frequenza degli eventi non può provare competenza o automazione.

Trattare il record più vecchio della pagina come creazione; usare tempo null come zero; contare alternativamente giorni trascorsi e inclusivi; trasformare interruzioni della fonte in attività zero; assegnare competenza o identità dalla cadenza.

Calcolare lunghezza della finestra intera, giorni mancanti e coperti, conteggi di eventi riusciti e giorni attivi, tasso per giorno coperto e intervallo trascorso. Riscrivere «W è stato creato25 giorni fa ed è rimasto inattivo per sei giorni».

• Nominare fonte della prima osservazione e regola di attività.
• Separare eventi riusciti da tentativi/iniziative.
• Usare convenzioni esplicite degli intervalli.
• Pubblicare lacune prima dei tassi.
• Mantenere sconosciuto il tempo di calendario null.
• Evitare etichette di creazione, competenza o persona dall’età osservata.

L’età del wallet è spesso un intervallo di osservazione. Le statistiche comportamentali sono utili quando regola degli eventi e denominatore della copertura restano visibili.

Prima osservazione non è creazione. Nessun dato non significa nessuna attività. Una cadenza descrive eventi forniti, non identità o competenza di una persona.

Cronologia[5,31) con lacuna[15,21) tratteggiata UNKNOWN, marcatori di eventi/tentativi ed eventi doppi del giorno10. Mostrare26 totali/6 mancanti/20 coperti; primo 6,ultimo29,analisi31 come marcatori distinti. Non etichettare mai la prima osservazione come creazione.

Attività osservata illustrativa; i giorni sintetici non sono timestamp del registro.

Usare SVG/HTML deterministico o grafici con unità, riferimenti alle evidenze e alternative testuali. Blu navy/nero con tocchi sobri di ciano, blu elettrico e viola; nessuna schermata decorativa o inventata di explorer. A 390px impilare le annotazioni; verificare 768px, desktop e RTL arabo quando le risorse saranno implementate. Mantenere gli identificatori LTR e inalterate le direzioni fattuali del tempo, degli archi e degli assi. Usare soltanto il marchio ufficiale BlockAssay fornito. Entrambi i record visivi rimangono specifiche.

WALLET_INTELLIGENCE corrisponde all’ispezione in sola lettura di record di indirizzi pubblici, relazioni e provenienza. Verificare rete supportata, identificatori esatti, campi e copertura prima di qualsiasi integrazione a runtime; qui non si dichiara alcuna capacità di un fornitore in tempo reale. Usare l’esercizio offline incorporato se dati o accesso a pagamento non sono disponibili. Non sono richiesti connessione del wallet, credenziali, chiave privata, firma o operazione di mercato reale. I dati mancanti rimangono sconosciuti. Progressi Academy, stato di creatore, pagamenti e segnalazioni non alterano mai le evidenze Radar.

• Solana getSignaturesForAddress — Cronologia delle firme che citano l’indirizzo, ordine dal più recente e paginazione. Verificato il 2026-09-30.
• Solana getTransaction — Ricerca delle transazioni, commitment e campi dati/tempo che possono essere nulli. Verificato il 2026-09-30.
• Account Ethereum — Distinzione account/interfaccia e tipi di account. Verificato il 2026-09-30.
• EIP-7702: impostazione del codice per EOA — Delega del codice degli EOA; la sola presenza di codice non è una regola universale di classificazione degli EOA. Verificato il 2026-09-30.

Tutti i record di esempio sono dati didattici originali ILLUSTRATIVE, non misurazioni storiche o in tempo reale della catena. La documentazione spiega i meccanismi, non gli importi o le etichette inventati. La cronologia sintetica è esplicitamente delimitata; observedAt=null è intenzionale. OBSERVED in un esercizio indica un record dei dati forniti. Riesaminare documentazione e decodifica distribuita prima della pubblicazione. Le etichette dei fornitori non stabiliscono identità; controllo degli indirizzi e attribuzione umana richiedono evidenze distinte.

P09-L06 dopo l’esercizio svolto e la revisione delle domande.