Deployer and first buyers

EN source master · P07-L05 · 45 minutes estimated · needs_review

Learning objectives:

• Map fee payer, initializer, authority and allocation recipient separately.
• Identify successful early buys from execution results and effects.
• Report earliest visible buyers with explicit coverage and attribution limits.

A launch transaction can involve a fee payer, a mint initializer, an authority address, a program and several recipient accounts. Calling one address “the deployer” can obscure these roles. Similarly, receiving tokens early does not necessarily mean buying them. This lesson teaches a transaction-backed role map and a carefully scoped list of early buyers.

Replace one vague label with specific roles

Define “deployer” before using it. For a Solana memecoin, you may mean the account paying for initialization, the signer authorizing issuance or the operator using a launchpad. Those roles need not be the same. Solana documentation explicitly separates the mint authority from the account creating or paying for the mint [S-TOKENS]. A role can also be mediated by a program rather than reveal a human account.

Use role labels that describe the actual evidence: fee payer, mint initializer, mint authority, allocation recipient, pool-funding account and swap recipient. An authority field is a permission at a stated observation, not proof of who built a website. An address may hold several roles, but each relationship requires an evidence pointer.

An explorer's “creator” tag may be a convenient indexer interpretation. Compare it with the relevant instruction and state. If you cannot inspect those records, report the label as a source declaration rather than a verified role. The purpose is not to distrust every indexer; it is to make the dependence visible.

Separate instruction intent from successful effects

A transaction can contain a swap instruction but fail. A recipient can get tokens through allocation, transfer or swap. Review execution result and balance changes before counting successful trades. Solana transaction lookup includes result metadata and can return null when a record is unavailable at the requested commitment [S-TRANSACTION]. Null does not prove that an address never acted.

Net balances can be misleading without instruction context. A transaction may combine an account creation, a transfer, fees and an exchange. Receiving tokens is only one observation; an economic purchase also needs evidence of an exchange mechanism and the corresponding paid asset. Record net versus gross amounts explicitly if intermediate movements are involved.

A failed transaction can still be evidence that an attempt occurred, and fees can remain relevant. It is not a successful purchase. Separate an attempts table from the successful-buy table. This keeps the launch record intact without contaminating the ranking.

Scope “first buyer” to what you actually searched

To claim “first,” state the venue, asset, event type, observation range, ordering convention and history coverage. A launchpad buy and a later pool buy can belong to different rankings. An earliest visible record in one provider's window is not automatically the earliest trade on the chain.

Address signature history can be paginated and is normally returned newest first [S-SIGNATURES]. A researcher must not interpret the first returned item as the first-ever event. Referenced-address coverage also does not guarantee every relevant transaction is captured by inspecting a single address. A mint, market, program and associated accounts may have different indexing needs.

Slots and displayed timestamps are distinct ordering aids. Several events may share a displayed second. An indexer's timestamp granularity can hide order; use transaction indices when available and preserve uncertainty otherwise. If order is unresolved, report an early cohort instead of inventing a unique first buyer.

Interpret early behavior without inferring motive

An address acting early can be an automated trader, a participant monitoring public launch events, a market maker or someone with privileged information. Timing alone does not discriminate among these explanations. A link to a pool-funding address may justify further investigation but does not resolve common human ownership.

A useful report has two layers. The first is a factual role/transaction table. The second is a bounded hypothesis register, naming possible interpretations and what evidence would strengthen or weaken them. Do not silently promote a hypothesis into the address label shown everywhere else.

These limits do not make early activity irrelevant. They make the conclusion testable. “Address B1 received 10,000 units in the first successful buy in the supplied venue window” is precise. “The creator secretly bought first” introduces an identity, motive and access claim requiring more than the transaction alone.

• Fee payer: account paying the transaction's network fee.
• Authority: account permitted to authorize a specific operation.
• Allocation recipient: account receiving distributed units without purchase evidence.
• Successful buy: a verified exchange with a successful result and relevant effects.
• Coverage window: the bounded history actually inspected.
• Role attribution: attaching an observed operational role to an address.

ILLUSTRATIVE EXAMPLE — FIX-P07-05. The six rows are a complete fixture for VENUE-A between relative T+0 and T+5. IDs and quantities are fictional.

These trade effects are supplied fictional records, not outputs derived from lesson 3's pool. No reserve model is supplied here; do not import one.

OBSERVED: The fixture assigns different initialization roles to F, C and A. B1 has the earliest successful buy in the supplied VENUE-A window and appears twice.

INFERRED: A role map is a useful representation of these observed relationships; it does not identify their ultimate human controllers.

UNKNOWN: Earlier venues/events outside the fixture, human ownership, private communications and access privileges.

INSUFFICIENT EVIDENCE: R's allocation is not a purchase. BUY-FAIL is not a successful buy. B1's timing cannot establish insider access or a relation to C.

Equating fee payer with creator; listing the allocation recipient as the first buyer; ignoring failed results; counting transactions as distinct buyers; interpreting newest-first records backward; and naming a human insider from launch timing.

Build the initialization role map and rank successful buy events in the supplied window. Count distinct successful buyer addresses, sum B1's quote expenditure and token receipts, and rewrite “B1 was the project's first insider buyer.”

• Define each operational role explicitly.
• Verify result, instruction and relevant balance effects.
• Separate allocation, transfer, attempt and successful exchange.
• State venue/time/history coverage for every “first” claim.
• Count unique addresses separately from transaction events.

A launch investigation should preserve distinct roles and successful effects. “First buyer” is meaningful only within a documented search scope, and an early address is not automatically a creator or insider.

Use role maps instead of one ambiguous deployer label. Preserve failed attempts separately. Timing supports chronology, not motive.

Plot INIT-A roles as labelled edges to a mint node; use a separate event timeline for allocation, failed attempt and successful swaps. Show B1 repeated without creating a new address node. Attach quote and token effects from the fixture and a visible VENUE-A coverage boundary.

Visual delivery rules: dark navy/black, cyan/electric-blue/violet accents, units and uncertainty explicitly labelled. Use deterministic charts or SVG, not fabricated screenshots. At 390 px stack annotations and provide the data table as a text alternative; verify 768 px and desktop later. In Arabic localize labels and layout with native RTL, while isolating addresses/hashes LTR and retaining the actual direction of transfers and chronology. Use only the supplied official ZECOIN logo if branding is added. No visual asset or mobile/RTL rendering is claimed ready.

Use WALLET_INTELLIGENCE only when the exact network, asset and needed fields are supported and their provenance is visible. This is a read-only educational inspection, not a trade or a token launch. Use the supplied offline dataset if access or data is unavailable; missing information remains unknown. A future Open in ZECOIN action needs validated runtime routing and source coverage. No executable asset CTA is supplied for illustrative identifiers. Academy participation and commercial status never change Radar observations.

• Solana Assets: mint and token accounts — Mint identity, token-account ownership and distinct mint/creation roles. Checked 2026-09-30.
• Solana getTransaction — Confirmed transaction lookup and nullable transaction/time/meta results. Checked 2026-09-30.
• Solana getSignaturesForAddress — Newest-first referenced-address signatures and pagination parameters. Checked 2026-09-30.
• Solana RPC JSON Structures — Transaction signers, instructions and balance/result metadata. Checked 2026-09-30.

The tables and exercise fixtures are original educational material unless explicitly designated HISTORICAL. Fictional identifiers are deliberately invalid as blockchain addresses. Documentation supports mechanism definitions, not the invented exercise values. Source inspection is editorial research, not a live-chain measurement. Sources may change; re-review before publication.

P07-L06; proceed after completing the exercise and reviewing each quiz explanation.