Anatomy of a Rug Pull: Ten Patterns from 14,000 Contracts

The word "rug pull" has become so elastic that it now covers everything from a deliberate multi-million-dollar extraction to a founder who simply lost interest after lunch. That imprecision is itself a risk factor: when every failure is called the same thing, people stop looking at how the extraction actually works. And the how is where the signal lives.

Over twelve months of scanning, our engine processed more than fourteen thousand contracts. Not all were malicious. Most were simply mediocre. But embedded in that corpus were recurring structural patterns, code-level signatures that appear, again and again, in contracts that eventually extracted value from their holders. What follows are the ten most frequent, ordered by how often they appear and how much capital they have historically displaced.

A note on language: we are not calling anyone a criminal. We are describing code patterns. A hidden mint function is not illegal. It is, however, a design choice that concentrates unilateral power in a single address, and the historical record of how that power gets exercised is not encouraging.

The problem is never that the code is complex. The problem is that it is complex in exactly the places you are not looking.

1. Hidden Mint Functions

The most common extraction pattern in the dataset, and arguably the most elegant in its simplicity. A hidden mint function is any mechanism that allows a privileged address to create new tokens after deployment, diluting existing holders without market activity. In the Webacy/Base exploit taxonomy from October 2025, the "Hidden Mint" family accounted for roughly 10.2% of all classified exploits, though its dollar impact is disproportionately larger because it scales linearly with market capitalisation.

The code signature is usually one of three variants: an onlyOwner modifier on a public mint() function that was not disclosed in documentation, an internal _mint() call buried inside an innocuous-looking admin function like setRewardRate(), or a pre-deployed proxy where the implementation contract contains mint logic that the proxy's public interface does not expose.

// Variant A: the obvious one, hidden in plain sight
function adjustSupply(uint256 amount) external onlyOwner {
    _mint(msg.sender, amount);
}

What makes this pattern so effective is not the code itself but the cognitive load required to find it. In a contract with four hundred lines of standard ERC-20 boilerplate, a single function that calls _mint() under a misleading name is easy to overlook. Our scanning corpus found that when hidden_mint was present and the top five wallets controlled 90% or more of supply, the eventual extraction rate exceeded 93%.

The GhostScore pillar this triggers: Security (weight: 0.305). A hidden mint function with concentrated ownership will typically collapse the Security subscore by 30 to 50 points, often enough to push the composite into Evacuate territory on its own.

2. Digital-Signature Tampering

This is the largest single category in the Webacy/Base exploit dataset: 39.1% of all classified exploit families. The label covers a range of techniques, but the common thread is the manipulation of cryptographic validation to authorise transactions that should have been rejected.

In practice, this often manifests as EIP-712 signature replay, where a signed message valid for one context is reused in another, or as malformed ecrecover implementations that accept zero-value signatures. The more sophisticated variants forge permit signatures to drain token approvals without the holder initiating a transaction.

// Dangerous: ecrecover returns address(0) for invalid sigs
// If owner is unset (also address(0)), this passes
address signer = ecrecover(hash, v, r, s);
require(signer == owner, "Invalid signature");

The behavioural economics angle here is worth noting. Signature-based exploits succeed not because the mathematics of ECDSA are weak, but because developers treat signature validation as a checkbox item rather than an adversarial surface. The mental model is "signatures are secure because cryptography," which is true of the primitive and irrelevant to the implementation.

The GhostScore pillar this triggers: Security. Signature validation flaws carry a critical severity flag in our engine and engage the non-linear amplifier at n^1.6 multiplied by 3, meaning a single signature flaw can cascade across the composite score far more than its raw weight would suggest.

3. Liquidity Pool Drain

The classic. A project launches, pools liquidity on a decentralised exchange, waits for retail capital to enter, then withdraws the paired asset (usually ETH or a stablecoin) in a single transaction. The LP drain is so well-understood that many observers assume it has been "solved" by LP locking services. It has not.

