Rug Pull Forensics: Post-Mortem Analysis Tools, Workflows, and Evidence Maps

1) What counts as a rug pull (and why post-mortems matter)

“Rug pull” is often used as a generic insult. For forensics, you need a tighter definition. A rug pull is a coordinated extraction of value where insiders use privileged control or structural deception to trap buyers, drain liquidity, or dump supply in a way the market could not reasonably price. Not every price collapse is a rug. Some projects fail honestly. Your job in a post-mortem is to separate: market risk, operational mistakes, and deliberate extraction.

1.1 The main rug pull categories

• Liquidity rug: removing LP or draining a pool so sells cannot execute at fair prices.
• Supply rug: insiders dump large holdings (often pre-distributed through stealth wallets).
• Honeypot / sell trap: buys work, sells revert or are taxed to near-zero.
• Tax toggle rug: taxes are turned up suddenly to confiscate value during sells.
• Proxy or upgrade rug: contract logic changes after hype to introduce extraction code.
• Oracle or pricing rug: manipulation of price feeds, reflective mechanics, or custom AMM logic.
• Cross-chain bridge or wrapper rug: minting or backing assumptions break, leaving holders with unbacked assets.

1.2 Why forensics is useful even after the damage

Post-mortems reduce repeat scams by teaching patterns. They also support: community warnings, blacklists, insurance claims, exchange reporting, and legal investigations. Most importantly, a structured post-mortem improves your ability to detect risk earlier next time.

2) Evidence preservation: build a case folder before you chase wallets

Scams evolve fast: websites go offline, social posts are deleted, and liquidity is routed through multiple hops. The first step is not “open ten tabs.” The first step is creating a case folder with consistent naming and a timeline log. This reduces mistakes and makes your results repeatable.

2.1 Minimum case folder structure

2.2 What to capture immediately

• Token contract address and verified source link (or bytecode if unverified).
• Pool address (pair), router, factory, and the chain explorer links.
• Top holders snapshot and LP token holders snapshot.
• Initial liquidity add tx, first swaps, and the first major dump.
• Admin functions called near the collapse: blacklist, trading open, tax changes, whitelist updates.
• Social artifacts: website domain, docs, whitepaper, and key announcements.

2.3 A simple rule for defensible evidence

Every claim you make in your report should be backed by a linkable artifact: a transaction hash, a decoded log, a contract function signature, a snapshot, or a reproducible query. If it cannot be verified, label it as speculation and keep it separate from conclusions.

3) Diagrams: timeline reconstruction and value extraction routes

A rug pull looks like chaos on a chart, but on-chain it is usually a small set of actions: deploy, seed liquidity, open trading, funnel buys, then drain liquidity or dump supply. These diagrams give you a structured way to map events and isolate the extraction path.

4) Contract forensics: control surfaces that enable rugs

Contract forensics is about identifying what insiders could do that regular traders could not. The goal is to map the control surfaces: ownership, privileged roles, upgrade hooks, tax and limits, and any function that can block sells, redirect value, or mint supply. When you do it right, you can explain the collapse in terms of specific mechanisms.

4.1 Start with the basics: ownership and roles

Most rugs require a privileged key. Your first checks are: who is owner, is ownership renounced, and are there secondary roles (operator, fee setter, guardian). If the contract uses AccessControl, list all role admins and role members at the time of the incident.

• Ownership events: transferOwnership, renounceOwnership, or custom owner setters.
• Role events: RoleGranted, RoleRevoked, role admin changes.
• Hidden owners: a second privileged address in storage, or a privileged router hook.

4.2 Proxy and upgrade detection

Proxy rugs happen when a token is deployed with harmless logic, then upgraded after hype. Even if you are not a solidity auditor, you can still detect proxies and upgrade patterns. Look for: EIP-1967 slots, TransparentUpgradeableProxy patterns, UUPS upgrade functions, and admin addresses controlling upgrades.

If it is upgradeable, your post-mortem must include: the implementation address before and after the rug window, and the exact upgrade tx hash. That single event can be the most important artifact in your whole report.

4.3 Transfer restrictions and sell traps

The most common “I cannot sell” outcomes come from: blacklist logic, trading flags, maxTx limits, maxWallet limits, cooldowns, and anti-bot traps. These can be legitimate at launch, but become abusive when toggled during exits.

