Following a Token Through Hands: A Hop Table

Follow a token by tracking the token accounts that hold it, not the wallets that own them. For each transaction, read the token balance arrays before and after, record which account decreased and which increased, keep amounts in raw integer units until the very end, and mark the point at which each branch terminates. Most branches terminate quickly, and naming the terminator is a result rather than a failure.

The distinction between following a wallet and following a token matters because they diverge immediately. A wallet can be busy in one token while its SOL balance barely moves. A token supply can pass through accounts belonging to entities you have no interest in. Deciding which of the two you are tracing, and writing it down, prevents a great deal of confusion later.

What following a token means

A token trace answers questions of the form: where did this supply go, over this window, in hops. It works well for a few hops through ordinary transfers, and it stops working at three specific structures: liquidity pools, custodial addresses and bridges. Those are not obstacles to be routed around; they are the ends of branches, and a competent trace labels them as such.

What it never answers is who received anything. A destination account has an owner field, and the owner is another public key. Following supply establishes movement between keys, and movement between keys is exactly as much as the ledger contains.

Token account mechanics you need first

Three facts about the SPL token model make token tracing readable. Balances live in accounts owned by the token program, not in the wallet itself, and each such account holds exactly one mint. The canonical account for a given owner and mint is derived deterministically as an associated token account, so you can compute the expected address rather than searching for it.

Amounts are integers scaled by the mint's decimals, so interpretation requires the decimals value and nothing else. Fetch it once from the mint and apply it consistently. Comparing raw amounts across two mints with different decimals produces numbers that look meaningful and are not, and this is a surprisingly common error in spreadsheets assembled quickly.

Accounts are created and destroyed. Creating one costs a rent-exempt deposit of roughly 0.00204 SOL, which returns when the account is closed. That means a transfer to a fresh recipient often carries an account creation alongside it, and the small SOL movement in the same transaction is provisioning rather than payment.

The hop table

The deliverable of a token trace is a table, not a diagram. A diagram hides amounts and implies certainty about direction that a table forces you to state. Each row is one movement, with its own signature, so any reader can verify a single row without re-running the whole trace.

Read what the table says and, more importantly, what it does not. Two branches ended: one at a pool, one at a custodial address. Neither ending is a mystery and neither should be described as the supply "disappearing". The trace covered three hops, accounted for the full amount at every step, and stopped where the structure stops.

Include the raw amounts, because they are the audit trail. If hop two says 600,000,000 raw units and hop four says the same, the reader can see that nothing was lost or added along the way. Converted display values hide exactly the discrepancies worth noticing.

Splits, routes and partial fills

Supply rarely moves in one piece. It splits, and each split doubles the bookkeeping. Three sources of splitting are worth recognising because they mean different things: deliberate division across several destinations, routing where an aggregator breaks a trade across venues for a better price, and partial fills where an intended amount is executed in pieces.

Routing splits are the ones most often misread. When a swap is routed across several pools, the transaction contains multiple inner transfers to different vaults, and a naive reading reports several separate movements to several counterparties. In reality it is one trade executed in parts, and the correct hop table entry is one row with a note, not four rows implying four relationships.

The rule that keeps splits manageable is to reconcile at each hop. Amounts out must equal amounts in, minus anything explicitly burned or paid as a fee inside the transaction. When they do not, you have missed a branch, and the missing branch is more informative than the ones you already have.

Where fungibility ends the chase

A liquidity pool is the hardest terminator in token tracing and the least well understood by people new to the work. Tokens are fungible: units in a reserve are not individually identified, and the pool's accounting tracks a balance rather than a set of items. When a supply enters a pool, it joins a common reserve and stops being distinguishable.

What you can say is precise and limited. A stated amount entered the pool at a stated time. Amounts later left the pool to various accounts. What you cannot say is that a specific exit is the same supply as a specific entry, because that statement has no meaning in a fungible reserve. Analysts who chase supply through a pool are matching amounts and calling the match a link, which is a coincidence dressed as evidence.

Curve to pool handover

Launch mechanics add one more structure worth understanding. Tokens that begin on a bonding curve and later migrate to a standard automated market maker cross a boundary where the accounting model changes: the curve holds reserves under one program, and migration moves liquidity into a pool under another.

For a trace this matters in two ways. The migration transaction itself is a large, single, dateable event that is easy to find and useful as an anchor for everything around it. And after migration, trading activity moves to the new venue, so a trace that keeps watching the curve accounts will show a supply going quiet when in fact the activity relocated.

Post-migration pool activity has its own patterns, and understanding what routine automated trading looks like on an established AMM helps separate it from anything unusual. Reference material on how a Raydium volume bot operates against pool liquidity describes the ordinary shape of scheduled trading on that kind of venue, which is a useful baseline when you are deciding whether a post-migration pattern is remarkable or entirely standard.

Following across venues

Supply that touches several venues produces a fragmented picture, because each venue has its own programs, its own account structures and its own vault addresses. The trace does not break, but it does require you to recognise each venue's vaults rather than treating them as ordinary counterparties, and mislabelling a vault as a recipient is one of the more consequential errors available.

Multi-venue activity is also completely ordinary. Aggregators route across venues by design, and any tool operating at scale spreads activity around, so a pattern crossing several markets tells you about execution rather than about intent. Documentation describing how a volume bot on Solana DEXs distributes activity across venues is useful here for the same reason a route map is useful: it tells you which multi-venue shapes are normal for scheduled trading, so you spend your attention on the ones that are not.

Supply accounting, worked

Percentages of supply are the most quoted and least carefully computed numbers in this field. The arithmetic below is illustrative and uses invented round figures to show the method rather than to describe any real token.

Take a mint with 1,000,000,000 tokens and six decimals, so the raw total supply is 1,000,000,000,000,000. Suppose a hop table shows 40,000,000,000,000 raw units moving from one account to a pool. Divide: that is 4 per cent of total supply. Now subtract what is not circulating. If 200,000,000 tokens sit in a locked or program-controlled account, circulating supply is 800,000,000, and the same movement is 5 per cent of circulating supply.

Two different true statements, one movement. This is why a supply percentage without its denominator is close to meaningless, and why the denominator has to be stated every time. State which supply figure you used, where it came from, and at what time you read it, because supply changes when tokens are minted or burned.

Burns, closes and disappearing balances

Balances vanish for several reasons, and the reasons look similar in a state view while being completely different in the record. A burn destroys tokens and reduces supply; the transaction records it explicitly. An account close returns rent and removes the account from current state while leaving its entire transaction history intact. A transfer to another account moves the balance without changing supply at all.

Reading current state alone cannot distinguish these, which is one more reason state views are a poor foundation for a trace. The transaction history distinguishes them cleanly: check the mint's supply figure before and after, check for a burn instruction, and check whether an account close appears in the same transaction.

Supply can also grow. If a mint authority still exists, new tokens can be created, which changes every percentage you computed earlier without any transfer appearing in your hop table. Check whether the mint authority has been revoked and record the answer with the date you checked it, because a percentage of supply quoted against a mutable supply is a figure with a shelf life.

Freeze authority deserves the same one-line check. Where it exists, individual token accounts can be frozen, which stops balances moving without destroying them, and a frozen account can look like voluntary dormancy in a trace. Neither authority tells you anything about who holds it; both change what the absence of movement in your table is allowed to mean.

How token tracing fails

The dominant failure is the amount-matching trap across a fungible boundary, described above. The second is missing a branch during a split and then reporting a total that does not reconcile, which usually happens when a routed swap is read as several independent transfers. The third is decimal confusion, which produces amounts wrong by orders of magnitude and is embarrassingly easy to commit under time pressure.

A fourth failure is subtler: treating a vault, program-derived address or protocol account as a counterparty. Those addresses receive from everyone, so including them in a trace as if they were participants creates apparent links between completely unrelated parties. Classify every destination before you record it, and mark protocol addresses as terminators.

Each of these is a mechanical error with a mechanical fix, which is why token tracing is one of the more reliable methods on this site when it is done carefully. The deeper limits are the structural ones collected in where a trail goes cold, and they are not fixable at all.

Writing a flow finding

Publish the hop table, the terminators and the reconciliation. State the window in UTC, the mint, the decimals, and the supply denominator behind any percentage. Then state what the trace does not establish: who owns the destination accounts, why any transfer happened, and what became of amounts that entered pools.

A good flow finding is deliberately unexciting. It says a stated amount moved from one account to two others within a stated window, that one branch terminated in a pool and one at a custodial address, and that the movement represents a stated percentage of a stated supply figure. Everything a reader would want beyond that is off chain, and saying so plainly is more useful than implying you know it. Where a group of accounts is involved, the grouping question is handled separately in clustering related addresses, with its own weights and its own failure modes.

Questions this page gets asked