Rug pull checker

The mechanics, not the intent

'Rug pull' describes an outcome — holders left with a token they cannot sell for anything near what they paid — reached by several different routes. In a liquidity rug, whoever holds the LP tokens withdraws the pooled assets, and the price collapses because there is nothing left to sell into. In a supply rug, a wallet holding a large share of supply sells into the pool until it is drained. In a permissions rug, the contract owner blocks selling or taxes it to nothing while exiting themselves. A slow rug does none of these dramatically and simply drains value over weeks.

Intent is not observable on-chain, and ScanZX does not claim to observe it. What is observable is capability: who can remove liquidity, who holds enough supply to matter, what the contract lets the owner do, and whether this deployer has done it before. A token where nobody has the capability is in a materially different position from one where a single key holder has all four, and that difference is what the score reflects.

The four signals ScanZX scores

Liquidity. Pool depth in absolute dollars, the change against the previous scan's snapshot where one exists, the locked share of the pool, and the unlock date. A large fall in pooled liquidity between two scans is a material finding on its own. Where no lock data is available that is recorded as uncertainty, never as a clean result.

Holder concentration. The top holder's share and the top ten's share, with known burn, liquidity-pool and exchange addresses excluded where the data supports identifying them. High concentration is a dump risk regardless of anybody's intentions, because a single decision can move the whole market.

Owner and admin powers. Mint, blacklist, pause, tax modification, ownership regain, hidden owner, and whether the contract is an upgradeable proxy. The owner's type matters as much as the powers: a single externally-owned account, a multisig and a timelock represent three different levels of exposure to one person's decision.

Deployer history. ScanZX counts prior tokens deployed by the same address that this system previously scored at high risk. This is an evidence-grade relationship built from ScanZX's own scan history — not guilt by transaction proximity, and not a third-party reputation label. Three or more prior failures is the threshold that feeds the score, and the count is shown so you can judge it yourself.

What a low score does and does not tell you

A low observed-risk score means the checks that ran did not find the conditions above. Read it next to the confidence score, which reports how much of the intended checking actually completed. A low risk score with low confidence usually means the scan could not see much — an unverified contract, an unreachable provider, a chain without an explorer key — and that combination should be read as 'unknown', not as 'fine'.

There is also a whole category of loss this cannot address. A token can have locked liquidity, renounced ownership, distributed supply and a clean deployer, and still go to zero because nobody wants it. Structural risk checks measure whether you can be trapped or robbed by the contract. They do not measure whether the thing is worth anything.

What a finding proves — and what it does not

Limitations

• Liquidity lock detection depends on the locker contract being recognisable. An unrecognised locker reads as 'no lock data', which lowers confidence rather than raising the risk score.
• Holder data depends on explorer access for the chain. Without a configured explorer key, concentration is reported as unavailable.
• Deployer history is built from ScanZX's own scans, so it is thin for deployers and chains this instance has not seen much of — and the report says when it is thin.
• Snapshot comparisons need a previous scan of the same token. The first scan of a token has nothing to compare against, so liquidity-change findings are unavailable by definition.

Any check that cannot run is listed in the report as unavailable and lowers its confidence score — it never lowers the risk score. The methodology page sets out how the weights and the confidence model work, and the status page shows which providers are configured.

Common questions

Chain coverage

The deep EVM scan runs on five chains. Each chain page lists which checks are configured there and the risk patterns that recur on it.

Related reading and checks

Guides that go deeper on this subject:

• What is a rug pull? — The routes to the same outcome, and which of them are observable in advance.
• How to read a liquidity lock — The three numbers behind the phrase, and why the phrase alone tells you nothing.
• Deployer history and why it matters — What a deployer's past tokens can show, and the reputation shortcuts worth refusing.

Other checks in the same report: