AI-Assisted Rug-Pull Checks: An Evidence-First Workflow

1. Build an evidence snapshot #

Start with the chain, exact contract address, and an observation time or block number. Save direct explorer links and raw exports where possible. A report without a contract address and timestamp cannot be reproduced, and a later check may see different ownership, balances, or proxy settings.

Binance Academy’s rug-pull guide, checked in September 2026 and updated May 19, 2026, recommends reviewing token distribution and transaction history with a block explorer, checking liquidity locks, and reading current audit reports. It also says these checks reduce risk rather than guarantee safety. Read the official guide.

2. Read contract powers #

Search the verified source and deployed configuration for powers that can change what holders experience: minting, pausing, blacklisting, transfer limits, fee or tax changes, exemptions, upgrade authority, and ownership or role transfers. For proxies, inspect the current implementation and proxy admin; reading only the proxy shell is incomplete.

Do not translate “owner renounced” into “no privileged control.” Check every role and connected contract. OpenZeppelin’s current access-control documentation explains that ownership and roles can govern minting, freezing transfers, upgrades, and role assignment. The actual functions and current role holders in the target deployment are what matter.

Keep evidence at function level: function name or selector, required role, current role holder, transaction that set it, and whether a delay or multisig constrains execution. AI may extract candidates from source, but a person should confirm each item in the explorer and contract calls.

3. Verify liquidity and holders #

Identify the actual pool, protocol, and version rather than trusting a project badge. For a fungible LP-token position, record supply, holders, locker beneficiary, amount, unlock time, and any early-withdrawal path. For a concentrated-liquidity NFT position, inspect the position manager, tokenId, owner, approved operator, liquidity in that position, and who can decrease liquidity, collect assets, or transfer the position. Uniswap v3’s official position-minting guide is one example of an NFT position. Any “locked liquidity” conclusion must be tied to the specific protocol, version, manager, and withdrawal powers.

Review holder concentration with labels. Pool, burn, bridge, treasury, vesting, and exchange addresses have different meanings; a raw “top 10 percentage” can mislead. Follow transfers between deployer, treasury, team, and newly funded wallets, and state the block range checked. Concentration or a new wallet is a lead for investigation, not by itself proof of fraud.

Test transfer behavior only in a safe simulation or with specialist tooling you understand. A successful historical sale does not prove every wallet can sell now, and a failed simulation may reflect configuration or tooling errors. Preserve the call data, block, revert reason, and tool version instead of reducing the result to “honeypot: yes/no.”

4. Check audits and public claims #

An audit claim needs the auditor’s original report, publication date, exact contract address or code commit, scope, findings, and remediation evidence. An old report may not cover an upgraded implementation. An audit is useful evidence about a defined scope; it is not a guarantee about treasury decisions, team conduct, or later code.

Verify partner, investor, and team claims from the named party’s own site or announcement, not only the token’s website. Save the URL and access date. Profile age, follower counts, polished biographies, or anonymity can guide follow-up questions, but they do not establish identity or intent.

For a gradual treasury drain, compare wallet flows and governance announcements over the same period. Give the model the original posts and transactions, not a sentiment summary. If the relevant Discord, forum, or multisig history is unavailable, say so; no model can inspect evidence it was not given.

5. Use AI without outsourcing judgment #

Ask AI to produce a claim-to-evidence table. Each row should contain the observed fact, primary URL, chain and block or access time, quoted field or transaction hash, why it matters, uncertainty, and the next manual check. Reject rows with no source, and reopen every cited page yourself.

Different models may summarize the same bundle differently. Without frozen inputs, transcripts, scoring rules, and labeled outcomes, those differences do not support a product ranking or detection-rate claim.

6. A traceable prompt template #

You are organizing token due-diligence evidence, not deciding whether a project is a scam.

Snapshot:
- Chain, contract, observation block/time: {VALUES}
- Verified source, ABI, bytecode, proxy implementation/admin: {LINKS_OR_MISSING}
- Owner and role reads with transaction links: {EVIDENCE}
- Pool protocol/version and position type; fungible LP-token supply/holders/locker, or NFT manager, tokenId, owner/operator, position liquidity, and withdrawal powers: {EVIDENCE}
- Supply and labeled holder table: {EVIDENCE}
- Audit and public project claims: {PRIMARY_SOURCES}
- Transactions and governance posts in scope: {RANGE_AND_LINKS}

Return a table with:
1. observed fact;
2. primary source URL and block/time;
3. exact value, function, role, or transaction;
4. why it needs review;
5. uncertainty or missing input;
6. next manual verification.

Do not assign a scam probability or invent missing facts.
Separate contract powers, current configuration, liquidity, distribution, and off-chain claims.

Before acting, rerun the important reads at a new block and compare the change. A result is stale when ownership, implementation, roles, liquidity, or supply has changed. Unresolved privileged controls or missing evidence may be enough reason not to interact, but absence of a flagged item is never a safety certificate.

See the full Prompt Library →

— AI Trade Lab, revised Sep 24, 2026