Wallet-Alter und Verhalten

EN-Quellmaster · P09-L05 · 45 Minuten geschätzt · needs_review

Eine Seite mit „Wallet-Alter 25 Tage“ kann tatsächlich25 Tage seit dem frühesten von einem Indexer zurückgegebenen Datensatz meinen. Das Konto könnte früher existiert oder gehandelt haben. Ein ruhiger Chart kann auch ein fehlendes Intervall statt Inaktivität widerspiegeln.

Diese Lektion ersetzt vage Alters- und Verhaltensbezeichnungen durch definierte Beobachtungsfenster, Ereigniszahlen und abdeckungsbereinigte Beschreibungen. Sie macht niemals aus beobachtetem Alter tatsächliche Erstellungszeit oder aus Aktivität ein Urteil über eine Person.

Erstsichtung präzise definieren

Erstsichtung erfordert Quelle, Abfrage, Netzwerk, Ziel und Aktivitätsregel. Erste Signatur, erster erfolgreicher Transfer, erste ausgehende Handlung und erstes Tokenkontoereignis können an verschiedenen Punkten auftreten. Vor Altersangabe die gewählte Regel benennen.

Solana-Signaturabfragen liefern referenzierten Adressverlauf mit neuesten Einträgen zuerst und Seitennavigation [S09-SIGNATURES]. Die älteste zurückgegebene Zeile ist nur der früheste sichtbare Datensatz unter dieser Abfrage. Auch erfolgreiche Seitennavigation belegt nicht automatisch vollständige Vorgeschichte für jedes zugehörige Konto oder jeden Aufbewahrungszeitraum eines Anbieters.

Eine tatsächliche Kontoerstellungsaussage braucht einen relevanten Mechanismus und Evidenz. Ein Schlüssel kann privat existieren, bevor er je in Datensätzen erscheint; eine Vertragsbereitstellungszeit betrifft den Vertrag, nicht die Schlüsselerzeugung seines Erstellers oder die erste Wallet einer Person. Die Erstellungszeit eines Tokenkontos betrifft dieses konkrete Konto, nicht zwingend die Existenz seines Eigentümers.

Zeitmessungen und Kontexte trennen

Ledgerkontext, berichtete Ereigniszeit, Quellenerfassungszeit und Analysezeit sind verschieden. Solana-Transaktionsantworten können null blockTime haben [S09-TRANSACTION]. Bei fehlender Ereigniszeit Slotkontext erhalten, ohne einen Kalenderzeitstempel zu erfinden.

Die Fixture liefert künstliche Kalendertagabstände für Rechnungen. Es wurden keine realen Uhrzeitbeobachtungen erhoben; observedAt bleibt null. SIM-DAY6 ist kein kodiertes reales Datum. Subtraktion bereitgestellter Abstände ergibt nur synthetisch verstrichene Tage.

Eine Spanne von Tag6 bis Tag29 beträgt 23 verstrichene Tage. Das Zählen beschrifteter Kalenderendpunkte ergäbe24 Datumspositionen, eine andere Menge. Angeben, ob verstrichene Zeit gemessen, Datumswerte gezählt oder ein halboffenes Intervall definiert wird. Konventionen nicht wechseln, um Aktivität größer erscheinen zu lassen.

Vor Raten die Abdeckung veröffentlichen

Halboffene Fenster wie [5,31) verwenden: Tag5 einschließen, Tag31 ausschließen. Dadurch überlappen benachbarte Fenster nicht. Eine Lücke [15,21) entfernt sechs Tage bereitgestellter Abdeckung. Diese Lücke nicht „inaktiv“ nennen, wenn die Quelle sie nicht beobachtete.

Gelten abgedeckte Intervalle für die gewählte Regel als vollständig, ist Ereigniszahl geteilt durch abgedeckte Tage eine abdeckungsbereinigte beschreibende Rate. Sie schätzt nicht, was an fehlenden Tagen geschah. Division durch das gesamte Fenster beantwortet eine andere Frage und sollte ausdrücklich benannt werden.

Eine Rate von 0.25 erfolgreichen Ereignissen je abgedecktem Tag bedeutet fünf bereitgestellte Ereignisse über zwanzig abgedeckte Tage. Sie bedeutet nicht, dass jeden vierten Tag eine Transaktion stattfand. Häufung innerhalb von Tagen ist relevant; gleichmäßige Aktivität wird nicht angenommen.

Verhaltensmaße wählen

Erfolgreiche Ereignisse getrennt von Versuchen zählen. Unterschiedliche aktive Tage getrennt von Ereignissen zählen. Mehrere Transaktionen an einem Tag können eine hohe Ereigniszahl erzeugen, ohne die Zahl aktiver Tage zu ändern.

Vermögenswert und Richtung definieren. Ein reiner Empfangsdatensatz ist nicht zwingend aktive Einleitung durch das Ziel. Ereignisse mit Adressreferenz belegen keine Signatur. Fragt das Verhaltensmaß nach initiierten Transaktionen, braucht es Signierer- oder Senderevidenz statt bloßer Aktivität mit der Adresse.

