Deployer und erste Käufer

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

Lernziele:

• Gebührenzahler, Initialisierer, Berechtigung und Zuweisungsempfänger getrennt abbilden.
• Erfolgreiche frühe Käufe anhand von Ausführungsergebnissen und Wirkungen identifizieren.
• Früheste sichtbare Käufer mit ausdrücklichen Abdeckungs- und Zuschreibungsgrenzen berichten.

Eine Starttransaktion kann Gebührenzahler, Mint-Initialisierer, Berechtigungsadresse, Programm und mehrere Empfängerkonten umfassen. Eine Adresse „den Deployer“ zu nennen, kann diese Rollen verdecken. Ebenso bedeutet früher Tokenempfang nicht zwingend einen Kauf. Diese Lektion vermittelt eine transaktionsgestützte Rollenkarte und eine sorgfältig begrenzte Frühkäuferliste.

Eine vage Bezeichnung durch spezifische Rollen ersetzen

„Deployer“ vor der Verwendung definieren. Bei einem Solana-Memecoin könnten Sie das für die Initialisierung zahlende Konto, den Unterzeichner der Emissionsgenehmigung oder den Launchpad-nutzenden Betreiber meinen. Diese Rollen müssen nicht identisch sein. Solanas Dokumentation trennt Mint Authority ausdrücklich vom Konto, das die Mint erstellt oder bezahlt [S-TOKENS]. Eine Rolle kann zudem durch ein Programm vermittelt werden, statt ein menschliches Konto offenzulegen.

Rollenbezeichnungen verwenden, die die tatsächlichen Belege beschreiben: Gebührenzahler, Mint-Initialisierer, Mint Authority, Zuweisungsempfänger, poolfinanzierendes Konto und Swap-Empfänger. Ein Berechtigungsfeld ist eine Erlaubnis bei einer angegebenen Beobachtung, kein Beweis dafür, wer eine Website baute. Eine Adresse kann mehrere Rollen haben, aber jede Beziehung benötigt einen Belegverweis.

Eine „Ersteller“-Markierung im Explorer kann eine praktische Indexerinterpretation sein. Mit relevanter Instruktion und Zustand vergleichen. Können Sie diese Aufzeichnungen nicht prüfen, die Markierung als Quellenerklärung statt verifizierter Rolle berichten. Zweck ist nicht, jedem Indexer zu misstrauen, sondern die Abhängigkeit sichtbar zu machen.

Instruktionsabsicht von erfolgreichen Wirkungen trennen

Eine Transaktion kann eine Swap-Instruktion enthalten und dennoch scheitern. Ein Empfänger kann Token durch Zuweisung, Transfer oder Swap erhalten. Ausführungsergebnis und Saldoänderungen prüfen, bevor erfolgreiche Trades gezählt werden. Solana-Transaktionsabfragen enthalten Ergebnismetadaten und können null liefern, wenn ein Datensatz beim angeforderten Commitment nicht verfügbar ist [S-TRANSACTION]. Null beweist nicht, dass eine Adresse nie handelte.

Nettosalden können ohne Instruktionskontext irreführen. Eine Transaktion kann Kontoerstellung, Transfer, Gebühren und Tausch kombinieren. Tokenempfang ist nur eine Beobachtung; ein wirtschaftlicher Kauf benötigt auch Belege für einen Tauschmechanismus und den entsprechend bezahlten Vermögenswert. Netto- und Bruttobeträge ausdrücklich dokumentieren, wenn zwischenzeitliche Bewegungen beteiligt sind.

Eine gescheiterte Transaktion kann weiterhin belegen, dass ein Versuch stattfand, und Gebühren können relevant bleiben. Sie ist kein erfolgreicher Kauf. Versuchstabelle von erfolgreicher Kauftabelle trennen. Dies erhält die Startaufzeichnungen, ohne die Rangfolge zu verunreinigen.

„Erster Käufer“ auf den tatsächlich durchsuchten Umfang begrenzen

Für die Aussage „erster“ Handelsplatz, Vermögenswert, Ereignistyp, Beobachtungsbereich, Reihenfolgekonvention und historische Abdeckung angeben. Ein Launchpad-Kauf und ein späterer Poolkauf können zu unterschiedlichen Rangfolgen gehören. Eine früheste sichtbare Aufzeichnung im Fenster eines Anbieters ist nicht automatisch der früheste Trade auf der Chain.

