> For the complete documentation index, see [llms.txt](https://docs.digitaldon.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digitaldon.net/the-telegram-bot/holder-analysis.md). # Holder analysis The chart tells you what price did. Holder analysis tells you who's holding the bag and whether they're all the same person. Available as the **👥 Holder Analysis** button in Telegram and the **holder intelligence** panel (with the bubble map) in the Web Analyzer. Both run the same analysis, so the numbers are identical by construction, not by luck. ## What it reports ### Supply concentration | Verdict | Roughly | | ----------- | --------------------------------------------------------------------------------- | | 🔴 **High** | The top 10 hold a majority of supply, or one wallet holds an outsized share of it | | 🟡 **Mid** | Meaningful concentration, but short of that | | 🟢 **Low** | Neither | Plus the raw numbers: holder count, top 10 %, top 20 %, and the largest single wallet. Note this is **owner-level**, not account-level. On Solana one person can hold a token across many token accounts; aggregating by owner is the difference between "800 holders" and "800 accounts belonging to 300 people". ### Wallet clusters (bubbles) This is the interesting part. Ten wallets holding 3% each looks like healthy distribution. Ten wallets holding 3% each that were **all funded by the same address twenty minutes before launch** is one wallet holding 30% wearing a hat. The analysis traces how each significant holder was funded and when it first became active, then groups wallets that trace back to the same origin. Each cluster is reported with its combined percentage, its wallet count, and *why* it formed. **Evidence strength matters.** Some links are strong evidence of one operator; others are circumstantial, because plenty of legitimate infrastructure touches many wallets. Weak links are held to a higher bar before they form a cluster at all, and they can't push the risk verdict to High on their own. Known exchange wallets are excluded outright: everyone who bought on Coinbase shares a funding source, and that isn't a bubble. Any list of known exchange wallets is best-effort, so there's a behavioural backstop as well — an address that has funded thousands of wallets is infrastructure, not a deployer. ### Bubble risk 🔴 **High** / 🟡 **Mid** / 🟢 **Low**, derived from how much supply sits inside those clusters and how strong the evidence behind them is. The card also shows total connected supply, and separately how much of it rests on strong evidence — so you can see when a scary-looking number is mostly weak inference. ### Launch signals Who was around when the pool opened: | Signal | Meaning | | --------------- | --------------------------------------------------------------- | | 🌱 **Fresh** | Wallets whose first-ever activity is around this token's launch | | 🎯 **Snipers** | Bought in the earliest transactions after the pool opened | | 📦 **Bundle** | Buys landing together — coordinated, not coincidental | | 👤 **Insiders** | Wallets funded by the token's own creator | Where the size of the launch cohort is known, snipers and bundles are shown as `launch% → now%`. That arrow is the whole story: `40% → 4%` means they dumped; `40% → 38%` means they're still sitting on it. ### Wallet quality The top holders (LP excluded) bucketed by total portfolio value — whales, mids, and everything below. A holder base made entirely of tiny wallets gets flagged for paper-hand risk: nothing there is a conviction position. ### Security Where the data is available, contract security checks are layered on — mint authority, blacklist functions, rug ratio, and the big one: > ⛔ **HONEYPOT — sells are blocked. Do not buy.** If that's on the card, it's the first line, and nothing else on the card matters. ## Chain coverage | Chain | Coverage | | ------------------- | ------------------------------------------------------------------------------ | | **Solana** | Full — owner aggregation, funding traces, clusters, snipers, bundles, insiders | | **Ethereum / Base** | Full — same output, resolved through a different data path | | **BSC** | Partial — cluster evidence is thinner than on the chains above | | **Robinhood Chain** | Partial — core shared-funder clustering works; some signals are unavailable | Every chain returns the same shape of result, which is why the Telegram card, the web panel and the bubble map all work unchanged across chains. ## Why it's behind a button A full holder scan is expensive — it means walking the entire holder set and then tracing the history of each significant wallet to find where its funding came from. That's orders of magnitude more work than reading a chart, and running it on every `/don` would exhaust the day's capacity by lunchtime. So: on demand only, and results are cached per token for a while, so tapping the button twice in five minutes gives you the same answer without paying twice. It's also **budget-aware end to end**. If a data source is close to its ceiling, the analysis degrades to a partial result rather than failing — and any hiccup anywhere in the pipeline degrades to "unknown" rather than crashing. The button always answers with something. ## What it deliberately doesn't expose You get the significant holders — address, percentage and role tags — and, for the full view, what's needed to draw the map. You don't get the complete holder set or the internals behind the verdicts. That's enough to render the visualisation and check the work. It isn't enough to reconstruct the analysis, or to use the panel as a free data pipe. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.digitaldon.net/the-telegram-bot/holder-analysis.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.