Ancienneté et comportement du portefeuille

Source maître EN · P09-L05 · 45 minutes estimées · needs_review

Une page affichant « portefeuille âgé de 25 jours » peut signifier en réalité25 jours depuis le premier enregistrement retourné par un indexeur. Le compte a pu exister ou agir avant. Un graphique calme peut aussi refléter une période manquante plutôt qu’une inactivité.

Cette leçon remplace les étiquettes vagues d’âge et de comportement par des fenêtres d’observation définies, des comptes d’événements et des descriptions ajustées à la couverture. Elle ne transforme jamais l’ancienneté observée en date réelle de création ni l’activité en jugement sur une personne.

Définir précisément la première apparition

La première apparition nécessite source, requête, réseau, cible et règle d’activité. Première signature, premier transfert réussi, première action sortante et premier événement de compte de jetons peuvent survenir à des moments différents. Nommer la règle choisie avant de rapporter une ancienneté.

Les requêtes de signatures Solana retournent l’historique référençant l’adresse du plus récent au plus ancien avec pagination [S09-SIGNATURES]. La ligne retournée la plus ancienne est seulement le premier enregistrement visible selon cette requête. Même une pagination réussie n’établit pas automatiquement un préhistorique complet de tous les comptes associés ou de toute la rétention du fournisseur.

Une affirmation de création réelle de compte nécessite un mécanisme pertinent et des preuves. Une clé peut exister en privé avant d’apparaître dans les enregistrements ; l’heure de déploiement d’un contrat concerne le contrat, pas la génération de clé du créateur ou le premier portefeuille d’une personne. La création d’un compte de jetons concerne ce compte précis, pas forcément l’existence de son propriétaire.

Séparer horloges et contextes

Contexte du registre, temps d’événement rapporté, temps de capture de source et temps d’analyse diffèrent. Les réponses de transaction Solana peuvent avoir un blockTime null [S09-TRANSACTION]. Si le temps de l’événement est absent, conserver le contexte de slot sans inventer d’horodatage calendaire.

Le jeu fournit des décalages artificiels en jours calendaires pour les calculs. Aucune observation réelle d’horloge n’a été collectée et observedAt reste null. SIM-DAY6 n’est pas une date réelle encodée. Soustraire les décalages fournis donne seulement des jours écoulés synthétiques.

La durée du jour6 au jour29 est de 23 jours écoulés. Compter les extrémités calendaires étiquetées donnerait24 positions de date, une quantité différente. Préciser si l’on mesure le temps écoulé, compte les dates ou définit un intervalle semi-ouvert. Ne pas alterner les conventions pour faire paraître l’activité plus importante.

Publier la couverture avant les taux

Utiliser des fenêtres semi-ouvertes telles que [5,31) : inclure le jour5 et exclure le jour31. Cela évite le chevauchement de fenêtres adjacentes. Une lacune [15,21) retire six jours de couverture fournie. Ne pas la qualifier d’« inactive » quand la source ne l’a pas observée.

Si les intervalles couverts sont stipulés complets pour la règle choisie, nombre d’événements divisé par jours couverts est un taux descriptif ajusté à la couverture. Ce n’est pas une estimation des jours manquants. Diviser par toute la fenêtre répond à une autre question et doit être nommé explicitement.

Un taux de 0.25 événement réussi par jour couvert signifie cinq événements fournis sur vingt jours couverts. Il ne signifie pas qu’une transaction a eu lieu tous les quatre jours. Les regroupements intrajournaliers importent et l’activité n’est pas supposée uniforme.

Choisir les mesures de comportement

Compter événements réussis et tentatives séparément. Compter jours actifs distincts et événements séparément. Plusieurs transactions le même jour peuvent accroître le compte d’événements sans changer le compte de jours actifs.

Définir actif et sens. Un enregistrement de simple réception n’est pas nécessairement une initiation active de la cible. Les événements référençant l’adresse ne prouvent pas une signature. Pour mesurer les transactions initiées, il faut une preuve de signataire ou d’expéditeur plutôt qu’une simple activité impliquant l’adresse.

