> For the complete documentation index, see [llms.txt](https://solradar.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://solradar.gitbook.io/docs/safety-and-filtering.md). # Safety & Filtering This is the core of what SolRadar does differently. Every candidate token is checked against layers of automated filters before a single alert goes out. A token that fails any check is simply never posted — silently, with no exceptions made for hype or volume. ### On-chain authority checks * **Mint authority** — must be renounced, or the token is skipped. An active mint authority means the supply can be inflated at any time. * **Freeze authority** — checked and disclosed. An active freeze authority means holder wallets can be frozen at will. ### Liquidity checks * **Liquidity lock** — verified via RugCheck; new pairs require liquidity to be locked or burned above a strict threshold before they qualify. * **Liquidity-to-market-cap ratio** — a token's liquidity must be proportional to its market cap. A high market cap sitting on almost no liquidity is a classic sign of manipulated or already-drained pricing. * **Post-discovery re-verification** — every token is re-checked against live data immediately before posting, not just at the moment it was first discovered. A token that looked fine minutes ago but has since collapsed will not be posted. ### Holder distribution * **Minimum holder count** — a token needs a real, distributed holder base, not a handful of wallets. * **Non-pool concentration check** — SolRadar specifically excludes the liquidity pool itself from "top holder" calculations (a naive check would flag every token's own pool as a "whale"). What's measured instead is how much the largest *individual wallets* — excluding the pool — control. High concentration outside the pool is a real insider-risk signal. ### Deployer history Every early-stage alert shows how many tokens that developer wallet has deployed on pump.fun before. Wallets that have deployed an excessive number of tokens (a classic "spray and pray" pattern) are filtered out automatically, not just flagged. ### Manipulation & artificial-activity detection * **Mayhem Mode detection** — some pump.fun tokens are wash-traded by automated agents to fake momentum. SolRadar checks on-chain token supply patterns to detect and filter these out. * **Instant-rug age gating** — pools on DEXs with a known history of near-instant rugs are held back for a longer observation window before they can qualify, regardless of how good the numbers look in the first few minutes. * **Recent price-action checks** — a token showing a severe recent price collapse, or a sharp reversal after a big pump, is not posted — even if the longer-term numbers still look attractive. Calling a token *while it's actively dumping* is a bad entry, not an early one. * **Zero-activity filter** — a token with no real trading volume in the most recent windows is not posted, regardless of how clean its other metrics look. ### The bottom line None of these checks make a token "safe" — nothing in crypto is. What they do is remove the categories of failure that are detectable and preventable. See the [Risk Disclaimer](#page-7-risk-disclaimer) for what this does *not* protect against. --- # 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://solradar.gitbook.io/docs/safety-and-filtering.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.