Analyzing a Token On-Chain (Holders, Liquidity, Contract)

The essentials

This guide is general information for educational purposes. It does not constitute investment advice.

Why analyze a token "on-chain"?

A website, an X account or a Telegram group presents a project the way its creators want. The blockchain, on the other hand, records what actually happens: transfers, each address's balance, the code of the contract that runs the token.

Analyzing a token on-chain means reading this data directly, with public tools, rather than relying on marketing talk. The goal isn't to predict the price, but to answer four simple questions:

1. Is the token concentrated in a few hands?
2. Can you actually sell it, and at what price?
3. Does the contract give anyone dangerous powers?
4. Are large quantities about to be unlocked soon?

The basic tools

You don't need to be a developer. A few families of tools are enough. The names below are common examples, cited for illustration.

Rule number one: always start from the contract address, never from the name or ticker. Anyone can create a token named after a well-known project. The official address is found in the project's documentation, and you can cross-check it across several sources. If you're new to explorers, the guide reading a block explorer explains how they work.

Step 1: holder distribution

A holder is an address that holds the token. On an explorer like Etherscan, a token's holders tab lists addresses by descending balance, with the percentage of supply each one holds.

What to look at

• The share of the top 10 holders. If a few addresses hold most of the supply, they can crash the price by selling.
• The nature of those addresses. A large address isn't necessarily an individual. It could be the liquidity pool, a vesting contract (gradual lockup), a project treasury or a centralized exchange's wallet. Explorers often show a label; otherwise, click the address to see whether it's a contract.
• Links between addresses. Ten addresses that each hold 3% may actually belong to the same person, who funded them from a common wallet.

Visualizing the links

That's the value of tools like Bubblemaps: each "bubble" represents one of the main holders (its size depends on the balance), and the lines between bubbles show transfers between those addresses. Connected bubbles form a cluster. According to the tool's documentation, centralized exchange, DEX pool and contract addresses are hidden by default, to focus on the real holders.

A cluster isn't proof of fraud: a team paying its members or a fund distributing tokens also creates links. But a large unexplained cluster, especially one funded just before launch, deserves real caution.

Step 2: liquidity and its lock

Liquidity is the quantity of assets available to buy or sell the token without moving the price excessively. For a token traded on a DEX (decentralized exchange), it sits in a pool: a contract that holds both the token and a counterpart asset (ETH, SOL, USDC...).

Depth

On an aggregator like DEX Screener, each pair shows the pool's total liquidity, volume and transaction history. Compare the liquidity to the displayed market cap:

• A market cap of several million with a few tens of thousands of euros of liquidity means an average-sized sale is enough to collapse the price.
• Also check that it isn't just one small pair among others: add up the main pairs.

To understand pool mechanics well, see the guide liquidity pools and impermanent loss.

Who can withdraw the liquidity?

On many DEXs, the person who adds the liquidity receives LP tokens (or an NFT position) representing their share of the pool. Whoever holds these tokens can withdraw the liquidity at any time. This is the classic "rug pull" mechanism: the creators pull the liquidity and the token becomes impossible to sell.

Three situations come up often:

• Locked liquidity: the LP tokens are deposited in a lock contract until a given date. Check the end date and the share that's locked, not just the word "locked".
• Burned liquidity: the LP tokens were sent to an unusable address. Withdrawal becomes impossible.
• Unlocked liquidity: the LP tokens are in an ordinary wallet. The withdrawal risk is fully present.

Go and check the lock or burn transaction on the explorer rather than trusting a screenshot.

Step 3: the token contract

Is the code verified?

A contract deployed on the blockchain is, originally, just unreadable bytecode. Source code verification means publishing the readable code and proving that it matches the deployed bytecode exactly. As ethereum.org explains, this lets anyone check that the advertised code is the code that actually runs.

On Etherscan and similar explorers, a verified contract shows a "Contract" tab with the source code and a checkmark. A token whose code isn't verified allows no serious analysis: it's a major red flag.

Owner privileges

Many contracts designate an owner, an address that can call certain restricted functions. In the widely used OpenZeppelin library, these functions are marked with the onlyOwner modifier. In the "Read Contract" tab, the owner function shows the current owner's address.

In the code or the "Write Contract" tab, look for functions that allow:

• creating new tokens (mint): diluting holders at will;
• pausing transfers (pause);
• blocking addresses (blacklist): preventing you from selling;
• changing buy or sell taxes (setFee, setTax): a sell tax raised to 99% makes the token practically unsellable;
• limiting transaction or wallet sizes.