Die Signaturhistorie einer Adresse kann paginiert werden und wird normalerweise mit neuesten Einträgen zuerst geliefert [S-SIGNATURES]. Ein Forscher darf den ersten zurückgegebenen Eintrag nicht als allererstes Ereignis interpretieren. Auch Abdeckung referenzierter Adressen garantiert nicht, dass die Prüfung einer einzigen Adresse jede relevante Transaktion erfasst. Mint, Markt, Programm und zugehörige Konten können unterschiedliche Indexierungsanforderungen haben.

Slots und angezeigte Zeitstempel sind getrennte Reihenfolgehilfen. Mehrere Ereignisse können dieselbe angezeigte Sekunde teilen. Die Zeitstempelgranularität eines Indexers kann Reihenfolge verbergen; Transaktionsindizes verwenden, wenn verfügbar, und andernfalls Unsicherheit erhalten. Ist die Reihenfolge ungeklärt, eine frühe Kohorte berichten, statt einen eindeutigen ersten Käufer zu erfinden.

Frühes Verhalten ohne Motivableitung interpretieren

Eine früh handelnde Adresse kann ein automatisierter Händler, ein Teilnehmer mit Beobachtung öffentlicher Startereignisse, ein Market Maker oder jemand mit privilegierten Informationen sein. Zeitpunkt allein unterscheidet diese Erklärungen nicht. Eine Verbindung zu einer poolfinanzierenden Adresse kann weitere Untersuchung rechtfertigen, löst aber gemeinsame menschliche Eigentümerschaft nicht auf.

Ein nützlicher Bericht hat zwei Ebenen. Die erste ist eine faktische Rollen-/Transaktionstabelle. Die zweite ein begrenztes Hypothesenregister mit möglichen Interpretationen und Belegen, die sie stärken oder schwächen würden. Eine Hypothese nicht stillschweigend zur überall sonst angezeigten Adressbezeichnung erheben.

Diese Grenzen machen frühe Aktivität nicht irrelevant. Sie machen die Schlussfolgerung prüfbar. „Adresse B1 erhielt 10,000 Einheiten im ersten erfolgreichen Kauf im vorgegebenen Handelsplatzfenster“ ist präzise. „Der Ersteller kaufte heimlich zuerst“ führt eine Identitäts-, Motiv- und Zugangsaussage ein, die mehr als die Transaktion allein erfordert.

• Gebührenzahler: Konto, das die Netzwerkgebühr der Transaktion bezahlt.
• Berechtigung: Konto, das einen bestimmten Vorgang genehmigen darf.
• Zuweisungsempfänger: Konto, das verteilte Einheiten ohne Kaufbelege erhält.
• Erfolgreicher Kauf: verifizierter Tausch mit erfolgreichem Ergebnis und relevanten Wirkungen.
• Abdeckungsfenster: tatsächlich geprüfte begrenzte Historie.
• Rollenzuschreibung: einer Adresse eine beobachtete operative Rolle zuordnen.

ILLUSTRATIVE BEISPIEL — FIX-P07-05. Die sechs Zeilen bilden einen vollständigen Datensatz für VENUE-A zwischen relativem T+0 und T+5. IDs und Mengen sind fiktiv.

Diese Handelswirkungen sind vorgegebene fiktive Aufzeichnungen, keine aus dem Pool von Lektion 3 abgeleiteten Ausgaben. Hier wird kein Reservemodell vorgegeben; keines importieren.

OBSERVED: Der Datensatz weist F, C und A unterschiedliche Initialisierungsrollen zu. B1 hat den frühesten erfolgreichen Kauf im vorgegebenen VENUE-A-Fenster und erscheint zweimal.

INFERRED: Eine Rollenkarte ist eine nützliche Darstellung dieser beobachteten Beziehungen; sie identifiziert nicht ihre letztlichen menschlichen Kontrolleure.

UNKNOWN: Frühere Handelsplätze/Ereignisse außerhalb des Datensatzes, menschliche Eigentümerschaft, private Kommunikation und Zugangsprivilegien.

INSUFFICIENT EVIDENCE: Die Zuweisung an R ist kein Kauf. BUY-FAIL ist kein erfolgreicher Kauf. Der Zeitpunkt von B1 kann weder Insiderzugang noch Beziehung zu C belegen.

Gebührenzahler mit Ersteller gleichsetzen; Zuweisungsempfänger als ersten Käufer auflisten; gescheiterte Ergebnisse ignorieren; Transaktionen als verschiedene Käufer zählen; neueste-zuerst-Aufzeichnungen rückwärts interpretieren; und aus dem Startzeitpunkt einen menschlichen Insider benennen.

