A wallet buying in a token’s first block may be a bot, a market maker, a participant with advance information, a project-controlled address or an unrelated trader competing for speed. The transaction proves that an address acted early. It does not, by itself, prove who controlled the address or why it acted.
That distinction matters whenever a meme launch is called “sniped.” Timing is a starting point for an investigation, not a person-level conclusion.
Define the launch event before counting blocks
“First block” is ambiguous until the event being measured is named. A token mint can exist before trading. Metadata can be created separately. A pool can be initialized before liquidity is deposited, and trading may start in the same transaction as a deposit or in a later one.
Anchor the timeline to an exact signature and explain the choice. For a decentralized launch, the most useful anchor is often the transaction that creates or activates the first intended trading pool with usable liquidity. A social post saying “live” is supporting chronology, not a substitute for the chain event.
The token also needs an exact mint address. Symbols and names are reusable. If the address came from a project post, archive that post; if it came from a data provider, label the provider and observation date. Mixing an imitator’s transactions into the official launch makes every later inference unreliable.
Reconstruct the block, not only one wallet
Solana’s getSignaturesForAddress method returns confirmed signatures that reference an address, newest first. Its before and until fields support pagination, while each result supplies a slot, signature, error state and optional block time. That is useful for locating relevant transactions, but it is not a complete launch reconstruction by itself.
Once the launch slot is known, getBlock can return the confirmed block’s metadata and transaction data. Request full transaction details and set maxSupportedTransactionVersion so versioned transactions are not silently excluded by an incompatible client. Preserve the slot, blockhash, signatures, transaction indexes, success or failure status and raw response hash used for the analysis.
The Solana transaction documentation also supplies an important boundary: instructions inside one transaction execute atomically, and a failed instruction reverts the transaction’s state changes even though a fee is charged. Do not count a failed attempted swap as acquired supply.
Speed can be purchased and automated
Early inclusion does not require an inside relationship. Bots can watch pool accounts, simulate swaps, pay priority fees and submit through specialized infrastructure. Jito’s documentation describes a block engine that accepts transactions and bundles, runs priority auctions and sends profitable combinations to validators. Bundles can contain up to five transactions executed sequentially and atomically, with tips competing for inclusion.
That infrastructure does not explain any specific launch wallet. It demonstrates why “landed immediately” and “must be an insider” are not equivalent statements. A technically prepared outsider can be very fast. Conversely, an insider can trade through an ordinary-looking address. Identity requires linkage evidence beyond transaction position.
Build the link as separate claims
Treat each proposed connection as a testable edge:
| Observation | What it supports | What it does not prove alone |
|---|---|---|
| Buy landed in the launch slot | Exceptional timing | Control by the project |
| Wallet was funded before launch | Preparation | Who supplied the funds or knew the schedule |
| Funding came directly from a disclosed project wallet | A financial link | The recipient’s legal identity or intent |
| Same signer authorized project and buyer transactions | Shared signing authority at those moments | The signer’s real-world owner if the key is a service or multisig participant |
| Multiple wallets share funding, timing and exit patterns | Coordinated behavior becomes more plausible | A criminal agreement or common beneficial owner |
| Contract, message or sworn filing names a wallet controller | Off-chain attribution | That every allegation in the document is true |
The strongest analysis combines independent layers: common funding, repeated interaction, shared signers, synchronized transactions, matching exit routes and an off-chain record that explains the relationship. State what each layer contributes. Do not hide a weak identity inference behind a dense wallet graph.
Separate proceeds, profit and remaining exposure
A wallet’s gross sale proceeds are not automatically profit. Reconstruct acquisition cost, presale consideration, swap inputs, network and priority fees, transfers between related addresses and tokens still held. If wallet ownership is unresolved, calculate per address before aggregating a cluster.
Use dated units. Native-token proceeds and dollar estimates answer different questions, and converting every transaction at one later price can invent a gain or loss that was never realized. If a pool is thin, a quoted value for remaining tokens may also exceed what the market could absorb.
HAWK shows the evidentiary ladder
TRM Labs’ December 2024 HAWK analysis reported that a project-controlled vanity address funded strategic-investor wallets and that one wallet acquired 17.5% of supply seconds after launch. The later HAWK complaint alleges an even more specific first-block and pre-funding scheme. The HAWK Meme Autopsy keeps those statements attributed because the public records reviewed here do not independently expose every input needed to reproduce the labels.
That is the right order of operations: confirm the exact token, anchor the launch, enumerate successful transactions, calculate flows, test links and only then describe what remains an allegation. “First-block buyer” is a precise observation. “Insider” is a conclusion that needs more evidence.
Continue with why holder lists count addresses rather than people, the token-launch evidence checklist, liquidity pools versus order books and the meme-coin learning hub.
Reporting and image notes
Original AI-assisted educational analysis based on Solana’s RPC and transaction documentation, Jito’s bundle documentation and the clearly attributed HAWK example. It does not identify any private person behind a wallet, make a live-token accusation or offer investment advice. The cover is Indika.warapitiya’s 2016 photograph of a real changeable hawk-eagle at Udawalawe National Park. The exact Wikimedia Commons page records the creator’s own-work statement and CC BY-SA 4.0 license. The photograph is a speed-and-observation metaphor, not HAWK token artwork or blockchain evidence. It was cropped, subtly darkened, resized and converted to WebP, and the adaptation is shared under the same license.