Risk rules
Version 1. Each rule reads one value, compares it with a fixed threshold and prints both on the report. Levels are clear, note, caution and flag. They are indicators, not a verdict, and they are not a substitute for an independent code review of any program a token depends on.
Contract settings
Holders
Liquidity
Market
Why these thresholds
The numbers are deliberately plain. A top-ten share of 30% is where a handful of sellers can start to move the market on their own; at 50% they can decide it. Liquidity under $50,000 means a four-figure order already moves the price noticeably. A market cap more than a hundred times its liquidity (under 1%) describes a valuation that a modest amount of selling cannot be absorbed by.
None of these is a law. A new token can be perfectly fine with one pool, and an old token can be dangerous with many. That is why each line shows its input: so you can apply your own judgement to the same evidence.
What the rules cannot see
- Wallets that belong to a team but are not labelled anywhere on chain.
- Promises made off chain, vesting agreements, or plans to sell.
- Whether a program a token depends on has bugs. Reading account settings is not the same as reading code.
- Liquidity in venues the public pair index does not list.
- Anything that changes after the report was read. Reports are cached for a minute.
Holder figures
On-chain holder data needs the getTokenLargestAccounts call, which free public nodes usually refuse. When it works, the report groups the largest accounts by owner and leaves pool and curve accounts out of the top-ten share. When it does not, the report uses the public token index's top-holder percentage instead and marks that line as a third-party figure. A site owner can add a private RPC endpoint to get the on-chain version every time; see Data sources.