La variation nette de solde ne mesure pas la compétence de trading. Un portefeuille peut recevoir des allocations, effectuer des transferts ou garder des actifs pour autrui. Cette leçon utilise uniquement des comptes descriptifs, sans classification de profit, de sophistication ou de stratégie.

Traiter honnêtement les observations partielles

Un premier événement visible dans la fenêtre demandée donne un énoncé délimité : observé depuis cet événement dans le périmètre disponible. Si la couverture commence après que le compte a déjà des fonds, même le premier financement visible n’est pas une preuve complète d’origine.

L’absence de lignes dans un intervalle pleinement vérifié peut étayer « aucun événement correspondant retourné selon cette règle ». Cela n’établit pas l’absence d’activité sur un autre réseau, mint ou compte lié. Les données manquantes du fournisseur n’étayent aucune affirmation d’absence pour cet intervalle.

Ne pas extrapoler dans les lacunes. Un portefeuille sans événement retourné pendant une panne connue ne peut être décrit comme dormant pendant cette période. Le graphe doit dessiner une zone inconnue explicitement ombrée plutôt qu’une barre de hauteur nulle ressemblant à un zéro mesuré.

Éviter les étiquettes comportementales de personne

« Adopteur précoce », « bot », « trader expert » ou « nouvelle personne » nécessitent des définitions et preuves plus fortes. Les motifs temporels peuvent motiver des hypothèses sans prouver automatisation ou identité. Une cadence égale peut venir d’actions programmées d’application ou de la granularité d’indexation.

Le compte peut changer de dispositif de contrôle au fil du temps. La continuité d’activité publique ne prouve pas qu’un même humain a opéré tous les événements. Actions médiées par contrat et exécution déléguée compliquent l’hypothèse d’un utilisateur manuel unique [S09-ETHACCOUNTS; S09-DELEGATION].

Ne pas classer la fiabilité par ancienneté. Un historique observé plus ancien établit une période visible plus longue selon une source annoncée, pas l’honnêteté. Une première apparition plus récente n’établit ni utilisateur novice ni opérateur malveillant.

Rédiger une description d’activité délimitée

Un rapport utile nomme règle, fenêtre, lacunes, premier et dernier événements correspondants visibles, compte et convention temporelle. Énoncer ensuite explicitement les limites de création et de contrôle.

Préférer « cinq événements réussis de transfert référencés sur quatre jours actifs couverts ; préhistorique et six jours manquants non résolus » à « portefeuille actif expérimenté ». Le premier est reproductible et permet un recalcul ultérieur avec une meilleure couverture.

• Première apparition : premier événement correspondant visible selon une source/règle précisée.
• Durée observée : temps écoulé entre premiers et derniers événements fournis.
• Jour couvert : jour inclus dans le périmètre vérifié du jeu.
• Jour actif : date couverte avec événement correspondant.
• Fenêtre semi-ouverte : inclut le début, exclut la fin.
• Taux descriptif : compte divisé par un dénominateur d’observation annoncé.

ILLUSTRATIVE — FIX-P09-05. SIM-CHAIN-A / W. Les décalages SIM-DAY sont des étiquettes inventées de jours calendaires. Fenêtre de requête[5,31), couverture complète pour la règle de transfert listée sauf lacune[15,21). Historique avant jour5 indisponible. Arrêt d’analyse jour31.

Montants en unités normalisées d’un actif fictif unique. Aucun champ de signataire, enregistrement de création antérieure ou preuve d’identité n’est fourni. La règle d’activité réussie inclut les deux sens et exclut les tentatives échouées.

OBSERVED dans le jeu : les enregistrements de réussite correspondants surviennent aux jours 6,10,22,29 ; jour12 est une tentative échouée ; six jours manquent de couverture.

INFERRED : cinq réussites sur quatre jours actifs couverts ; durée écoulée du premier au dernier de 23 jours ;25 jours depuis la première réussite visible au jour d’analyse31.

UNKNOWN : véritable création, activité avant jour5/dans la lacune, initiation/signataires et continuité humaine.

INSUFFICIENT EVIDENCE : l’ancienneté observée 25 ne peut être présentée comme âge réel de création du compte. Un intervalle manquant n’établit pas d’inactivité ; la fréquence des événements ne prouve ni expertise ni automatisation.

