Bundles snipers and launch patterns

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

Learning objectives:

• Separate verified bundle membership from same-slot timing.
• Calculate early-acquisition and mapped-bundle shares with explicit rules.
• Test coordination hypotheses without inventing ownership or current holdings.

Several early buys can occur close together without forming a bundle, sharing a controller or proving privileged access. Terms such as “sniper” and “bundled supply” often combine a technical mechanism with a speculative interpretation. Your skill is to describe a pattern, test alternative explanations and separate verified bundle evidence from timing alone.

Distinguish the submission mechanism from behavior

Jito documents a bundle mechanism for up to five transactions intended to execute sequentially and atomically within one slot [S-JITO]. This describes its execution semantics, not an identification test for arbitrary neighboring on-chain transactions. A group of transactions sharing a slot may have been submitted independently. A single transaction containing several instructions is also different from several transactions grouped through a bundle service.

The same documentation describes an uncled-block exception: rebroadcast constituent transactions can reach the normal banking stage, which does not enforce bundle atomicity or reversion protection [S-JITO]. Therefore intended bundle semantics are not a universal guarantee for every later transaction appearance. Inspect matched result and status records; do not invent this exception as the explanation for any fixture event.

A submission receipt is not the same as evidence of landed execution. Status evidence needs to match the transaction signatures and confirmed outcome. Provider status retention can be limited; a missing status later is not proof that no bundle existed. Preserve what the source actually reports, along with when it was queried.

“Sniper” is a behavioral label, not a universal on-chain field. In this lesson define it operationally as an address satisfying a declared early-participation timing rule. If the rule says “successful buy among the first three covered swap events,” then the output should be named an early-participation cohort. Do not silently add conclusions about automation, insider access or malicious intent.

Start with testable observables

A useful observation table contains exact asset/venue identity, slot and transaction order where supplied, result, signer/recipient roles, time resolution and amounts. Token balance changes should be linked to the relevant exchange, not merely nearby transfers. If the signature-to-bundle mapping is available from a trusted inspected source, keep it as a separate evidence column.

Fix the rule before viewing the distribution. Selecting a cutoff after noticing several conspicuous wallets can overfit the pattern. Different rules can produce different cohorts: first three successful buys, buys within a displayed second, or verified members of one bundle. A report should never use the percentage from one rule while naming it as another.

If order within a slot is unresolved, preserve ties. The convenient visual ordering chosen by an interface can be an indexer convention rather than execution order. A reported block time can be null or coarse, so write the actual resolution rather than inventing millisecond precision.

Compare alternative explanations

Near-simultaneous buys may reflect public bots, independent participants reacting to the same announcement, a common service or coordinated actors. Equal sizes may result from interface presets. Similar funding might arise from a custody hub. None of these alternatives automatically explains the data, but their existence prevents timing from becoming exclusive proof of coordination.

Independent clues should be assessed for their mechanism, not counted as a magic total. Same slot, same second and “very close in time” can be three descriptions of one timing observation. They are not three independent identity confirmations. Funding patterns and bundle status can answer different questions, but even a verified common bundle does not identify the human controller of every recipient.

An early-supply statistic requires a snapshot. Tokens bought early may later move or be sold. “Bought 40% during the window” describes accumulated acquisition volume under a rule; “holds 40% now” requires a separate balance observation. Gross purchases may double-count units resold and repurchased. Use matched units, stated denominators and a clear cutoff.

Build a conservative report

Keep separate fields for observed early activity, verified submission/execution grouping and inferred coordination. This makes the report useful even when the strongest claim cannot be established. An analyst can say “two transactions have a supplied landed bundle mapping; a third early transaction has no mapping in the fixture.” That sentence does not require a binary “manipulated/not manipulated” classification.

No part of this exercise teaches bundle submission, transaction racing or strategies for exploiting launches. You are evaluating supplied records read-only. A pattern report is not an entry signal or a way to forecast price. Claims about unfair access need additional evidence, and commercial or social status must not change diagnostic facts.

• Bundle mapping: evidence connecting particular signatures to a reported bundle.
• Landed status: a source's execution-status record, distinct from submission.
• Early cohort: addresses/events selected by a disclosed timing rule.
• Timing resolution: precision actually provided by the source.
• Overfitting: choosing a rule to fit the observed pattern after the fact.
• Acquisition volume: purchases in a window, distinct from current holdings.

ILLUSTRATIVE EXAMPLE — FIX-P07-07. Slots, event IDs and bundle labels are invented training values. The window covers three successful early buy events plus a separate failed attempt.

The fictional mint has 1,000,000 base units of supply at the acquisition cutoff. No later holdings are supplied. Membership mapping is a supplied exercise fact, not a real Jito response.

OBSERVED: E1/E2 have an explicit landed grouping in the fixture. E3 shares the slot but lacks that grouping evidence. E4 failed.

INFERRED: Under the rule “successful buys in SLOT-A,” the early acquisition cohort obtained 400,000 units, or 40% of the supplied supply. The verified mapped subset obtained 300,000, or 30%.

UNKNOWN: Human control, later balances, automation, private access and whether E3 belonged to an unreported submission mechanism.

INSUFFICIENT EVIDENCE: Shared slot alone cannot classify E3 as bundled; E4's receipt cannot establish a landed buy. Neither early-acquisition share establishes insider-held supply.

Calling all same-slot events one bundle; interpreting missing retained status as proof of absence; confusing bundled transactions with multiple instructions; double-counting timing clues; and relabelling early acquisitions as current balances.

Write two separate statistics: successful SLOT-A acquisition share and explicitly mapped BUNDLE-X acquisition share. Decide whether E3 and E4 can be included in the mapped subset. Then assess the sentence “40% is currently held by one insider.”

• Define an early-event rule and preserve its cutoff.
• Verify success separately from submission.
• Require explicit evidence for bundle membership.
• Separate transaction grouping from human identity.
• Distinguish acquired volume from later holdings.

Launch patterns are research observations, not identities or forecasts. A verified bundle and a same-slot cohort answer different questions; preserve both their evidence and their limits.

Timing alone does not prove bundling. A receipt is not a successful exchange. Name the exact statistic before interpreting its percentage.

Create a slot timeline from FIX-P07-07. Bracket only E1/E2 as the supplied mapped bundle; put E3 in the same-slot lane with unresolved ordering and no bracket; E4 is a failed attempt. Show 40% cohort acquisition and 30% mapped acquisition with one-million denominator and 'not current holdings' label.

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.

• Jito Low Latency Transaction Send — Intended execution semantics, submission versus landed status and uncled-block rebroadcast limits. Checked 2026-10-01.
• Solana getTransaction — Confirmed transaction lookup and nullable transaction/time/meta results. 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-L08; proceed after completing the exercise and reviewing each quiz explanation.