Two ways wallets profit from tokens they never bought on market. How to distinguish a front-running infrastructure play from an insider allocation using nothing but on-chain data.
How to Detect Insider Wallets on Solana
You found a wallet that keeps printing. It takes profit on token after token without ever taking a loss. Most of its gains come from coins it received at creation and sold around 70k market cap.
Did it buy early or did it never buy at all?
The answer matters. A wallet that front-runs token launches with low-latency infrastructure is a different problem from a wallet that received insider allocation. One requires execution speed. One requires access.
This article shows how to tell them apart using nothing but on-chain data. No proprietary APIs. No insider information. Just the public ledger and a few questions to ask of every transaction.
Option A: The wallet bought before anyone else could
The wallet is not receiving tokens for free. It is buying them before any DEX pool exists, in the same transaction block that creates the token.
This requires three things.
Low-latency parsed data. The wallet operator needs to see mint events as they land on chain. Public RPC polling at one-second intervals is too slow. They need parsed websocket feeds or direct validator connections.
Tracking mint instructions, not swap events. The instruction that creates a token is the signal, not the trade. On pump.fun this instruction is called create_2. The operator watches for it, extracts the token mint address from the instruction data, and prepares to buy before the pool ever goes live.
Same-slot or next-slot execution. Once the mint instruction lands, the operator must submit a buy transaction in the same slot or the one immediately after. By the time the pool is visible to normal traders, they already hold a position.
This is infrastructure, not access. Anyone with the right setup can do it. The edge is speed.
Option B: The wallet never bought at all
The wallet holds tokens it never paid for. Someone minted them directly to this address, or transferred them from a deployer wallet, before any market existed.
This is an insider allocation. It is a team wallet, an advisor allocation, or a targeted airdrop to a known address.
The way to prove this is the birth order check.
Step 1: Find the token account creation time
Every SPL token balance lives in an Associated Token Account (ATA). This account is created the first time a wallet receives that token. The creation timestamp is the first time that wallet could have held that token.
Check when the ATA was created relative to the token’s first DEX pool creation. If the ATA was created before the pool went live, the wallet did not buy it on market. There was no market to buy from.
Step 2: Trace the first transfer into that token account
The first transaction that deposits tokens into the ATA tells you the origin.
If the sender is the mint authority or the token deployer address, the tokens were allocated directly. If the sender is another known wallet, follow that chain backwards. If the sender is a DEX program like Raydium or Meteora, it was a market buy. If there is no inbound transfer and the account was funded as part of the initial mint, it was created alongside the token supply itself.
Step 3: Check the mint authority’s action log
Pull the mint authority address. Query its transaction history around the token deploy timestamp. Look for mintTo instructions that target the wallet in question. If the mint authority called mintTo targeting this wallet before any pool existed, the proof is on chain.
Step 4: Do it programmatically
The same check expressed as RPC calls:
1. getTokenAccountsByOwner(suspectWallet, tokenMint)
2. getSignaturesForAddress(tokenAccount, limit=1)
3. Parse the first instruction:
- programId == TOKEN_PROGRAM_ID && instruction == mintTo
-> origin = mint allocation
- programId == AMM_PROGRAM
-> origin = dex buy
- programId == TOKEN_PROGRAM_ID && instruction == transfer
-> origin = received from another wallet
-> follow that wallet back to step 1
The first transaction on a token account is immutable. It cannot be faked. If the first movement into the wallet came from the mint authority, the wallet received those tokens before any market existed.
The practical shortcut
Pull the suspect wallet on Solscan. Navigate to the token account tab for the specific token. The first transaction listed is the origin.
If it says Mint or shows a transfer from the deployer wallet, the holder never bought. If it says Swap, they bought early but they still bought.
Why this pattern keeps working
Most token launches do not enforce fair distribution. The mint authority knows which wallets get the first allocation. They control the timing of the mintTo calls. They decide whether to send tokens to the pool first or to insiders first.
The wallet you found could be running Option A (infrastructure play) if it takes minimal losses and trades across many tokens. The pattern of selling at 70k market cap every time suggests a repeatable execution strategy, not a one-time allocation.
But Option B is just as common. Many high-profit wallets on Solana are simply addresses that were funded at token creation and have never executed a single market buy for the tokens they sell.
Both patterns are visible on chain. The birth order check is all it takes to know which one you are looking at.
For a worked example of structural wallet detection at scale, see the mule detection system that applies similar on-chain forensic techniques to TRON money flow analysis.