Die Initialisierungsrollenkarte erstellen und erfolgreiche Kaufereignisse im vorgegebenen Fenster ordnen. Verschiedene erfolgreiche Käuferadressen zählen, Quotierungsausgaben und Tokenempfang von B1 summieren und „B1 war der erste Insiderkäufer des Projekts“ umformulieren.

• Jede operative Rolle ausdrücklich definieren.
• Ergebnis, Instruktion und relevante Saldoeffekte prüfen.
• Zuweisung, Transfer, Versuch und erfolgreichen Tausch trennen.
• Handelsplatz-/Zeit-/Historienabdeckung für jede „erster“-Aussage angeben.
• Eindeutige Adressen getrennt von Transaktionsereignissen zählen.

Eine Startuntersuchung sollte getrennte Rollen und erfolgreiche Wirkungen erhalten. „Erster Käufer“ ist nur innerhalb eines dokumentierten Suchumfangs sinnvoll, und eine frühe Adresse ist nicht automatisch Ersteller oder Insider.

Rollenkarten statt einer mehrdeutigen Deployer-Bezeichnung verwenden. Gescheiterte Versuche getrennt erhalten. Zeitpunkt stützt Chronologie, kein Motiv.

INIT-A-Rollen als beschriftete Kanten zu einem Mint-Knoten darstellen; einen getrennten Ereigniszeitstrahl für Zuweisung, gescheiterten Versuch und erfolgreiche Swaps verwenden. B1 wiederholt zeigen, ohne einen neuen Adressknoten zu erzeugen. Quotierungs- und Tokenwirkungen aus dem Datensatz und eine sichtbare VENUE-A-Abdeckungsgrenze anfügen.

Vorgaben für die visuelle Umsetzung: Dunkles Marineblau/Schwarz, Akzente in Cyan/leuchtendem Blau/Violett, Einheiten und Unsicherheit ausdrücklich beschriften. Deterministische Diagramme oder SVG verwenden, keine erfundenen Screenshots. Bei 390 px Annotationen untereinander anordnen und die Datentabelle als Textalternative bereitstellen; 768 px und Desktop später prüfen. Für Arabisch Beschriftungen und Anordnung mit muttersprachlichem RTL lokalisieren, Adressen/Hashes dabei LTR isolieren und die tatsächliche Transferrichtung und Chronologie erhalten. Falls Branding ergänzt wird, nur das vorgegebene offizielle BlockAssay-Logo verwenden. Kein visuelles Element oder mobiles/RTL-Rendering wird als fertig behauptet.

WALLET_INTELLIGENCE nur verwenden, wenn das genaue Netzwerk, der Vermögenswert und die benötigten Felder unterstützt werden und ihre Herkunft sichtbar ist. Dies ist eine rein lesende didaktische Prüfung, kein Handel oder Tokenstart. Den vorgegebenen Offline-Datensatz verwenden, falls Zugang oder Daten nicht verfügbar sind; fehlende Informationen bleiben unbekannt. Eine künftige Aktion „In BlockAssay öffnen“ benötigt validierte Laufzeitweiterleitung und Quellenabdeckung. Für illustrative Kennungen wird kein ausführbarer Vermögenswert-CTA bereitgestellt. Academy-Teilnahme und kommerzieller Status ändern niemals Radar-Beobachtungen.

• Solana-Vermögenswerte: Mints und Tokenkonten — Mint-Identität, Tokenkonto-Eigentümerschaft und getrennte Mint-/Erstellungsrollen. Geprüft 2026-09-30.
• Solana getTransaction — Abfrage bestätigter Transaktionen und Transaktions-/Zeit-/Metadatenergebnisse, die null sein können. Geprüft 2026-09-30.
• Solana getSignaturesForAddress — Signaturen mit referenzierter Adresse, neueste zuerst, und Paginierungsparameter. Geprüft 2026-09-30.
• Solana-RPC-JSON-Strukturen — Transaktionsunterzeichner, Instruktionen und Saldo-/Ergebnismetadaten. Geprüft 2026-09-30.

Die Tabellen und Übungsdatensätze sind eigenes Lehrmaterial, sofern nicht ausdrücklich als HISTORICAL bezeichnet. Fiktive Kennungen sind bewusst als Blockchain-Adressen ungültig. Dokumentation stützt Mechanismusdefinitionen, nicht die erfundenen Übungswerte. Quellenprüfung ist redaktionelle Recherche, keine Live-Chain-Messung. Quellen können sich ändern; vor Veröffentlichung erneut prüfen.

P07-L06; nach Abschluss der Übung und Prüfung jeder Quizerklärung fortfahren.