A public blockchain makes a great deal of activity visible: transfers, swaps, token balances and program calls. That visibility is tempting for trading research. A large transfer to an address tagged as an exchange looks like a sell signal. A group of “smart money” wallets buying the same token looks like a lead. A top-holder list looks like a ready-made risk score. Each of those readings adds an interpretation on top of the record. This article separates what the ledger shows from what a researcher infers, and explains why on-chain features are unusually easy to leak into a backtest.
What an on-chain record actually shows
A recorded transaction shows that the required signatures authorized a set of instructions, that the network processed them with a particular result, and that balances and fees changed accordingly. On Solana, SOL pays network fees, token balances sit in token accounts tied to a specific mint, and a transaction can be reported at different commitment levels: processed, confirmed or finalized. A walkthrough of reading an explorer record covers those fields in more detail.
The record does not show who controlled the signing key, why the transfer happened, whether one person or a custodian moving customer funds was behind it, or whether a matching trade happened somewhere off-chain. Keep the fact and the interpretation in separate columns:
| On-chain fact (fictional) | What it supports | What it does not establish |
|---|---|---|
| 50,000 tokens moved from address A to address B | A balance change between two addresses at a recorded time | A sale, a change of owner or a motive |
| One address holds 12% of supply | That balance at that point in the record | That one person controls 12% |
| Address B carries an “exchange” tag | A provider’s classification, as of some date | That the tag was correct, or existed when the transfer happened |
| Twenty wallets bought within one hour | Similar actions recorded close together | Coordination, skill, or that a follower could have bought at those prices |
Labels are hypotheses with a date attached
Wallet labels come from explorers, analytics providers, community lists or a researcher’s own heuristics. The guide to address labels and uncertain identities treats them as clues that need a source and a confidence level, not as names. An address may be shared, custodial or used for several purposes at once.
Labels also change. A provider may add a tag after an event made a wallet notable, merge or split clusters, or remove a mistaken tag. For research, that means a label is evidence about what one provider believed at the time it was assigned, and you need that time. A useful habit is to work from public addresses only; analyzing a wallet without connecting it never requires a recovery phrase or a signature.
Holder concentration needs classification first
A top-holder list mixes very different kinds of address: liquidity pools, program-owned accounts, exchange wallets, vesting or locker contracts, project treasuries and, sometimes, many addresses controlled by one entity. The guide on what top-holder addresses represent makes the same point: the list is a starting question, not a conclusion.
Consider a fictional token whose ten largest addresses hold 62% of supply. After classification, a researcher finds a pool account at 18%, a locker contract at 20%, exchange-tagged addresses at 9% and unexplained addresses at 15%. The same 62% headline could describe very different situations, and the 15% that remains unexplained is the part the list cannot answer. Record the classification method and its date next to any concentration figure you use.
Today’s labels on yesterday’s data is look-ahead bias
The scikit-learn documentation defines data leakage as using information that would not be available at prediction time when building a model, and warns that it produces overly optimistic performance estimates. Its recommended practice is to split the data first and fit every preprocessing step on the training portion only. On-chain research has several routes for the same mistake:
- Selection by outcome. A list of “smart wallets” built because those wallets later profited will make a follow-the-wallet rule look good over the period used to build the list.
- Label revision. Applying this month’s exchange tags to last year’s transfers assumes the tags were known then.
- Arrival delay. An indexer, explorer or API may make an event available later than its block time. A rule that reacts at block time may be using data it could not yet have seen.
- Finality. A transaction seen at a lower commitment level is not yet final; a backtest that treats every early observation as settled skips that uncertainty.
- Survivorship. Wallet or token lists drawn from what is still active today leave out the ones that went quiet.
A fictional example: a study tags 40 wallets as “early buyers” using a list compiled this month. Most of them earned the tag because their earlier trades did well. Testing “buy when these wallets buy” over the same months mostly measures how the list was chosen. The fix mirrors the scikit-learn advice: build the label set only from data before the test window, then evaluate on later data. Checking what was knowable at decision time covers the broader version of this problem.
Timestamp everything twice
For every on-chain feature, keep at least two times: the block time recorded by the network and the observation time at which your data source made the event available to you. Add the commitment level and the label snapshot date. Without those fields, a feature cannot be placed honestly on a decision timeline. The same discipline appears in the data provenance and timestamp checks for price history.
Timing matters even more when the signal is someone else’s trade. A visible buy reaches you after it landed. A follower trades later, at a different price and cost, and without seeing the wallet’s off-chain hedges, other accounts or exit plan. The learn guide on why mirroring a visible wallet fails and the SuperQuant review of copy-trading track records both work through that gap.
A checklist before using a wallet signal
Before an on-chain observation becomes a research input, write down:
- Address identity. Is it a user wallet, a program-owned account, a pool, a locker or a custodial address? How do you know?
- Label source and date. Who assigned the tag, on what evidence, and was it available before the event you are studying?
- Block time versus observation time. When did the event happen, and when could your source have shown it to you?
- Commitment level. Was the transaction processed, confirmed or finalized when you used it?
- Fact versus reality. What does the record prove, and what does it leave to off-chain custody, agreements or intent? See where on-chain verification stops.
- Alternative explanations. List at least two other stories that fit the same transfer.
- Execution. At what later time, price and cost could a follower actually have acted?
SuperQuant’s included examples use synthetic hourly data, and the workspace does not place live orders or verify live execution. Where it reads a public address’s history, treat that history as unverified context, not a track record.
Keep learning
The on-chain topic hub collects the explorer, labeling and holder-analysis guides in one place. When a wallet move coincides with news, the SuperQuant guide to building an event evidence timeline shows how to keep sources and timestamps in order. This is educational research context, not investment advice.