SAYLOR Measure concentration, linked ownership, creator activity, liquidity control, authorities, and trading conditions while clearly separating observations from predictions.
The result you're 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/integration or monitoring changes.
- Explaining why top-holder percentage alone is misleading.
Do not use it as a substitute for
- Do not guarantee a token cannot rug or will be profitable.
- Do not count LP, burn, exchange, program, vesting, or pool vault addresses as ordinary insiders without classification.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- 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.
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.
Concentration needs circulating/accessible denominator
Locked/burned/LP/vesting classifications change interpretation but require proof.
Rug risk is multi-dimensional
Supply control, liquidity withdrawal, transfer restrictions, linked wallets, upgradeability, market depth and behavior can fail independently.
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 ordinary wallet. |
| Many wallets funded together | Linked control | Funding/transfer timing and common controller evidence | Cluster as possible common owner with confidence; do not assert identity. |
| LP appears locked | Liquidity custody | Verify position/LP owner, lock contract, expiry, withdrawal rights | Marketing claim alone is not proof; permanent vs vesting differs. |
| Small buy works, sell fails | Trading restriction | Simulate/execute tiny round trip safely | Hook/tax/transfer/account/liquidity issue; high-risk stop. |
| Depth collapses at size | Market risk | Quote price impact for realistic entry/exit | Nominal TVL/market cap does not equal executable exit. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Anchor asset and snapshot
Why: Wrong mint/stale data invalidates the report.
Do: Record chain/mint/program, slot/time, supply/decimals and data-provider context; cross-check authoritative RPC.
Read the result: All downstream calculations use same snapshot window.
Next: Reject unresolved identity.
Step 02 — Classify holders and controllers
Why: Raw account ranking overstates/understates concentration.
Do: Resolve token account owners and label pools/vaults/burn/vesting/treasury/exchange/program where evidenced; aggregate wallet-controlled accounts; preserve unknown class.
Read the result: Publish inclusion/exclusion rules and both raw/adjusted metrics.
Next: Do not guess labels.
Step 03 — Measure concentration and linkage
Why: Top-10 alone misses clusters and change.
Do: Compute top1/5/10/20 of defined supply, HHI/Gini if useful, creator/insider cluster, new-wallet/funding/transfer patterns and time changes.
Read the result: Linked-control claims include evidence/confidence and alternative explanations.
Next: Alert cluster transfers to exchanges/pools.
Step 04 — Verify liquidity control and exit depth
Why: Displayed liquidity may be removable or too shallow.
Do: Identify pools/programs/vaults/position owners/LP tokens/locks/vesting/expiry; quote executable sells at several sizes including fees/impact/slippage.
Read the result: Report one-sided/out-of-range/low-volume conditions.
Next: No 'locked' claim without on-chain mechanism.
Step 05 — Decode token/program controls
Why: Authorities/hooks can alter trading or accounts.
Do: Apply authority decoder, metadata mutability, Token-2022 extensions, upgrade/program controls, taxes/fees/honeypot-like restrictions and tiny round-trip test if authorized.
Read the result: Unknown custom program lowers confidence.
Next: Keep transaction amount disposable.
Step 06 — Issue scorecard without prophecy
Why: A score must expose reasons and uncertainty.
Do: Report red flags/protective observations, weights/version, raw metrics, evidence, data gaps, scenario exit loss, changes and no-guarantee language.
Read the result: A score cannot override hard stop or missing data.
Next: Timestamp and recheck triggers.
Worked example
Evidence collected
- Forty wallets received funds from the same creator funding wallet minutes before launch.
- Combined cluster controls 38%.
- LP position NFT is held by creator wallet with no verified lock.
- A 2% supply sell has extreme price impact.
Decision: Per-wallet ranking and marketing label hide linked concentration and removable/shallow liquidity.
Actions taken
- Aggregated evidenced wallet cluster with confidence.
- Verified position ownership/lock status on-chain.
- Calculated executable exit scenarios and disclosed unknowns.
Why this example matters: Useful analysis explains mechanisms that could create loss instead of issuing a false badge.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Exact mint/program/snapshot and same-window data.
- Holder accounts are owner-aggregated/classified with rules.
- Linked clusters include evidence/confidence.
- Liquidity ownership/locks/expiry/exit depth are verified.
- Authorities/extensions/trading simulation are separate dimensions.
- Score version, gaps, scenarios and non-guarantee are explicit.
Rollback or safe recovery
- Withdraw/replace report when labels/parser/snapshot are wrong.
- Return to prior verified snapshot and recompute with same methodology.
- Disable automated purchase on stale/missing/hard-stop data.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Providers disagree on holders | Snapshot/token-account aggregation difference. | Use RPC/context and reproduce aggregation. |
| LP lock unclear | Position type/custom locker not decoded. | Mark unknown; inspect program/account/expiry; no safe claim. |
| Sell simulation succeeds but real fails | State changed/priority/quote/account issue. | Use tiny disposable test and reconcile exact program logs. |
| Score remains high despite hard flag | Weight model masks catastrophic condition. | Use non-compensable stop flags outside weighted score. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- 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.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points