Traiter le plus ancien enregistrement de page comme création ; utiliser un temps null comme zéro ; interchanger jours écoulés et inclusifs ; transformer les pannes de source en activité nulle ; attribuer compétence ou identité à partir de la cadence.

Calculer longueur totale de fenêtre, jours manquants et couverts, événements réussis et jours actifs, taux par jour couvert et durée écoulée. Réécrire « W a été créé25 jours avant et est resté inactif six jours ».

• Nommer source de première apparition et règle d’activité.
• Séparer événements réussis, tentatives et initiations.
• Utiliser des conventions explicites d’intervalle.
• Publier les lacunes avant les taux.
• Garder un temps calendaire null inconnu.
• Éviter les étiquettes de création, de compétence ou de personne tirées de l’âge observé.

L’ancienneté d’un portefeuille est souvent un intervalle d’observation. Les statistiques comportementales sont utiles lorsque leur règle d’événement et leur dénominateur de couverture restent visibles.

La première apparition n’est pas la création. Aucune donnée ne signifie pas aucune activité. Une cadence décrit les événements fournis, pas l’identité ou la compétence d’une personne.

Chronologie[5,31) avec lacune[15,21) hachurée UNKNOWN, marqueurs d’événement/tentative et événements doublés au jour10. Montrer26 au total/6 manquants/20 couverts ; premier 6,dernier29,analyse31 comme marqueurs distincts. Ne jamais étiqueter la première apparition comme création.

Activité observée illustrative ; les jours synthétiques ne sont pas des horodatages du registre.

Utiliser du SVG/HTML déterministe ou des graphiques avec unités, repères de preuve et alternatives textuelles. Bleu marine/noir avec touches discrètes de cyan, bleu électrique et violet ; aucune capture d’explorateur décorative ou fabriquée. À 390px, empiler les annotations ; vérifier 768px, l’ordinateur et le RTL arabe lorsque les actifs seront réalisés. Conserver les identifiants LTR et les sens factuels du temps/des arêtes/des axes. Utiliser uniquement la marque officielle BlockAssay fournie. Les deux enregistrements visuels restent des spécifications.

WALLET_INTELLIGENCE correspond à l’inspection en lecture seule des enregistrements d’adresses publiques, des relations et de leur provenance. Vérifier le réseau pris en charge, les identifiants exacts, les champs et la couverture avant toute intégration à l’exécution ; aucune capacité de fournisseur en direct n’est revendiquée ici. Utiliser l’exercice hors ligne intégré si les données ou l’accès payant sont indisponibles. Aucune connexion de portefeuille, aucun identifiant de connexion, aucune clé privée, signature ou transaction de marché réelle n’est requis. Les données manquantes restent inconnues. La progression Academy, le statut de créateur, les paiements et les parrainages ne modifient jamais les preuves Radar.

• Solana getSignaturesForAddress — Historique des signatures référençant l’adresse, ordre du plus récent au plus ancien et pagination. Vérifié le 2026-09-30.
• Solana getTransaction — Recherche de transaction, engagement de confirmation et champs de données/temps pouvant être nuls. Vérifié le 2026-09-30.
• Comptes Ethereum — Distinction compte/interface et types de comptes. Vérifié le 2026-09-30.
• EIP-7702 : définition de code pour les EOA — Délégation de code des EOA ; la seule présence de code n’est pas une règle universelle de classification des EOA. Vérifié le 2026-09-30.

Tous les enregistrements d’exemple sont des jeux originaux ILLUSTRATIVE, pas des mesures historiques/en direct de la chaîne. La documentation explique les mécanismes, pas les montants ou étiquettes inventés. La chronologie synthétique est explicitement délimitée ; observedAt=null est intentionnel. OBSERVED dans un exercice désigne un enregistrement du jeu fourni. Réexaminer la documentation et le décodage déployé avant publication. Les étiquettes de fournisseur n’établissent pas l’identité ; le contrôle d’une adresse et l’attribution humaine nécessitent des preuves distinctes.

P09-L06 après l’exercice corrigé et la révision des questions.