The issue is not whether liquidity is locked. The issue is what happens when it unlocks, or whether the locking mechanism itself has an admin override. In our dataset, 34% of contracts that advertised "locked liquidity" had either an emergency withdrawal function accessible to the deployer, or a lock duration shorter than the project's stated roadmap.

// "Locked" LP with a convenient back door
function emergencyWithdrawLP() external onlyOwner {
    IERC20(lpToken).transfer(owner(), IERC20(lpToken).balanceOf(address(this)));
}

The dollar figures here are significant. According to CoinLaw's 2025 aggregation, total losses attributed to LP drain mechanisms exceeded $1.2 billion across all chains, with BSC and Ethereum mainnet accounting for roughly 78% of volume. The average incident displaced approximately $510,000 in 2025, though the distribution is heavily skewed: the top five LP drains that year accounted for over 80% of total losses.

The GhostScore pillars this triggers: Security and Tokenomics (weight: 0.166). The LP drain pattern scores against both because it represents a simultaneous security flaw (the ability to extract) and a tokenomics flaw (the supply/liquidity ratio is structurally unsound).

4. Faulty Calculations

The second most common exploit family in the Webacy classification at 20.3%, faulty calculations cover arithmetic errors that produce exploitable outcomes: integer overflow before Solidity 0.8, rounding errors in fee distributions, unchecked division by zero in price oracles, and the perennial favourite, precision loss in token-to-share conversions.

The subtlety here is that faulty calculations are often not intentional. A developer miscalculates a fee split, and the rounding error is harmless at low volume but becomes a siphon at scale. The line between incompetence and malice is genuinely blurry, which is precisely why automated scanning matters more than intent-based analysis.

// Classic rounding exploit in vault shares
function deposit(uint256 amount) external {
    uint256 shares = amount * totalShares / totalAssets; // rounds to 0 if totalAssets > amount * totalShares
    _mint(msg.sender, shares);
}

The GhostScore pillar this triggers: Security. Faulty calculations are flagged at warning severity unless they interact with privileged functions (in which case they escalate to critical).

5. Reentrancy Exploits

Reentrancy was supposed to be a solved problem after the DAO incident of 2016. It is not. The Webacy/Base dataset shows reentrancy at 11.4% of exploit families, which is a remarkable persistence for a vulnerability class that is covered in the first chapter of every Solidity tutorial.

