Why a Token Can Pass a Scan and Still Be Risky

Start by matching the network and full contract or mint address. A familiar name, ticker or logo is not enough: unrelated tokens can use the same branding. Then check when the report was produced and whether the market data, permissions and holder evidence were acquired at comparable times. A saved screenshot can look reassuring long after the underlying conditions have changed.

Separate a completed check from an unavailable one. If a report could not establish who controls a liquidity position, that is an unanswered question. It should not be interpreted as evidence that the position is locked. Likewise, finding no concerning transaction in a limited history is different from reviewing the entire relevant history.

Write down what each result actually proves. Contract verification means you can inspect published source associated with the deployed code; it does not mean someone audited the business or approved the token. A sell test concerns a particular transaction, route, size and state. Keeping those statements narrow helps you avoid turning a useful observation into a much broader promise.

• Confirm the exact address and chain.
• Check timestamps and coverage before interpreting a rating.
• Record unresolved questions separately from confirmed findings.

On Solana, check the mint account's current mint and freeze authorities. Under the standard Token Program, revoking a selected authority means setting that role to None. Sending an authority to an address described as a burn wallet is not the same operation. Removing mint authority also does not remove freeze authority: they are separate permissions. Tokens using the Token Extension Program may have additional controls that need separate inspection.

For an EVM token, inspect the actual privileged functions and their access rules. An owner address by itself does not prove the owner can mint, pause transfers or change fees. Those abilities depend on the code. Conversely, removing a conventional owner role may leave other administrator roles or upgrade powers active.

Build a small permission list: what action is possible, who can authorize it, and what limits apply? For a multisig, establish its signer threshold and membership where that information is available. Several signatures can reduce dependence on one key, but they do not establish that the signers are independent or that an authorized change will benefit holders.

A large displayed liquidity value does not tell you exactly how much you could receive when selling. Check the trading pair, quote asset and route. Then compare indicative sell quotes at more than one size without signing a transaction. A quote is still a snapshot, but it can expose a market that becomes expensive to exit as trade size increases.

Consider a hypothetical comparison: a small sell quote has modest price impact, while a much larger sell quote has substantially worse execution. That difference is evidence of limited depth for the larger order. It does not, by itself, prove a honeypot or deliberate manipulation. Fees, available routes and market conditions also affect execution.

Pool design matters. In a concentrated-liquidity pool, a position provides active liquidity only while the price is within its selected range. Total deposits can therefore overstate the liquidity currently available around the market price. In a conventional constant-product pool, reserves and trade size determine execution along the price curve. Describing such a pool as providing equally deep liquidity at every price would be misleading.

Treat a successful sell simulation as evidence about the tested conditions. Future changes to reserves, permissions, fees or trading routes can produce a different result.

Look for the on-chain record rather than relying on a badge or announcement. Identify the pool, the locked asset, the quantity or position, the beneficiary, and the unlock conditions. A lock for one pool does not establish that all of a token's liquidity is protected. An expired lock offers a different picture from a lock that remains active.

Conventional LP tokens and concentrated-liquidity positions require different checks. A claim about burned LP tokens should not automatically be applied to a position represented by an NFT or another protocol-specific structure. If you cannot identify the pool type and the relevant ownership evidence, record the result as unresolved.

A lock addresses a specific withdrawal right. It does not prevent a large token holder from selling their own tokens, remove token-contract administrator powers, or guarantee useful trading depth. Check any documented emergency withdrawal, migration or upgrade provisions in the locking mechanism itself. The point is to understand the actual conditions, not to assume every lock has the same protections or weaknesses.

Several wallets holding the same token does not establish that one person controls them. Shared funding can also have ordinary explanations: an exchange, bridge, payment service or distributor may fund many unrelated users. A connection becomes more informative when you can explain the transactions behind it and consider those alternative explanations.

Look for corroboration rather than a dramatic graph. For example, repeated transfers between the same wallets, coordinated timing and a common deployment history may justify further investigation. Even then, describe the observed pattern and your uncertainty. Keep a verified creator transfer separate from an inference about an unidentified wallet.

Concentration remains relevant even when ownership is unknown. A large holder may affect market conditions if it sells, but a pool account, locker or exchange address needs context before being treated as an ordinary trader. Preserve transaction hashes, amounts and timestamps so the interpretation can be checked later. An attractive visualization is a starting point; the underlying records are the evidence.

Imagine a hypothetical EVM token with verified source code and a successful small sell simulation. Further inspection shows a privileged role that can pause transfers, a liquidity lock that expires soon, and one non-pool wallet holding a substantial share of supply. None of those observations automatically proves fraud. Together, however, they identify specific questions that a sell simulation alone did not answer.

You would want to establish who holds the pausing role, whether it is still effective, what the lock covers after expiry, and how the large wallet received its tokens. If those questions remain unanswered, a confident conclusion would run ahead of the evidence. This example describes a research process, not a real token or a claim that Rug.Tools would miss those controls.

Use the same routine when reading a Rug.Tools report: verify the address, review each finding and its coverage, and follow the relevant on-chain evidence where more context is needed. If important conditions change, revisit the evidence. Repeating a scan without understanding what changed is less useful than checking the particular permission, position or transaction that could alter your assessment.