Nettosaldoänderung kann kein Handelskönnen messen. Eine Wallet kann Zuteilungen empfangen, Transfers ausführen oder Vermögenswerte für andere verwahren. Diese Lektion verwendet nur beschreibende Zahlen, ohne Gewinn-, Kompetenz- oder Strategieklassifizierung.

Teilbeobachtungen ehrlich behandeln

Ein erstes sichtbares Ereignis innerhalb des angefragten Fensters ergibt eine begrenzte Aussage: seit diesem Ereignis im verfügbaren Umfang beobachtet. Beginnt Abdeckung, nachdem das Konto bereits Mittel hatte, ist selbst die erste sichtbare Finanzierung keine vollständige Ursprungsevidenz.

Keine Zeilen in einem vollständig verifizierten Intervall können „keine passenden Ereignisse gemäß dieser Regel zurückgegeben“ stützen. Dies belegt dennoch keine fehlende Aktivität auf anderem Netzwerk, anderer Mint oder zugehörigem Konto. Fehlende Anbieterdaten stützen keine solche Abwesenheitsbehauptung auf Intervallebene.

Nicht in Lücken extrapolieren. Eine Wallet ohne zurückgegebene Ereignisse während eines bekannten Ausfalls kann dann nicht als ruhend beschrieben werden. Ein Graph sollte eine ausdrückliche schattierte unbekannte Region zeichnen, statt eines Balkens mit Höhe null, der wie eine gemessene Null aussieht.

Personenbezogene Verhaltensbezeichnungen vermeiden

„Früher Anwender“, „Bot“, „erfahrener Händler“ oder „neue Person“ erfordern stärkere Definitionen und Evidenz. Zeitmuster können Hypothesen anregen, belegen jedoch weder Automatisierung noch Identität. Gleichmäßige Taktung kann durch geplante Anwendungshandlungen oder Indexierungsgranularität entstehen.

Ein Konto kann seine Kontrollanordnung über die Zeit ändern. Kontinuität öffentlicher Aktivität belegt nicht, dass derselbe Mensch jedes Ereignis ausführte. Vertragsvermittelte Handlungen und delegierte Ausführung erschweren die Annahme eines einzelnen manuellen Nutzers [S09-ETHACCOUNTS; S09-DELEGATION].

Vertrauenswürdigkeit nicht nach Alter ordnen. Ein älterer beobachteter Verlauf belegt einen längeren sichtbaren Zeitraum unter einer angegebenen Quelle, keine Ehrlichkeit. Eine neuere Erstsichtung belegt weder einen Anfänger noch einen böswilligen Betreiber.

Eine begrenzte Aktivitätsbeschreibung schreiben

Ein nützlicher Bericht benennt Regel, Fenster, Lücken, erste und letzte sichtbare passende Ereignisse, Zahl und Zeitkonvention. Dann Erstellungs- und Kontrollgrenzen ausdrücklich angeben.

„Fünf erfolgreiche referenzierte Transferereignisse über vier abgedeckte aktive Tage; Vorgeschichte und sechs fehlende Tage ungeklärt“ gegenüber „eine erfahrene aktive Wallet“ bevorzugen. Ersteres ist reproduzierbar. Ein späterer Prüfer kann nach besserer Abdeckung außerdem neu berechnen.

• Erstsichtung: frühestes passendes Ereignis, das unter angegebener Quelle/Regel sichtbar ist.
• Beobachtete Spanne: verstrichene Zeit zwischen erstem und letztem bereitgestellten Ereignis.
• Abgedeckter Tag: Tag im verifizierten Umfang des Datensatzes.
• Aktiver Tag: abgedecktes Datum mit passendem Ereignis.
• Halboffenes Fenster: schließt Beginn ein, Ende aus.
• Beschreibende Rate: Zahl geteilt durch angegebenen Beobachtungsnenner.

ILLUSTRATIVE — FIX-P09-05. SIM-CHAIN-A / W. SIM-DAY-Abstände sind erfundene Kalendertagbezeichnungen. Abfragefenster[5,31), Abdeckung für die aufgeführte Transferregel vollständig außer Lücke[15,21). Vorgeschichte vor Tag5 nicht verfügbar. Analysestichtag Tag31.

Beträge sind normalisierte Einheiten eines fiktiven Vermögenswerts. Keine Signiererfelder, früheren Erstellungsdatensätze oder Identitätsevidenz sind bereitgestellt. Die Regel für erfolgreiche Aktivität schließt beide Richtungen ein, fehlgeschlagene Versuche aus.

OBSERVED in der Fixture: Passende Erfolgsdatensätze treten an Tagen 6,10,22,29 auf; Tag12 ist ein fehlgeschlagener Versuch; sechs Tagen fehlt Abdeckung.

INFERRED: Fünf Erfolge über vier aktive abgedeckte Tage; verstrichene Spanne vom ersten zum letzten Ereignis 23 Tage;25 Tage seit erstem sichtbaren Erfolg am Analysetag31.

UNKNOWN: Tatsächliche Erstellungszeit, Aktivität vor Tag5/in der Lücke, Einleitung/Signierende und menschliche Kontinuität.

INSUFFICIENT EVIDENCE: Beobachtetes Alter 25 kann nicht als tatsächliches Kontoerstellungsalter berichtet werden. Fehlendes Intervall belegt keine Inaktivität; Ereignishäufigkeit belegt weder Expertise noch Automatisierung.

Ältesten Seitendatensatz als Erstellung behandeln; null-Zeit als null verwenden; verstrichene und inklusive Tage austauschbar zählen; Quellenausfälle in Nullaktivität verwandeln; und Können oder Identität aus Taktung zuordnen.

Volle Fensterlänge, fehlende und abgedeckte Tage, erfolgreiche Ereignis- und aktive Tageszahlen, Rate je abgedecktem Tag und verstrichene Spanne berechnen. „W wurde vor25 Tagen erstellt und blieb sechs Tage inaktiv“ umformulieren.

• Erstsichtungsquelle und Aktivitätsregel benennen.
• Erfolgreiche Ereignisse von Versuchen/Einleitungen trennen.
• Ausdrückliche Intervallkonventionen verwenden.
• Lücken vor Raten veröffentlichen.
• Kalenderzeit null unbekannt halten.
• Erstellungs-, Könnens- oder Personenbezeichnungen aus beobachtetem Alter vermeiden.

Wallet-Alter ist oft ein Beobachtungsintervall. Verhaltensstatistiken sind nützlich, wenn ihre Ereignisregel und ihr Abdeckungsnenner sichtbar bleiben.

Erstsichtung ist nicht Erstellung. Keine Daten bedeutet nicht keine Aktivität. Eine Taktung beschreibt bereitgestellte Ereignisse, nicht Identität oder Können einer Person.

Zeitachse[5,31) mit schraffierter Lücke[15,21) UNKNOWN, Ereignis-/Versuchsmarkierungen und doppelten Tag10-Ereignissen. Insgesamt26 Tage/6 fehlend/20 abgedeckt zeigen; erster 6,letzter29,Analyse31 als unterschiedliche Markierungen. Erstsichtung niemals als Erstellung bezeichnen.

Illustrative beobachtete Aktivität; synthetische Tage sind keine Ledgerzeitstempel.

Deterministisches SVG/HTML oder Diagramme mit Einheiten, Evidenzverweisen und Textalternativen verwenden. Marineblau/Schwarz mit zurückhaltendem Cyan, elektrischem Blau und Violett; keine dekorativen oder erfundenen Explorer-Screenshots. Bei 390px Anmerkungen stapeln; bei Umsetzung der Assets 768px, Desktop und arabisches RTL prüfen. Kennungen LTR und sachliche Zeit-, Kanten- und Achsenrichtungen unverändert lassen. Nur das offiziell bereitgestellte BlockAssay-Zeichen verwenden. Beide visuellen Datensätze bleiben Spezifikationen.

WALLET_INTELLIGENCE entspricht der ausschließlich lesenden Prüfung öffentlicher Adressdatensätze, Beziehungen und Herkunft. Unterstütztes Netzwerk, genaue Kennungen, Felder und Abdeckung vor jeder Laufzeitintegration prüfen; hier wird keine Live-Fähigkeit eines Anbieters behauptet. Bei fehlenden Daten oder kostenpflichtigem Zugang die eingebettete Offline-Übung verwenden. Wallet-Verbindung, Zugangsdaten, privater Schlüssel, Signatur oder Live-Handel sind nicht erforderlich. Fehlende Daten bleiben unbekannt. Academy-Fortschritt, Creator-Status, Zahlungen und Empfehlungen ändern niemals die Radar-Evidenz.

• Solana getSignaturesForAddress — Signaturverlauf für referenzierte Adressen, Reihenfolge mit neuesten Einträgen zuerst und Seitennavigation. Geprüft am 2026-09-30.
• Solana getTransaction — Transaktionsabfrage, Commitment und Daten-/Zeitfelder, die null sein können. Geprüft am 2026-09-30.
• Ethereum-Konten — Unterscheidung zwischen Konto und Oberfläche sowie Kontotypen. Geprüft am 2026-09-30.
• EIP-7702: Code für EOAs festlegen — Codedelegation bei EOAs; das Vorhandensein von Code allein ist keine universelle Regel zur EOA-Klassifizierung. Geprüft am 2026-09-30.

Alle Beispieldatensätze sind originale ILLUSTRATIVE Fixtures, keine historischen oder aktuellen Chain-Messungen. Die Dokumentation erklärt Mechanismen, keine erfundenen Beträge oder Bezeichnungen. Die synthetische Chronologie ist ausdrücklich begrenzt; observedAt=null ist beabsichtigt. OBSERVED bezeichnet in einer Übung einen bereitgestellten Fixture-Datensatz. Dokumentation und eingesetzte Dekodierung vor Veröffentlichung erneut prüfen. Anbieterbezeichnungen belegen keine Identität; Adresskontrolle und menschliche Zuordnung erfordern getrennte Evidenz.

P09-L06 nach der ausgearbeiteten Übung und der Fragenprüfung.