SAYLOR The result you are building
A time-stamped token-risk report separating observable holder concentration, linked control, creator behavior, authorities, liquidity custody/locks, market depth, and trading constraints from uncertain prediction — with raw inputs, calculations, and stop flags.
Use this guide when: screening a token before trading or integration, monitoring for changes, or explaining why top-holder percentage alone is misleading.
Do not use it as a substitute for: guaranteeing a token cannot rug or will be profitable, or counting LP/burn/exchange/program/vesting/pool-vault addresses as ordinary insiders without classification first.
Before you change anything, collect: exact chain/mint, observed block/slot/time, and token program; supply, holder accounts/owners, labeled addresses and related transfers; liquidity pools/vaults/position ownership/locks and executable exit depth; authorities/extensions, creator/funder/deployer history, taxes/hooks/trading simulation.
Stop an automated favorable verdict when holder or liquidity data is incomplete/stale, unknown extensions/hooks exist, sell simulation fails, liquidity isn't independently verified, or controller linkage is unresolved.
Understand the system before fixing it
- Token accounts are not always independent owners. On Solana, multiple token accounts can share one wallet owner; PDAs/vaults/program accounts need classification before counting them as holders.
- Concentration needs a circulating/accessible denominator. Locked/burned/LP/vesting classifications change interpretation but require proof, not a label.
- Rug risk is multi-dimensional. Supply control, liquidity withdrawal, transfer restrictions, linked wallets, upgradeability, market depth, and behavior can each fail independently — a clean score on one axis says nothing about the others.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Top holders are pools/vaults | Classification | Resolve owner program and pool role | Exclude/classify transparently, not as an ordinary wallet |
| Many wallets funded together | Linked control | Funding/transfer timing and common controller evidence | Cluster as possible common owner with stated confidence — don't assert identity |
| LP appears locked | Liquidity custody | Verify position/LP owner, lock contract, expiry, withdrawal rights | A marketing claim alone is not proof; permanent vs vesting differs |
| Small buy works, sell fails | Trading restriction | Simulate/execute a tiny round trip safely | Hook/tax/transfer/account/liquidity issue — high-risk stop |
| Depth collapses at size | Market risk | Quote price impact for a realistic entry/exit | Nominal TVL/market cap does not equal executable exit |
Step-by-step procedure
01. Anchor asset and snapshot. Record chain/mint/program, slot/time, supply/decimals, and data-provider context; cross-check against an authoritative RPC. All downstream calculations use the same snapshot window.
02. Classify holders and controllers. Resolve token account owners and label pools/vaults/burn/vesting/treasury/exchange/program where evidenced; aggregate wallet-controlled accounts; preserve an "unknown" class rather than guessing labels. Publish inclusion/exclusion rules alongside both raw and adjusted metrics.
03. Measure concentration and linkage. Compute top-1/5/10/20 of a clearly defined supply denominator, and identify creator/insider clusters and new-wallet/funding/transfer patterns over time. Any linked-control claim carries evidence, confidence, and alternative explanations.
04. Verify liquidity control and exit depth. Identify pools/programs/vaults/position owners/LP tokens/locks/vesting/expiry; quote executable sells at several sizes including fees, price impact, and slippage. No "locked" claim without a verifiable on-chain mechanism.
05. Decode token/program controls. Apply the authority decoder, check metadata mutability, Token-2022 extensions, upgrade/program controls, taxes/fees/honeypot-like restrictions, and a tiny authorized round-trip test. An unknown custom program lowers confidence.
06. Issue a scorecard without prophecy. Report red flags and protective observations, weights/version, raw metrics, evidence, data gaps, scenario exit loss, changes since last check, and explicit non-guarantee language. A score can never override a hard stop or missing data.
Worked example
Starting problem: a token shows 2% top-wallet concentration and "locked LP," appearing decentralized.
Evidence collected: forty wallets received funds from the same creator funding wallet minutes before launch; the combined cluster controls 38%; the LP position NFT is held by the creator wallet with no verified lock; a 2% supply sell has extreme price impact.
Decision: per-wallet ranking and the marketing label hide linked concentration and removable/shallow liquidity.
Actions taken: aggregated the evidenced wallet cluster with a stated confidence; verified position ownership/lock status on-chain; calculated executable exit scenarios and disclosed unknowns.
Proof of completion: the report shows raw and clustered concentration, liquidity-control evidence, price-impact scenarios, authorities, and hard risk flags — it makes no rug prediction.
Why this matters: useful analysis explains the mechanisms that could create loss instead of issuing a false badge.
Verify, recover, and hand off
A report is complete only when: mint/program/snapshot are exact and use the same-window data; holder accounts are owner-aggregated and classified with stated rules; linked clusters include evidence and confidence; liquidity ownership/locks/expiry/exit depth are verified; authorities/extensions/trading simulation are reported as separate dimensions; and the score version, gaps, scenarios, and non-guarantee are explicit.
If providers disagree on holder counts, use consistent RPC context and reproduce the aggregation. If an LP lock is unclear, mark it unknown and inspect the program/account/expiry — don't make a safe claim. If a sell simulation succeeds but a real sell fails, use a tiny disposable test and reconcile exact program logs. If a score stays high despite a hard flag, use non-compensable stop flags outside the weighted score.
Reusable handoff record: asset/snapshot/data-source identity; raw and classified owner concentration; linked-control evidence and confidence; liquidity custody/lock/exit-depth scenarios; authorities/trading constraints/score version/gaps/disclaimer.
For agents
A useful automated version of this guide never returns a single opaque "safe/unsafe" number — it returns the evidence, the classification rules used, and confidence per dimension, with hard stop flags that can't be averaged away by an otherwise-good score. Refuse any workflow that would require a seed phrase or private key; none of this analysis needs one. Escalate rather than guess when holder or liquidity data is incomplete or stale.
Official references: https://solana.com/docs/rpc/http/gettokenlargestaccounts · https://solana.com/docs/rpc/http/gettokenaccountsbyowner · https://solana.com/docs/tokens
*This is educational technical and risk-analysis information, not financial, investment, legal, or tax advice. Blockchain transactions can be irreversible and no checklist can guarantee safety or profit.*