The reason for its persistence is what behavioural scientists call the "solved problem illusion." Because reentrancy has a well-known fix (the checks-effects-interactions pattern, or OpenZeppelin's ReentrancyGuard), developers assume they are protected without verifying. In our corpus, 8% of contracts that imported ReentrancyGuard had at least one external-facing function that failed to apply the nonReentrant modifier.

// The modifier exists. It just was not applied here.
function claimAndCompound() external {
    uint256 reward = pendingReward[msg.sender];
    (bool ok, ) = msg.sender.call{value: reward}("");
    require(ok);
    pendingReward[msg.sender] = 0; // state update after external call
}

According to Chainalysis reporting on H1 2025, approximately $2.17 billion in crypto assets were lost to exploits in the first half of the year alone, with reentrancy remaining a top-five vector. The persistence of this pattern suggests that the problem is not educational. Developers know about reentrancy. They simply do not audit every function with the same rigour.

The GhostScore pillar this triggers: Security. Reentrancy is always flagged at critical severity and activates the non-linear amplifier.

6. Malicious Boolean Logic

At 10.0% of the Webacy classification, malicious boolean exploits involve functions that return hardcoded or manipulated boolean values to bypass validation checks. The most common variant: a transfer() function that returns true regardless of whether the transfer actually occurred, or a balanceOf() that reports an inflated figure to pass collateral checks.

// Looks like a standard transfer. It is not.
function transfer(address to, uint256 amount) public override returns (bool) {
    if (msg.sender == _owner) {
        _balances[to] += amount; // mints from nothing
        emit Transfer(msg.sender, to, amount);
        return true;
    }
    return super.transfer(to, amount);
}

The danger of malicious booleans is that they exploit the implicit trust developers place in interface conformity. If a contract implements IERC20, most integrations assume its transfer() behaves like a standard transfer. This assumption is load-bearing, and when it fails, it fails silently. There is no revert. There is no error. There is simply a number that does not mean what you think it means.

The GhostScore pillar this triggers: Security. Malicious boolean patterns carry critical severity when detected in core token operations (transfer, approve, transferFrom).

7. Malicious External Calls

At 7.7% of the exploit taxonomy, this pattern involves contracts that delegate logic to external addresses controlled by the deployer. The contract looks self-contained, but critical operations (fee calculation, access control, transfer validation) are routed through an external contract that the deployer can modify post-deployment.

// The fee logic lives somewhere else. Where? Ask the owner.
IFeeCalculator public feeCalc;

function setFeeCalculator(address _new) external onlyOwner {
    feeCalc = IFeeCalculator(_new);
}

function _calculateFee(uint256 amount) internal view returns (uint256) {
    return feeCalc.getFee(amount); // could return 100%
}

This is the architectural equivalent of a restaurant where the menu prices are set by a phone call to someone you cannot identify. Everything appears normal until the bill arrives. In our corpus, contracts with mutable external call targets and an onlyOwner setter showed an extraction correlation of 67% when combined with anonymous deployer addresses.

The GhostScore pillars this triggers: Security and Team (weight: 0.304). The mutable external call is a security concern; the anonymous deployer who controls it is a team concern. Together, they form one of the highest-conviction composite signals in the scoring engine.

8. Upgradeable Proxy Abuse

Roughly 1% of classified exploits in the Webacy dataset, but responsible for some of the largest single-incident losses in the historical record. The proxy pattern allows a contract's logic to be swapped post-deployment while preserving state. This is a legitimate architectural choice for long-lived protocols. It is also, when abused, the most complete form of extraction available: the deployer can replace the entire contract logic with a withdrawal function.

The Coinlaw bug bounty dataset notes that uninitialized proxy bugs led to the highest single bounty payout of $10 million, an indication of how seriously the security community takes this vector. The issue is usually not the proxy pattern itself but the access control around who can trigger an upgrade and whether a timelock exists.

// UUPS proxy with no timelock and a single admin key
function upgradeTo(address newImpl) external onlyOwner {
    _upgradeTo(newImpl);
    // No timelock. No multisig. No governance vote.
    // The entire contract logic changes in one transaction.
}

The GhostScore pillars this triggers: Security, Team, and Health (weight: 0.087). A proxy without a timelock suggests both a security weakness and a governance failure, while the operational risk of single-key upgrades affects the Health pillar's assessment of long-term protocol viability.

9. Honeypot Tax Manipulation

The honeypot is perhaps the most psychologically revealing of all extraction patterns, because it does not prevent you from buying. It prevents you from selling. The mechanism is usually a transfer tax that starts at 0% or a reasonable 2 to 5%, then escalates to 90% or 100% after sufficient buy volume has entered. The buy works. The chart goes up. The sell fails.

In the memecoin era, this pattern has become the dominant retail-facing extraction mechanism. Where earlier cycles saw honeypots concentrated in DeFi protocol tokens, the 2024/2025 data from CoinLaw shows a decisive shift toward memecoins as the primary vehicle, a migration that makes sense when you consider the audience: memecoin buyers are optimising for speed and social signal, not contract review.

// Tax starts reasonable. It does not stay that way.
uint256 public sellTax = 3; // looks normal

function setSellTax(uint256 _tax) external onlyOwner {
    sellTax = _tax; // no upper bound check. Can be set to 99.
}

function _transfer(address from, address to, uint256 amount) internal override {
    uint256 fee = (to == uniswapPair) ? amount * sellTax / 100 : 0;
    super._transfer(from, to, amount - fee);
    if (fee > 0) super._transfer(from, taxWallet, fee);
}

The behavioural insight is that honeypots exploit the same cognitive bias as a lobster trap: the entrance is frictionless precisely because the exit is the product. By the time you discover the exit condition, your capital is already inside the mechanism. In our dataset, contracts with an unbounded onlyOwner tax setter and a sell-side-only fee application had a 91% probability of eventually setting that tax above 50%.

The GhostScore pillars this triggers: Security and Tokenomics. The unbounded tax is a security flaw; the asymmetric buy/sell fee structure is a tokenomics red flag.

10. Malicious Burn Mechanisms

The rarest pattern in the Webacy classification at approximately 0.4%, but worth including because it represents the inversion of the hidden mint: rather than inflating supply, it selectively destroys it. A malicious burn function allows a privileged address to burn tokens from any holder's wallet, effectively confiscating assets without a transfer event that would appear on standard block explorers.

// Burns from ANY address. Not just the caller.
function purge(address target, uint256 amount) external onlyOwner {
    _burn(target, amount);
}

The low frequency of this pattern is itself interesting. Malicious burns are less popular among extractors because they are noisy: the disappearance of tokens from wallets generates holder complaints faster than a slow bleed through tax manipulation. But in contracts where the mechanism exists, it functions as a final extraction tool, deployed after other methods have been exhausted, to consolidate remaining value into the deployer's position.

The GhostScore pillar this triggers: Security. Any function that can burn tokens from an arbitrary address without that address's approval is flagged at critical severity, regardless of context.

The Pattern Behind the Patterns

If you step back from the individual mechanisms, a larger architecture becomes visible. Every pattern in this list shares three structural properties: concentrated privileged access (a single address or small multisig that can trigger the extraction), information asymmetry (the mechanism exists in the code but is not disclosed or is actively obscured), and temporal separation (the extraction occurs after capital has entered, not before).

This is not a technology problem. As CoinDesk reported in their analysis of the Chainalysis H1 2025 data, the thesis is increasingly "people, not code." Access control vulnerabilities alone accounted for $1.83 billion in losses, and those vulnerabilities are not bugs in the traditional sense. They are governance choices: who holds the keys, how many signatures are required, whether a timelock exists.

The code does not steal money. People with privileged access to the code steal money. The distinction matters because it tells you where to look.

The numbers support a counterintuitive trend. According to ainvest.com's aggregation of 2025 data, total rug pull losses reached approximately $6 billion, a 6,499% increase from 2024's roughly $90 million. But the number of incidents dropped 66%, from 21 to 7. The market is producing fewer rugs, but the ones that succeed are catastrophically larger. The Mantra (OM) incident alone accounted for 92% of 2025's total.

This is the pattern of a maturing predatory ecosystem: amateur operators are being priced out by detection tools and educated buyers, while sophisticated operators with institutional-grade execution are capturing more value per incident. The average extraction in 2025 was roughly $510,000, up from under $5,000 in 2023.

What This Means for Scoring

The GhostLabs 100-point scoring framework was built to catch exactly these compound signals. A single hidden mint function is a warning. A hidden mint function combined with concentrated ownership, an anonymous deployer, and no LP lock is a different conversation entirely. The non-linear critical failure amplifier exists because these patterns do not add risk linearly. They multiply it.

When we say a contract scored 14 out of 100 and received an "Exit Liquidity" verdict, we are not making a moral judgment. We are stating that the structural properties of this contract match the historical patterns of contracts that have previously extracted value from their holders. The code has specific, observable features. Those features have a track record. The score reflects that track record, nothing more and nothing less.

The free scan catches all ten of these patterns. The Deep Audit contextualises them against market conditions, deployer history, and comparable contracts. The Sentinel Monitor watches for the moment a dormant pattern goes active. Different tiers, same engine, same scoring model, same willingness to state plainly what the numbers say.

Sources: Webacy/Base Exploit Taxonomy, Oct 2025 · Chainalysis Crypto Crime H1 2025 (via CoinDesk) · CoinLaw Rug Pull Statistics 2025 · ainvest.com DappRadar Annual Report · CRPWarner, arXiv 2024 · CoinBureau Smart Contract Attack Taxonomy · OWASP Smart Contract Top 10, 2025

Anatomy of a rug pull: ten patterns from 14,000 contracts.