Signs of an engineered sell trap: the contract has functions like setBlacklist, setIsBot, excludeFromFees, setTradingEnabled, setSwapEnabled, setMaxTx, setCooldown, or a custom internal gate on transfer. You want to answer: Did the admin change any of these settings shortly before the collapse?

4.4 Tax mechanics and confiscation routes

Taxes are not inherently malicious. Many tokens have buy and sell taxes. The malicious variant is when taxes can be changed rapidly and routed to an insider wallet, or when taxes spike during the collapse. Forensics tasks:

• Identify current buy tax, sell tax, and transfer tax. Identify max possible values.
• Find the tax receiver wallet and the function that updates it.
• Check whether tax wallets are excluded from limits and fees.
• Track tax wallet swaps into the base asset and routing to other wallets.

If the tax wallet repeatedly receives value during the dump window, you have a clean extraction narrative: buyers pay tax, sellers pay higher tax, and proceeds are moved out via swaps and transfers.

4.5 Minting, rebasing, and supply control

Supply rugs can be obvious or subtle. Obvious means: there is a mint function accessible by the owner. Subtle means: a reflection mechanism that can be manipulated, a rebasing mechanism that shifts balances, or a “swap and liquify” mechanic that mints LP tokens under insider control. Your checklist:

• Is there a mint, burnFrom, or setTotalSupply function?
• Are balances “scaled” via a rebase index?
• Is there a fee-on-transfer that can mint or redirect balances?
• Is there a hidden “airdrop” or batchTransfer that can distribute supply to insider wallets?

5) Liquidity and pool forensics: prove the extraction path

Many rug pulls end the same way: liquidity disappears, the price gaps down, and normal users cannot exit. The pool is where the “physics” of value extraction happens, so you must treat pool analysis as first-class evidence. Your goal is to answer: Where did the base asset go? If you can identify the drain transaction and the receiving wallet, you have the core of the case.

5.1 Identify the pool and all liquidity events

Start by finding the main trading pair address. Then capture: the initial AddLiquidity event, all subsequent adds, and all liquidity removals. If there are multiple pools, identify which one carried most volume at the time of the rug.

Key evidence: LP tokens minted to who, LP tokens later transferred to where, and LP tokens burned or redeemed by who. LP tokens are the receipt that proves who owned liquidity at each stage.

5.2 Liquidity lock misconceptions

Projects often claim “LP locked,” but the details matter: locked where, for how long, and how much. A partial lock can be used as marketing while insiders keep a large unlocked portion. Also, even if LP is locked, other rugs can happen: tax toggles, sell traps, or supply dumps.

5.3 Swaps analysis: separate organic sells from engineered dumps

A dump looks like a wall of sells, but in forensics you want to label those sells: which wallets sold, how they were funded, and whether those wallets had pre-launch allocations. A common pattern is “insider ladder dumping”: several wallets sell in sequence to maintain price while draining the base asset.

The strongest evidence is when the selling wallets connect to: the deployer wallet, the funding wallet, the tax wallet, or known cluster addresses. If you can show funding from a single origin, you can argue coordination.

5.4 A simple pool snapshot method

Even without advanced tools, you can take pool snapshots at key blocks: before trading opens, before the dump, and after the rug. Track the reserves of token and base asset. A liquidity pull will show reserves dropping sharply. A supply dump will show base asset leaving the pool while token reserve increases.

6) Wallet clustering and funding paths: connecting the insiders

Wallet clustering is where your report becomes more than “chart went down.” It is also where investigators make the most mistakes. The goal is not to guess identities. The goal is to show coordination and control. Strong clusters are based on concrete behaviors: shared funding, shared deployment tools, repeated interaction patterns, and synchronized action windows.

6.1 Build your suspect wallet list

Start with these sources: deployer wallet, owner wallet, tax wallet, marketing wallet, LP recipient wallet, and the top sellers during the dump window. Add any wallet that: received large transfers before trading opened, or sold in early blocks with unusually high profit.

6.2 Funding sources: the cleanest cluster signal

If five “independent” wallets are all funded by the same origin wallet, you have a strong coordination signal. Funding patterns to look for: one origin sending the same amount repeatedly, funding right before launch, and funding that uses the same gas price strategy or the same block timing.

