Insider Trading Tracking Guide: Spot Coordinated Buying

Following early wallets isn't enough to identify insiders. A profitable buyer might have confidential information, but they might also be reacting to a public rumour, copying another trader or supplying liquidity. Buying because a tracker displays an insider badge can turn an uncertain observation into an expensive assumption.

Insider trading tracking works best as a way to rank leads for verification. For a Solana meme coin, the useful question isn't who bought first. It's whether timing, funding relationships and trading behaviour support the same explanation, and what evidence could still contradict it.

Table of Contents

• Signals Worth Checking Before You Trade
• How to Run a Pre-Event Screen Step by Step
  • Build the event record
  • Test the explanation
• Grouping Wallets Without Overcounting Actors
  • Combine behaviour with relationships
  • Avoid misleading cluster counts
• Why an Alert Is Not Proof of Insider Trading
  • Use labels that match the evidence
• How to Validate an Alert Before Acting
  • Check coverage and calibration
  • Compare competing alerts
• Decide What to Do With a Suspicious Token
  • Match the response to the evidence

Signals Worth Checking Before You Trade

No single signal proves insider trading. Check several together, and separate evidence you can inspect directly from calculations that require historical market data or a clustering model.

A block explorer lets you inspect transaction timestamps, funding transfers and sell transactions. Benchmark-adjusted returns and cluster rankings need a dedicated data tool or your own analytical pipeline.

Insider tracking signals and what each one shows

Signal	What to measure	Stronger when	Weaker when
Pre-event buying	Buys in a chosen 1 to 24 hours before a listing or announcement, checked in an explorer	Several apparently unrelated wallets buy in the same window	One wallet buys alone or the event was already public
Abnormal return	Token return minus a market or sector benchmark, calculated with a data tool	The gap persists against several matched control windows	A broad market rally lifts comparable tokens
Wallet cluster size	Linked wallets sharing funders, counterparties or entry times, assessed with a clustering tool	The linked cluster holds a large share of supply	An exchange funding source creates an apparent connection between unrelated customers
Buy size vs liquidity	Entry size divided by pool liquidity, using trade and pool records	Large buys occur against thin liquidity	A deep pool absorbs the same purchase
Creator-linked wallets	Deployer connections and bundled first buys, investigated in an explorer	Bundled buyers share a funder with the creator	No funding connection is visible, although attribution remains incomplete
Post-launch selling	Cluster sales relative to the price peak, checked against explorer and price records	Linked buyers exit together shortly after the spike	Holders sell gradually rather than synchronously
Post-flag outcome	Price change over a chosen 24-hour evaluation period	Flagged tokens repeatedly perform poorly in comparable evaluations	No decline follows, or similar unflagged tokens behave the same way

Treat these as screening criteria, not validated legal thresholds. The chosen monitoring and evaluation windows are workflow settings, not boundaries between lawful and unlawful trading.

Repeated event timing deserves more attention than an isolated winning trade. The SEC's insider-trading enforcement overview describes investigations involving relationships, information access and varied market participants, rather than a single profitable transaction.

Practical rule: Escalate only when at least three independent signals agree. This is a conservative review rule, not a measured detection guarantee.

Independence matters. Early entry, a large unrealised gain and a high abnormal return may all describe the same price move. Funding evidence, repeated event timing and coordinated exits provide more distinct reasons to investigate.

How to Run a Pre-Event Screen Step by Step

A single price spike is not a screen. Start with an information event and reconstruct what traders could have known before it became public.

The exchange-listing study available through SSRN estimated suspicious insider trading around 28–48% of listings, with at least $30 million in aggregate profits. Those are findings about the study's exchange-listing sample and methodology, not a probability that any early Solana buyer is an insider.

Build the event record

1. Define the information event exactly. Record the announcement's publication timestamp and preserve the original announcement. Use a block explorer for transactions, funding and transfers, plus a DEX data feed for price history and pool liquidity; list any unavailable inputs rather than substituting guesses.

2. Set the pre-event window. A practical starting setting is the hours before publication, with the exact boundaries saved in your log. Don't confuse the announcement time with the later trading-open time, because doing so can classify public-information trades as advance buying.

3. Calculate the abnormal return. Subtract the market or token-sector benchmark's return from the token's return over identical boundaries. Choose the benchmark before reviewing the result so you don't select whichever comparison makes the token look most suspicious.

4. Build matched control periods. Select earlier periods of comparable duration and, where possible, similar trading conditions. Skipping controls lets ordinary launch speculation pass as unusually precise event timing.

