What distinguishes a rug pull from a project that simply failed

banner-image

A rug pull is defined by what the people controlling a token deliberately did, not by the fact that the token’s price fell to zero. A project that fails honestly — through bad decisions, a design flaw, or a market downturn nobody engineered — is not the same event, even though a chart of the two can look identical. That distinction, between deliberate extraction and honest failure, is the one the taxonomy in Rugsafe’s technical paper is built around; the paper was posted to arXiv on 8 July 2025, with an earlier working version dated 1 September 2024.

Three price patterns, three different causes

Rugsafe’s paper, written by Jovonni L. Pharr and Jahanzeb M. Hussain, sets out three distinct patterns that a collapsing token price can follow. In what the paper calls a scam rug pull, the token’s creators deliberately drain liquidity after building trust with holders, and the price collapses almost instantly once that liquidity is pulled. In a catastrophic event rug pull, a legitimate project suffers an unexpected failure — the paper cites a major design flaw or a market crash — and the price declines exponentially, but gradually, as a result of that failure rather than fraud. In the third pattern, which the paper labels a legitimate project resembling a rug pull, the project keeps operating but the price fades toward zero as community confidence erodes; the paper says this is especially visible in NFT floor prices, where a collection can remain live while its trading value evaporates. All three end in a worthless token. Only the first, in this taxonomy, is a rug pull in the strict sense.

How the liquidity-drain mechanism actually works

On an automated market maker such as Uniswap V2, liquidity providers deposit two assets — say a new token and ETH — into a pool and receive an ERC20 pool-share token, commonly called an LP token, representing their claim on that pool. Per a Uniswap V2 developer course published by Cyfrin Updraft, withdrawing that liquidity means calling the router’s removeLiquidity function, which first moves the LP tokens from the holder’s wallet to the pair contract and then calls the pair contract’s burn function; burning the LP tokens is what triggers the underlying paired assets to be sent back to whoever held them. Kaspersky and Crypto.com, reporting independently, describe the same underlying mechanic in plain terms: liquidity theft happens when a token’s creators withdraw the paired assets backing the pool, leaving the token with no liquid counterpart to trade against. If a project’s team holds most or all of the LP tokens for its own pool, that suggests they control when the removeLiquidity call gets made — an inference from how the contract mechanics work, not a statement made in that course material.

What a liquidity lock does, and does not, cover

To reassure buyers that a team will not make that call, a project can send its LP tokens into a separate lock contract that will not release them before a set date. Streamflow’s documentation, last updated 22 June 2026, describes exactly this: tokens sent into a lock become inaccessible for trading or withdrawal until the unlock time passes, and the documentation warns that tokens sent to a lock address outside the official creation flow are not considered part of the lock at all — they are redirected, irreversibly, to the protocol’s own treasury. A separate, open-source example on GitHub, a token-locker contract built by a developer identified as Dragon Bot Z, describes similar functionality: a lock can be created, extended (never shortened), increased or split, and the project’s own documentation describes the contract as having no admin keys and no upgrade mechanism. That description is self-reported by the contract’s author; the repository does not reference an independent audit or any project that has actually deployed it.

What none of this documentation covers is the token being traded against that locked liquidity. A lock contract holds LP tokens; it has no visibility into, and no control over, whatever functions exist inside the separate ERC20 contract for the token itself. Reading the lock documentation against Kaspersky’s account of how other rug-pull mechanisms work makes the gap explicit: Kaspersky describes rug pulls executed through code that blocks sell orders, restricts transfers between wallets, or contains a backdoor letting developers mint or drain tokens directly — none of which a liquidity lock touches. A locked-liquidity badge, in other words, rules out one exit route. It says nothing about the others.

Named cases, and what actually happened in each

Frosties, an 8,888-piece NFT collection, priced its mints at 0.04 ETH each; once the collection sold out within a few hours, the project’s team had accumulated 335 ETH, according to Kaspersky’s account of the 2022 case. Squid Game Token (SQUID) rode the hype of the Netflix series to a sharp price rise in November 2021, per Crypto.com, before its contract blocked sell orders and its developers drained the liquidity pool. AnubisDAO, in October 2021, raised a large sum in Ether in roughly 20 hours before its developers emptied the pools, which Crypto.com describes as one of the fastest such episodes recorded. Luna Yield, a purported yield-farming protocol on Binance Smart Chain, drained investor deposits in April 2021 by using a backdoor built into its smart contract, per Crypto.com. Meerkat Finance emptied its pool within 24 hours of its March 2021 launch by copying a reputable protocol’s code while building in an exploitable flaw; Crypto.com reports that its developers later claimed, under legal pressure, that the episode had only been a security test. Thodex is a different category: in April 2021 the founder of this Turkish exchange fled with user funds, per Crypto.com — a centralized-platform exit scam with no liquidity pool involved at all, unlike the DeFi cases above, even though the harm to users looks the same.

Hard pulls, soft pulls, and a legal line that isn’t drawn the same way twice

Kaspersky draws its own line inside the category of deliberate scams: a hard pull is one where developers write a malicious backdoor into the contract itself, which Kaspersky describes as illegal; a soft pull is simply developers dumping their own holdings to crash the price, which Kaspersky calls unethical but not always illegal. Crypto.com frames the legal position differently, stating that intentionally deceiving investors for personal enrichment falls under fraud statutes in most jurisdictions, including Germany and the EU. The two sources do not reconcile — Kaspersky’s soft-pull framing leaves more room for a token dump to sit outside the law than Crypto.com’s fraud framing does — and neither resolves the question for a specific reader’s jurisdiction.

What a reader can check before the fact

Crypto.com’s own checklist for spotting a likely rug pull before it happens includes: anonymous developers who don’t disclose their identity, a liquidity pool that isn’t locked in a smart contract, ownership concentrated in a small number of wallets, and the absence of any third-party security audit. These are diligence signals, not proof of anything — a project can pass every one of them and still fail honestly, and a project can fail one and still be legitimate.

What this page does not tell you

None of the sources reviewed for this page document a verified real-world case of a purely honest catastrophic-failure collapse — every named example above is a deliberate liquidity drain, sell restriction, or exit scam. The three-type taxonomy used to structure this page comes from a single, non-peer-reviewed preprint written by the founders of Rugsafe. That paper describes a protocol built around vaults that accept rugged tokens, an inversely-pegged “anticoin” issued as a receipt, and a decentralized insurance mechanism for claims tied to rug pulls. Taken together, this suggests — though the paper does not state it outright — a commercial interest in rug pulls being defined and recognized in a particular way; that is a potential conflict of interest, not neutral academic consensus, and no independent taxonomy in the evidence reviewed corroborates or disputes the paper’s framework. The lock documentation from Streamflow and the GitHub token-locker describes only what those lock contracts themselves do; it says nothing about whether a given token’s underlying contract carries a mint function, a transfer blacklist, or any other privileged control. The GitHub token-locker’s own security claims — no admin keys, no upgrade mechanism, reentrancy protection — are self-reported by its developer, with no audit cited and no evidence in the repository that any live project has ever used it. Finally, none of the sources here confirm a court finding of fraud for any of the named cases; they describe the mechanics of what happened, not a legal adjudication.

Sources

Every fact above is attributed to one of these reports. Where they disagree, the article says so.