6.3 Peel chains and split patterns

After the rug, insiders often route funds through a peel chain: a wallet receives funds, sends a portion onward, keeps a portion, then repeats. This can be for operational reasons or obfuscation. Record the hops and label each hop with: tx hash, amount, asset, and destination type (wallet, CEX, bridge, mixer).

6.4 Behavior clustering: synchronized actions

Some clusters are not funded by a single origin, but still coordinate: they buy in the same minute, sell in the same minute, use the same router path, and interact with the same set of contracts. You can show this by building a simple timeline: wallet A sells at T1, wallet B sells at T1+20s, wallet C sells at T1+60s, then liquidity is pulled.

7) Exchange touchpoints: off-ramp clues and what they do (and do not) prove

Many rug pull proceeds end up at centralized exchanges (CEX) because scammers want liquidity and fiat exits. The presence of a transfer to a CEX deposit address does not prove identity, but it can prove that the proceeds were consolidated and prepared for off-ramp. It also helps victims submit reports with concrete destinations.

7.1 What counts as a likely CEX touchpoint

• Transfers to addresses labeled by on-chain intelligence providers as exchange deposit wallets.
• Large, round-number transfers that match typical deposit patterns.
• Consolidation into a single wallet, then a transfer to a known deposit address.
• Stablecoin conversions before transfer (USDT/USDC patterns).

7.2 Bridges, mixers, and the “detection wall”

Bridges and mixers create a detection wall: you can often see funds enter, but attribution becomes harder after. Still, entry transactions are valuable evidence. If funds are bridged, capture the bridge contract, chain destination, and the resulting minted assets. If funds enter a mixer or privacy mechanism, record the deposit tx and time window.

7.3 Reporting: what to include

If you are compiling information for victims or authorities, include: rug tx hash, extraction wallet address, routing path, and likely CEX destination addresses. Avoid accusations about real-world identities unless verified by proper legal processes.

8) AI-assisted rug pull forensics: what to automate and what to keep manual

AI is useful in forensics when it reduces repetitive work: decoding events, labeling transactions, clustering wallets by features, and drafting structured summaries. AI is not useful when it is asked to “guess” intent or identity. The best workflow is hybrid: automation for extraction, manual reasoning for conclusions.

8.1 High-value automation targets

• Event decoding: map admin calls, tax changes, and blacklist updates into a timeline table.
• Swap labeling: classify swaps as buys, sells, liquidity events, and tax wallet swaps.
• Wallet features: funding source, first seen time, number of swaps, profit estimate, routing pattern.
• Cluster hints: identify wallets with shared funding, shared router paths, or synchronized actions.
• Report drafting: convert timeline and evidence into a readable narrative with links.

8.2 Guardrails: prevent hallucination in your output

If you use AI to draft a report, use strict rules: every claim must reference a tx hash, a contract call, or a captured artifact. Anything else is “hypothesis” and must be labeled as such.

9) How to write a credible rug pull post-mortem report

A good post-mortem reads like a security incident report: what happened, what evidence supports the conclusion, what alternative explanations were considered, and what preventive lessons can be generalized. Your report should be readable by: regular users, builders, and analysts. That means short sentences, concrete links, and clear structure.

9.1 Suggested report structure

1. Executive summary: one paragraph with the core mechanism (LP pull, sell trap, tax toggle, dump).
2. Identifiers: chain, token address, pair address, deployer, owner, key wallets.
3. Timeline: timestamped events with tx hashes and short notes.
4. Mechanism analysis: contract control surfaces, admin calls, liquidity changes, swap series.
5. Money flow: extraction wallet, routing path, likely CEX touchpoints (if present).
6. Impact: approximate liquidity drained, peak and trough liquidity, user harm indicators.
7. Confidence level: high, medium, low with what evidence would increase confidence.
8. Lessons and prevention: what users should check next time.
9. Appendix: raw tx list, decoded function calls, wallet list, screenshots.

9.2 How to quantify impact without overclaiming

It is tempting to claim “millions stolen.” Be careful. The cleanest metric is pool base asset change around the extraction tx, plus routed amounts observed on-chain. If you cannot measure a number precisely, use ranges and explain methodology. For example: “Base asset reserve fell from X to Y at block B, consistent with a liquidity removal event.”

