On-Chain Data Explained: Types, Solana Collection and Risk
What on-chain data is, its key types, how Solana collects it, and how to use it to spot token risks before you trade.
Published
Updated
You've found a Solana token with a rising chart, busy trading, and a holder list that looks reassuringly spread out. Before buying, you want to know whether those wallets represent independent demand, whether the liquidity is usable, and whether the creator still has powers that could change your position.
On-chain data lets you investigate those questions against the public ledger. It doesn't tell you what to buy. It gives you evidence you can inspect, compare, and revisit, provided you distinguish recorded actions from assumptions about who performed them.
Table of Contents
- What On-Chain Data Records and Why It Matters
- Core On-Chain Data Types and What Each Reveals
- How Solana On-Chain Data Is Collected
- Why Holder Counts Alone Miss Coordinated Wallets
- How to Run a Time-Stamped Token Risk Check
- Where On-Chain Data Falls Short
- Start Your First Dated Token Check
What On-Chain Data Records and Why It Matters
On-chain data is the permanent, publicly inspectable record of activity recorded on a blockchain. Think of it as a shared logbook whose entries are signed with pseudonyms. Anyone can inspect the entries, but there isn't necessarily a person's name beside each signature.
For a trader, that logbook contains evidence of transfers, swaps, balances, and changes to program-controlled accounts. The useful question isn't whether an entry exists. It's whether the entry supports the claim someone is making about a token.
The ledger analogy helps separate the public record from the interpretation attached to it.
What a Solana record looks like
Say you're checking a claimed transfer from a creator-controlled wallet into a liquidity pool. Rather than accepting a screenshot, open the relevant transaction in a Solana explorer and inspect:
- Transaction signature: The identifier you can save and reopen.
- Accounts and movement: The source and destination token accounts, the token mint, and the amount moved.
- Timing: The slot and available block time.
- Outcome: Whether the transaction succeeded.
- Program calls: The programs and instructions involved in the action.
A swap can involve more than a simple sender-to-recipient transfer. Read the decoded instructions alongside balance changes so you don't mistake an intermediate account movement for the trader's final result.
Evidence independent of the announcement
An exchange price describes a market quotation. A project announcement describes what its authors say happened. The ledger provides a separate transaction trail against which you can test the on-chain part of that statement.
Bitcoin uses the same broad ledger principle, with blocks appended approximately every 10 minutes, as described in the Bitcoin blockchain analysis paper hosted by MIT Sloan. Turning those records into useful histories requires analysts to organize transactions, reconstruct flows, and connect related addresses rather than read isolated entries.
Practical rule: Separate what the ledger records from what you infer about the people behind it.
A completed transfer can support a claim about asset movement. It can't, by itself, establish an independent buyer, a commercial purpose, or honest intent. An address isn't a person, so on-chain data establishes behavior more reliably than identity.
Core On-Chain Data Types and What Each Reveals
The most useful starting point is a map of what you can inspect and which risk question each record helps answer.
| Data type | What it records | Risk question it answers | Where to read it |
|---|---|---|---|
| Transactions | Signed actions with participating accounts, fee, status, and block time | Did the action succeed, who signed, and when? | Block explorer or Solana RPC node |
| Token transfers | Movements of a token between accounts and associated balance changes | Does apparent activity involve independent trading or repeated movements among linked wallets? | Token account history |
| Holder distribution | Balance per holder address and share of total supply | How concentrated is supply, and are the largest holders linked? | Holder list sorted by balance |
| Liquidity | Pool reserves, liquidity-position or LP token ownership, and withdrawals | What selling capacity is available, and who can remove liquidity? | Pool account state and applicable LP lock or burn records |
| Creator and account state | Mint authority, freeze authority, creator wallet, and funding history | Who retains control, and can an authority issue supply or restrict token accounts? | Mint account and creator wallet history |
Read the records as a connected account
Transactions establish the sequence. They help you distinguish an initial allocation from a later sale, or a liquidity deposit from a withdrawal. Without that sequence, a current balance can hide the action that produced it.
Token transfers add detail, but a transfer isn't automatically a trade. A creator moving tokens between controlled accounts changes their location without necessarily changing their economic ownership. To classify a sale, look for the relevant swap instructions and the corresponding movement of the asset received.
Holder distribution describes the resulting ownership pattern at a particular moment. Before interpreting a ranked list, identify pool accounts, program-controlled accounts, and other addresses whose role differs from an ordinary trader's wallet. Otherwise, you might treat market infrastructure as discretionary insider holdings.
Liquidity answers a different question: what happens if you need to exit? Read reserves alongside the pool's mechanics and a quote for your intended trade size. A liquidity balance alone doesn't establish an acceptable execution price.
Creator and account state describe retained powers. A revoked authority answers a narrow control question, not every question about the token. Existing insider inventory or removable liquidity can remain relevant even when particular token authorities are absent.
Resolve the immediate risks first
For a new token, start with liquidity and authority fields, then investigate distribution and activity. This is an analytical priority, not a universal ranking: establish whether the market has usable exit capacity and whether someone retains consequential controls before treating a broad holder list as reassurance.
Consider a hypothetical token with dispersed balances but creator-controlled liquidity. Its holder distribution doesn't resolve the creator's withdrawal power. Conversely, a large address may belong to a pool rather than an insider, so its percentage needs classification before interpretation.
The strongest assessment connects control, ownership, actions, and execution conditions. Each data type answers part of the question. None should be promoted into a complete verdict.
How Solana On-Chain Data Is Collected
Solana records are gathered through an RPC node or indexer, then decoded into actions and state changes. The unit of evidence is the complete transaction, not a promising-looking log line.
The process below emphasizes transaction outcomes. Failed transactions can still appear in the ledger, so distinguish a recorded attempt from a committed change.
Protocol limits worth recording
The Solana transaction documentation specifies a 1,232-byte serialized transaction limit, a normal 64-account reference limit, and a 150-slot blockhash processing window. The Solana account documentation specifies 10 MiB maximum account data, 10 KiB permitted account-data growth per instruction, and a 20 MiB per-transaction growth ceiling.
| Limit | Value | Effect on collection |
|---|---|---|
| Serialized transaction size | 1,232 bytes | Complex routes may require linked transactions |
| Accounts per transaction | 64, normal limit | Account-heavy operations may span transactions |
| Blockhash processing window | 150 slots | Check whether a submitted transaction landed rather than assuming settlement |
| Maximum data per account | 10 MiB | Reconstruct large state structures account by account |
| Account data growth per instruction | 10 KiB | Trace allocation and growth through individual instructions |
| Account data growth per transaction | 20 MiB | Check how state growth is distributed across transactions |
Solana transactions execute atomically: if an instruction fails, the intended instruction-driven state changes are reverted. Fees can still be charged, so a failed attempt mustn't be treated as though nothing was recorded or no cost occurred.
Build a reproducible collection trail
- Choose an RPC node or indexer. Record its rate limits, historical coverage, and commitment setting so you know what you can retrieve reliably.
- Gather relevant signatures. Query the mint, pool, creator, and relevant token accounts. Don't assume the mint's address history contains every transfer involving its token.
- Fetch full transactions. Preserve the raw response and execution status before assigning labels such as sale, withdrawal, or authority change.
- Decode execution context. Capture instruction order, signers, writable accounts, available compute-unit usage, and block position.
- Snapshot account state. Record mint and freeze authorities, token balances, pool reserves, and account ownership at the observation point.
- Store ordering information. Keep slots, available block times, and retrieval times so another analyst can reconstruct your reading.
The Solana token analysis methodology provides a complementary explanation of how these records become token-level checks.
This video offers another way to follow the collection workflow.
Complex swaps and bundled launch activity can involve multiple transactions. Join them using shared accounts, funding relationships, and timing, while keeping the distinction between an observed connection and inferred common control.
Why Holder Counts Alone Miss Coordinated Wallets
A reassuring top-wallet percentage can coexist with coordinated distribution. In a 2025 Solana study covering 767 meme-coin projects and 754,849 transactions, researchers identified patterns involving roughly 100 wallets receiving equal allocations from a central wallet and trading exclusively against the liquidity pool, as described in the ACM conference paper on meme-coin trading behavior.
The trader's question is whether early activity represents independent demand. Counting addresses doesn't answer it when apparently separate wallets share funding and repeat the same actions.
Concentration risk means a large balance sits in a wallet. Coordinated-distribution risk means apparently separate wallets may function as a group.
Those risks require different checks. A holder list can expose the former directly; investigating the latter requires relationships and a timeline.
Test the relationships, not just the balances
- Common funder: Trace the funding that enabled wallets to become active. Distinguish direct creator funding from withdrawals through a shared service, since a common exchange source doesn't establish common ownership.
- Synchronized buying: Compare early purchases by slot and sequence. Closely timed activity becomes more informative when the wallets also share a funder or allocation pattern.
- Buy-sell asymmetry: Examine whether the suspected group repeatedly accumulates, distributes, or alternates actions in a consistent pattern. Compare token quantities and value flows, not just transaction counts.
- Repeated trade sizes: Look for recurring amounts and action sequences. Treat repetition as a lead, then check whether routing conventions or ordinary automation offer a plausible explanation.
For a fuller account of how to interpret those relationships, use the guide to Solana wallet clusters and what they mean.
Keep the conclusion narrower than the suspicion
Say several early buyers receive funding from the creator, purchase in a tight sequence, and later send proceeds to the same destination. That combination supports a stronger coordination hypothesis than timing alone. Preserve the signatures that establish each connection.
Now change the scenario: the wallets only share an exchange withdrawal source and bought during a public launch. The evidence is weaker because unrelated traders can use the same service and react to the same event.
Label clusters with a confidence level and a reason. A useful note distinguishes observed funding links from inferred control and records competing explanations. Possible coordination is a starting point for investigation, not proof of misconduct.
How to Run a Time-Stamped Token Risk Check
Timing changes what a warning means. A machine-learning study of early token trading assembled 6.4 million tokens launched between November 30, 2024, and June 30, 2025, reported that many displayed rug-pull characteristics within the first hour, and found that models using only the first five minutes of trading data could detect risk.
That finding supports early observation, not a promise that every dangerous token can be identified immediately. A useful assessment states what was observable, when it was observable, and what remained unresolved.
Compare dated records rather than treating a token label as permanent.
Capture evidence in a repeatable order
- Record launch provenance. Save the creator's funding trail and initial distribution transactions. Separate directly observed relationships from assumptions about wallet ownership.
- Inspect the earliest trading sequence for bursts, repeated sizes, and unusual allocation-to-sale patterns. Keep the transaction references behind any warning.
- Measure current exit conditions. Record pool reserves, the quote for your intended sale size, and applicable liquidity-position ownership or lock evidence. Confirm which pool and assets each record covers.
- Apply the common-funder and synchronized-buying tests to early holders. Save any proposed cluster with its confidence level and the evidence that could weaken it.
- Date and classify the assessment. Use a stage label such as launch-stage, live-market, or post-flag. Include the latest observed slot, retrieval time, source coverage, and unresolved checks.
- Schedule another observation and define event-triggered reviews. Migration, fresh liquidity, authority changes, or creator selling should prompt a new reading rather than wait for a routine review.
The dated Solana rug-check workflow offers a practical way to organize these observations.
Define what would invalidate the reading
Say your initial warning concerns shallow liquidity in a launch pool. The token later migrates, and trading moves into a different pool. The old warning remains an accurate description of the earlier observation, but it no longer describes the active trading venue.
Reassess the new pool instead of just deleting the warning or declaring the issue resolved. Check the destination, liquidity ownership, reserves, and whether the creator's position changed during migration.
A useful record separates observed conditions, interpretation, and review triggers. That makes disagreement testable: another trader can inspect the same evidence without having to accept your conclusion.
A clean result means the completed checks didn't reveal the specified warning signs at that moment. It isn't a guarantee of safety, and an uncompleted check isn't a clean result.
Where On-Chain Data Falls Short
Missing data is not proof of safety.
The ledger can be public while your view of it remains incomplete. An RPC response, explorer display, or indexer result is an access path to evidence, not a guarantee that you've retrieved every relevant record.
Common misreadings and their fixes
| Misreading | Better analytical response |
|---|---|
| Address growth equals user growth | Report addresses as addresses. Use cautiously labelled clusters when estimating distinct control, not a claimed headcount of people. |
| High volume proves genuine demand | Trace counterparties and net asset movement to investigate circular activity. |
| An instruction log proves completion | Verify the complete transaction outcome and resulting state. |
| A holder percentage settles the risk question | Classify the address and assess its relationship to controls and exit conditions. |
| An old snapshot describes the current market | Check for intervening events before applying its conclusion to a trade. |
These corrections prevent a category error: treating a convenient metric as the thing you really want to know. Wallet count is observable; independent participation requires interpretation. A completed action is observable; the actor's motive usually isn't.
Distinguish unknown from negative
If a node is behind the chain or an indexer has a coverage gap, a missing sale may reflect missing retrieval rather than an absence of selling. Record both the chain position you inspected and the time you retrieved it.
Use explicit labels. Unknown liquidity control means the required ownership or lock evidence wasn't established. It doesn't mean liquidity is protected, and it doesn't establish that someone will remove it.
Automated explanations introduce another interpretation layer. At MemeAssist, we acknowledge that AI can misinterpret information or produce an erroneous explanation, and that blockchain and market data can be incomplete, delayed, or unavailable. A confident sentence should never outrank the raw evidence behind it.
Before acting on a strong claim, perform these checks:
- Confirm the window: Does the evidence cover the period relevant to your decision?
- Confirm the transaction: Does the raw record support the described action and outcome?
- Confirm coverage: Were the relevant accounts and records available throughout that window?
On-chain analysis is strongest when the conclusion includes its boundary. State what you verified, what you inferred, and what you couldn't establish.
Start Your First Dated Token Check
Choose a token you already follow rather than searching for an unfamiliar launch. Familiarity gives you a useful comparison between the public story you've heard and the evidence you can retrieve.
Create a record you can reopen
- Identify the token by mint address. Save it with the creator and active pool addresses so a matching ticker doesn't send you to the wrong asset.
- Open a public Solana explorer and inspect raw transactions involving the creator and liquidity pool. Save the signatures supporting your main observations.
- Complete the data-type checklist. Record transactions, token transfers, holder distribution, liquidity, and creator or account state. Put an observation time beside each entry.
- Write down unresolved questions, including uncertainty about linked-wallet control or incomplete pool-ownership evidence.
- Repeat after a day as a practical review schedule. Compare the dated records and explain which changes affect your original interpretation. Review sooner if a material event occurs.
Keep the record compact enough that you'll really revisit it. A saved conclusion without its evidence is difficult to audit later.
Use automation for organization, not certainty
Our AI-powered Solana token report combines token controls, wallet evidence, and market structure with an Overall Health Score, Rug Risk Rating, AI Verdict, and Detailed Risk Breakdown. Reading public token evidence and reopening saved reports is free; running a new analysis is a paid action.
Choose MemeAssist for integrated research, explanations, and tracking, not exclusive blockchain data, safety guarantees, or profit promises. The purpose is to bring the checks together and make their implications easier to evaluate, not replace your judgment with a score.
Visit MemeAssist to inspect public token evidence and bring on-chain checks into an explained Solana report. Start with a token you follow, review the supporting records, and save a dated assessment you can compare when conditions change.