The workflow below summarises the process from event definition to a documented conclusion.

Test the explanation

5. Compare the event window with the controls. Look for a result that remains unusual across reasonable comparisons. If suspicion disappears when you replace a convenient control period, lower confidence instead of keeping the strongest-looking chart.

6. Cluster the buying wallets. Inspect shared funding sources, common counterparties, synchronised entries and direct transfers. A common service address is a lead to examine, not sufficient evidence that its customers coordinate.

7. Normalise purchases by liquidity. Divide each purchase's value by the relevant pool liquidity at entry, using consistent units. Raw transaction volume alone can obscure the difference between a substantial commitment in a deep pool and a price-moving purchase in a thin one.

8. Document confidence and contradictory evidence. Save the event window, benchmark-adjusted return, linked-wallet count, funding paths and explanation for the confidence label. Include public rumours, missing history and alternative cluster interpretations rather than reporting only supporting observations.

The useful output is an auditable event record, not a list of wallets labelled guilty. Another analyst should be able to reproduce the calculation and understand why you escalated it.

Grouping Wallets Without Overcounting Actors

An address count is not an actor count. One trader splitting buys across a dozen wallets looks like twelve independent buyers, while an exchange withdrawal address shared by thousands of customers makes strangers look coordinated. Both mistakes corrupt the same number: how many independent actors bought before the event.

Use the wallet map to separate observed transfers from inferred ownership.

Say several wallets receive funds from the same private address and buy within minutes of a deployer transaction. Label them a candidate cluster, then run three checks: whether the funder is a shared service such as an exchange or sniping tool, whether the wallets move assets between themselves, and whether their exits align in time. Each check passed raises the cluster's rank as a lead; a failed check can dissolve it entirely. Until then, each address is one suspected actor at most, never independent confirmation of the others.

Combine behaviour with relationships

Build features across three complementary evidence layers:

• Transaction behaviour: entry lead time, purchase size relative to liquidity, realised and unrealised returns, and sell timing.
• Network structure: shared funders, wallet reuse, transfer paths and recurring counterparties.
• Behavioural change: whether the wallet's activity departs from its own historical trading profile.

Combining network and behavioural-change features is a standard approach in anomaly detection, because a transaction-only view misses wallets that look ordinary alone but unusual as a group. An Isolation Forest can rank unusual wallets or clusters. Treat the score as an ordering of what to inspect first rather than a probability of unlawful conduct.

For a trader-facing interpretation of these relationships, our guide to what Solana wallet clusters mean separates address connections from stronger ownership inferences.

The video below walks through the same wallet-analysis concepts in another format.

Avoid misleading cluster counts

A whale distributing funds across fresh wallets before a launch should count as one actor, however many addresses appear in the map. Exchange-funded buyers sit at the opposite trap: thousands of unrelated customers can share one depositor address, so treat the shared funder as a service until wallet-level transfers or synchronised exits say otherwise. Copy-trading bots and automated snipers produce a similar cluster shape to coordinated insiders, which is why timing and funding evidence need the behavioural layer beside them.

Other traps include fitting every token to a familiar launch pattern and letting raw volume dominate liquidity-adjusted behaviour. Test stability by dropping a feature or shifting the control window; a cluster that survives only one configuration is a weak lead.

Preserve wallet-level evidence: transaction signatures, funding paths, feature values and the reason each address entered the cluster. That record lets you split an incorrect cluster or revise its confidence without reconstructing the investigation from scratch.

Why an Alert Is Not Proof of Insider Trading

A suspicious wallet isn't an identified insider. Blockchain records establish transactions, but generally don't establish who controlled an address or whether that person possessed confidential information.

The Springer paper on pre-listing cryptocurrency behaviour highlights the absence of reliable insider-wallet labels and the attribution problems created by pseudonymous addresses. More visible transactions can mean richer evidence without a correspondingly stronger conclusion about identity or intent.

Common on-chain patterns and their benign explanations

Pattern	Benign explanation	Evidence that would strengthen the concern
Early buyers cluster before a listing	Public rumour or copied trades	Evidence of a non-public information source
Bundled launch buys from one funder	Creator or market maker managing the launch	A concealed relationship to the party making the announcement
Wallet rotation after a spike	Ordinary profit-taking spread across addresses	Coordinated exits timed to a non-public event
Large buy before an announcement	Liquidity provision or market making	Repeated profitable timing across separate events
Correlated buying across unrelated wallets	Social-media hype reaching many holders at once	Communication links among the holders

Keep the distinction between transaction evidence and personal attribution visible.

Use labels that match the evidence

An anomaly means activity differs from the comparison baseline. Coordinated trading means evidence supports linked execution. Likely information leakage requires a defensible connection to information access, while legally established insider trading belongs to a legal determination, not an on-chain score.

Consider a hypothetical bundled launch where the creator also manages market-making wallets. Shared funding and simultaneous transactions may reflect inventory allocation or liquidity management; inspect pool deposits, subsequent quotes and disclosed roles before inferring secret advance knowledge.

Our insider-risk outcome analysis is relevant to evaluating trading risk, but a subsequent decline doesn't resolve the attribution question. A price outcome and a misconduct finding answer different questions.

Put confidence and the strongest alternative explanation in the same sentence as the flag.

For example, describe a moderately confident coordination flag with market-making still unresolved. Don't hide that qualification beneath an unqualified insider label.

How to Validate an Alert Before Acting

Start with the ranking stability test. Rerun the anomaly model using different random seeds, feature sets and event boundaries, then check whether the same candidate clusters remain near the top.

Stability alone doesn't establish event-specific information access. The Springer article on cryptocurrency anomaly detection also identifies incomplete venue coverage and scarce confirmed wallet labels, which constrain conventional precision and recall estimates.

Check coverage and calibration

• Coverage check: Pass when the report identifies the pools, price feeds and wallet history it used, alongside unavailable records. Fail when it implies complete market coverage from a DEX-only dataset.
• Ranking check: Pass when the cluster remains prominent under reasonable settings. Fail when a small boundary change removes the supporting relationship.
• Outcome check: Record the token's price over the chosen post-flag evaluation window. Compare it with similarly scored tokens and market conditions, not just the most dramatic losing example.
• Calibration check: Compare outcomes across score bands. A stronger label should earn its place through repeatable evaluation, not a more alarming colour.
• False-positive review: Separate disproved ownership links from alerts followed by rising prices. Neither should be discarded, but they represent different analytical failures.

The checklist keeps missing venues visible rather than treating the observed pool as the whole market.

Compare competing alerts

Suppose one flagged token declines sharply and its candidate cluster survives different event windows. Another token's apparent cluster disappears when you adjust the start boundary. The first warrants more investigation because its underlying evidence is more reproducible, not because a falling price proves insider trading.

Centralised exchange activity, over-the-counter transfers and other pools may remain outside your view. Mark a token with thin records unverified, not cleared, and use Solana token safety checks to assess risks that the trading-pattern alert doesn't address.

Maintain a log containing the token address, flag timestamp, evidence, missing inputs, model settings and subsequent outcome. Without that denominator, you can remember successful warnings while overlooking weak ones.

Decide What to Do With a Suspicious Token

Your decision rule should determine how much additional risk you'll accept, not whether you can publicly accuse a wallet owner. Set it before reviewing a token you already want to buy.

Match the response to the evidence

• Insufficient independent agreement: Keep the token on a watchlist and reassess at the next relevant event. Don't upgrade several versions of the same price signal into separate confirmations.
• Independent agreement with stable clustering: Consider reducing exposure or avoiding entry while you seek a second source that does not repeat the original alert. Check whether its evidence independently confirms funding, timing, or creator relationships.
• Missing essential records: Leave the result unverified until the missing inputs arrive. A blank field shouldn't become a favourable score.
• A credible benign explanation: Record what supports it and what would disprove it. Lower confidence where appropriate, without assuming every unresolved connection is harmless.

At MemeAssist, we treat suspicious activities and possibly connected wallets as starting points for further checks, not evidence of misconduct. We also don't interpret missing data as proof of safety.

Before relying on a narrative report, run the basic contract and liquidity checks. We offer free Contract Checker, Liquidity Checker, Honeypot Checker and Rug Checker tools to help examine those separate risks; none substitutes for verifying the trading evidence.

Decision rule: Require independent agreement and stable evidence before escalating concern. Keep incomplete cases unverified.

Repeat the screen on the next launch using the same log and decision settings. Change your rules when a documented evaluation justifies it, not whenever a memorable token makes the previous rule look inconvenient.

---

MemeAssist combines Solana wallet activity, creator behaviour, liquidity and trading-pattern checks with plain-English risk explanations. Visit MemeAssist to run the free checks, inspect the evidence behind a suspicious token and decide which wallet connections need further verification.