9.3 Presenting uncertainty

Not every case is clean. Sometimes multiple mechanisms occur together: a dump plus a tax spike, or a blacklist plus a liquidity pull. Your report is stronger when you explicitly separate: known events, likely interpretation, and unknowns.

10) Tool stack for rug pull post-mortems (beginner to advanced)

You do not need every tool. You need a minimum stack that lets you: read contracts, decode transactions, inspect pools, cluster wallets, and track funds. Below is a practical set of tools that aligns with common investigator needs.

10.1 Core tools (must have)

• Block explorer: read transactions, verify source, decode inputs and logs.
• DEX analytics: pool address, LP events, price and liquidity snapshots.
• Token permission scans: owner privileges, tax toggles, limits, proxy hints.
• Spreadsheet: timeline CSV and wallet list tracking.

10.2 Investigative add-ons (high leverage)

• On-chain intelligence: wallet labels, clusters, exchange tags, smart money patterns.
• RPC + scripting: pull logs and balances at blocks for reproducible evidence.
• Compute for parsing: run scripts on large tx sets and build feature tables.

10.3 Personal security stack (do not skip)

Investigators get targeted. Use a hardware wallet, keep a separate browser profile for research, and do not connect your main wallet to random sites. A secure setup is part of doing credible work.

10.4 Tax and accounting tools (for treasuries and recovered funds)

If your work includes treasury tracking, reimbursements, or recovered assets, keep clean accounting records from day one.

11) Reusable templates: checklists, tables, and a post-mortem skeleton

Consistency makes your output valuable. Use the templates below as a standard operating procedure. They are designed for copy-paste into your report draft or case folder. Adapt them to the chain you are investigating.

11.1 Control Surface Table (copy-paste)

11.2 Pool Evidence Checklist

• Pair address, router, factory and chain.
• Initial liquidity add tx and amount of base asset added.
• LP token recipient address and LP token transfers.
• Any liquidity lock proof (lock contract, lock duration, amount locked).
• Liquidity removal tx(s) and before/after reserves.
• Top sellers list during dump window and their profits estimate.
• Tax wallet swap events and routing of proceeds.

11.3 Wallet Cluster Notes Template

Case: [Token name / symbol]
Chain: [EVM chain]
Primary pool: [pair address]
Rug window: [start time] to [end time]

Cluster A (High confidence)
- Wallets: [addr1], [addr2], [addr3]
- Shared funding: [origin wallet] -> [tx hashes]
- Synchronized actions: [buy window], [sell window]
- Shared interactions: [router], [same contracts]
- Notes: [why this is a cluster]

Cluster B (Medium confidence)
- Wallets: [...]
- Signals: [partial funding], [timing], [swap route similarity]
- Notes: [what evidence would upgrade confidence]
      

11.4 Post-mortem skeleton (drop into your report)

1) Executive summary
- What happened:
- Primary mechanism:
- Key evidence (top 3 tx hashes):
- Confidence level:

2) Identifiers
- Token contract:
- Pair contract:
- Deployer:
- Owner / roles:
- Tax wallet:
- LP holder:

3) Timeline (key events)
- T0: deploy (tx)
- T1: add liquidity (tx)
- T2: open trading (tx)
- T3: peak / major buy wave (tx range)
- T4: extraction event (tx)
- T5: routing (txs)
- T6: off-ramp touchpoint (tx)

4) Mechanism analysis
- Contract controls used:
- Liquidity evidence:
- Swap evidence:
- Sell failures evidence (if any):

5) Money flow
- Extraction wallet:
- Routing path:
- Destinations:
- Notes and limitations:

6) Lessons and prevention
- What users should check:
- What builders should avoid:

Appendix
- Full tx list
- Decoded inputs
- Screenshots
- Wallet list
      

Connect this to TokenToolHub

If you want to reduce rugs before they happen, combine post-mortem learning with pre-trade checks: contract permissions, ownership controls, and suspicious token mechanics. Route readers to your hubs and tools so they can build intuition.

References and further learning

Use primary sources where possible, especially for token standards and smart contract security patterns. The following are reliable starting points: