Solana wallet tracking, one hop at a time

Solana wallet tracking means reading a public record in a fixed order: fix the address, page the full signature history, compare balances before and after each transaction, walk back to the first deposit, and only then group addresses that behave as though one hand moves them. Everything after that is inference, and inference has a failure rate.

Trace Rack publishes the procedure and the failure rate together. Eight guides, each one stating its inputs, its output, and the pattern that makes it produce a confident wrong answer. This is a reading method for markets and flows, not a way of finding out who somebody is.

Open the console Start with the loop

DESK SCOPE PUBLIC DATA ONLY

SUBJECTAddresses, transactions and token accounts on a public ledger. Never the people who may or may not hold the keys.
INPUTSignatures, pre and post balances, instruction lists, program logs, block times read in UTC.
OUTPUTProcedures, scoring sheets, hop tables and a stated false-positive mode for every method published here.
REFUSEDIdentity work, de-anonymisation technique, accusations against named wallets or projects, and tracing as a service.

Addresses in every example are written as letters, not base58, so no page here points at a real account.

What this desk covers

Three questions come up in every piece of wallet work, and all three are answerable from data anyone can query. The fourth question, the one about identity, is the one this desk does not touch.

What did this address actually do?

Not what a dashboard summarised, but what the transactions say: which programs ran, which accounts changed balance, in what order, and how much of the movement was fees rather than trades.

Where did the funds come from?

Every account starts empty. The transaction that first made it usable, and the path behind that transaction, is usually the most informative object in the whole history and the easiest one to over-read.

Do these addresses move together?

Clustering is a probability exercise dressed up as a diagram. The useful version writes down the weight of each signal, then tests the group against the pattern that would produce it by coincidence.

Following a wallet

The procedural half. Where the record actually lives, how to read a transaction without guessing, how to walk backwards to a first deposit, how to decide that two addresses belong together, and how to follow one token as it changes hands. Each method is written with its inputs, its output, and the pattern that will fool it.

01Procedure How to track a Solana wallet The whole loop in order: fix the address, choose the record you will read, page the history properly, separate SOL movement from token movement, and write down the question before the first query rather than after the tenth. LIMIT / Cannot tell you who holds the key 02Field note Reading a transaction history A Solana transaction is an account list, a set of instructions and a pair of balance snapshots. Reading it means comparing before and after rather than trusting a summary line an interface produced for you. LIMIT / A parsed label is an interpretation 03Procedure Funding paths and first deposits Every account was empty once. Walking backwards to the transaction that made it usable is the single highest-yield move in wallet work, and also the one most often over-read the moment an exchange sits in the path. LIMIT / A first deposit is not an origin 04Method Clustering related addresses Six grouping signals ranked by how much weight each can actually hold, a scoring sheet that forces you to write the weight down, and the concrete pattern that breaks each signal in practice. LIMIT / Shared behaviour is not shared control 05Procedure Following a token through hands Tokens move through associated accounts, split across routes and disappear into pools. How to follow a supply hop by hop, where fungibility ends the chase, and how to record a hop table nobody has to take on trust. LIMIT / Fungibility erases identity in a pool

Knowing when to stop

The half that keeps the first half honest. A label is a claim and most labels are weaker than the sentence they get written into. Trails end for structural reasons rather than clever ones, and a conclusion that survives review is usually smaller than the one you wanted. These three pages are the reason this desk is not a surveillance manual.

06Method Labelling what you find A label is a compressed claim, and compression is where the errors get in. A three-tier vocabulary, the evidence each tier demands, an expiry rule, and the labels this desk refuses to write at all. LIMIT / Labels outlive the evidence behind them 07Limits Where a trail goes cold Eight structural terminators, from custodial pooling to cross-chain hops to plain silence, with what remains provable at each one and the phrasing that keeps a report accurate once the trail has ended. LIMIT / Most endings are structural, not clever 08Method False positives and honest conclusions The failure modes that produce a confident wrong answer: base rates, coincidence at scale, one-way inference, and the review procedure that shrinks a finding down to the size the evidence can carry. LIMIT / Confidence is not a form of evidence

What each signal can carry

Signals are not equal and the difference is not a matter of taste. Some describe a fact the ledger records directly; others describe a pattern that a completely ordinary situation also produces. The third column is the one that decides how a finding should be phrased.

Six common tracing signals, what each one establishes, the ordinary situation that imitates it, and the strongest wording it can support in a written finding.
Signal	What it establishes	What also produces it	Strongest honest wording
Direct transfer	Value moved from one account to another in a recorded transaction	Nothing: this part is a fact, though the reason for it is not	"A transferred to B in slot N"
Shared funder	Two accounts received their first lamports from the same source	An exchange withdrawal desk, a faucet, an airdrop distributor, a payroll batch	"Both were funded from the same address"
Same-block activity	Two accounts acted inside the same slot or a very narrow window	Everyone reacting to the same public event at the same moment	"Activity was concurrent"
Fee-payer overlap	One account paid the fee for transactions signed by another	A relayer, a fee-sponsoring service, a wallet with gasless transfers	"A paid fees for transactions involving B"
Behavioural rhythm	A repeated timing, sizing or route pattern across accounts	Two operators running the same off-the-shelf software	"The accounts share an execution pattern"
Consolidation	Many accounts eventually sweep into one destination	A shared custodian, a deposit address, a market maker taking flow	"Funds converged on a single address"

Read the fourth column carefully. Not one of those sentences names a person, asserts ownership or implies intent, and none of them needs to. A finding that survives review is almost always the one that stayed inside what the record literally shows.

When the wallets in front of you are disclosed automation

A large share of the multi-wallet activity an analyst runs into is not covert at all. Trading desks, market makers and published volume tools all operate wallet sets openly, and their output looks structurally similar to the patterns clustering methods flag. The practical difference is disclosure: a tool that documents its venue coverage, its fee model and what a run leaves on chain gives you a reference pattern to compare against, which is far more useful than guessing from the shape of the transactions alone.

Look at a disclosed console

How this desk works

Four rules, written so a reader can tell when the site is out of its depth and when it is refusing on purpose.

Method, not case files

Pages here describe procedures a reader can run against any address they care about. The desk does not publish investigations into specific wallets, projects or people, and does not take tracing work.

Every method states how it fails

A technique with no stated false-positive mode is a technique nobody has stress-tested. Each guide names the ordinary situation that produces its signal by accident, because that situation is common.

Addresses are keys, not people

Nothing here links on-chain activity to a real-world identity, and techniques whose main use would be de-anonymising or harassing someone are left out with the omission stated in the page.

No numbers we did not observe

There are no accuracy rates, cluster counts or hit rates on this site. Arithmetic appears only as clearly labelled illustration using protocol constants and figures you supply from your own query.