Some of these functions exist for good reasons (for example freezing addresses on certain regulated stablecoins). The question is: who controls them, and with what safeguards?

Renouncing, multisig, proxy

• Renounced ownership: the renounceOwnership function lets the owner permanently give up their role. The owner address then becomes the zero address, and the restricted functions can no longer be called by anyone. Check the corresponding transaction.
• Ownership held by a multisig: the owner is a wallet that requires several signatures (see the multisig guide). That's safer than a single key, though not a guarantee.
• Proxy (upgradeable) contract: the address you see is a "proxy" that redirects to an implementation contract. According to the OpenZeppelin documentation, an administrator can replace this implementation without changing the token's address. In other words, the code can change tomorrow. Explorers generally flag these contracts ("Read as Proxy"). A renounced but upgradeable contract is therefore not frozen.

Step 4: the unlock schedule

Many projects don't issue their entire supply from the start. Team, investor or treasury tokens are often subject to vesting: they're released gradually on a schedule, sometimes after a waiting period called a cliff.

What to check:

• the share of supply currently in circulation versus the total supply;
• the dates of the next major unlocks;
• the addresses of the vesting contracts, which you can follow on the explorer.

A massive unlock can create selling pressure. The guide tokenomics, market cap, FDV and unlocks explains these concepts in detail.

A concrete example

Let's imagine a fictional token, "NOVA", launched two weeks ago on an Ethereum-compatible network. You want to get a feel for it before touching it.

1. Address: you get the contract address from the official documentation and paste it into the explorer. The name and symbol match.
2. Code: the contract is verified. The owner function returns an ordinary address (not a multisig). In the code, you find a setSellTax function with no cap.
3. Holders: the top 10 hold 62% of the supply. The first address is the DEX pool (18%), the second a vesting contract (15%). The next eight each hold 3 to 4%.
4. Clusters: on a holder visualization, six of those eight addresses are connected and were funded by the same wallet the day before launch.
5. Liquidity: 40,000 dollars in the main pool for a displayed market cap of 8 million. The LP tokens are locked, but only for 30 days.
6. Unlock: the vesting contract releases 15% of the supply in three months.

Summary: a sell tax that a single key can change without limit, supply concentrated in a group of linked addresses, low liquidity locked for a short time. None of these proves a scam, but together they describe a very high risk profile.

Quick checklist

• Contract address obtained from an official source and cross-checked
• Source code verified on the explorer
• Owner identified: single key, multisig or renounced
• Proxy (upgradeable) contract or not
• Sensitive functions: mint, pause, blacklist, changeable taxes
• Top 10 share and nature of the large addresses
• Clusters of linked addresses explained or not
• Total liquidity compared to market cap
• LP tokens locked (until when) or burned
• Circulating supply and upcoming unlocks

Mistakes to avoid

• Searching for the token by name. Copies with the same name are common. Only the contract address is authoritative.
• Trusting the word "audit" or "SAFU". An audit covers one version of the code at a given date; it says nothing about the keys that control the contract or about holder distribution.
• Confusing renouncement with immutability. A proxy contract can be modified even if the token shows a renounced owner.
• Counting the pool or the vesting contract as a "whale". Always identify the nature of large addresses before concluding.
• Forgetting the lock duration. Liquidity locked for a few days offers little protection.
• Testing by buying. Buying a small amount "to see if you can resell" still exposes you to booby-trapped mechanisms. The guide spotting a rug pull details these signals.
• Treating an automated score as a verdict. Automated scoring tools help, but they can miss a booby-trapped function or wrongly flag a legitimate contract.

Key takeaways

• Always start from the contract address, never from the token's name.
• Unverified source code rules out any serious analysis and is a strong red flag.
• Look at who controls the contract: owner-only functions, multisig, renouncement, and the possibility of upgrades via a proxy.
• Holder distribution must be read alongside the nature of the addresses and the links between them.
• Compare liquidity to market cap and verify on the explorer that LP tokens are locked or burned, and until when.
• No on-chain analysis guarantees an investment: it reduces certain risks, it doesn't eliminate them.

Sources

• ethereum.org — Verifying smart contracts
• OpenZeppelin Docs — Access Control (Ownable, renounceOwnership)
• OpenZeppelin Docs — Proxy Upgrade Pattern
• Bubblemaps Wiki — How does it work?
• Etherscan Docs — Documentation de l'API (données on-chain, code source des contrats)

Compare services related to this topic

• Best crypto wallet: comparison