A Rug Pull Is Not a Hack — It Is a Permission

Did the Code Break?

Scanning all Ethereum smart contracts with public source code, backdoors turned up in 288,440 of them, including potential ones. The most frequent type, at 211,687 cases, was one that blocks sending assets to other addresses (DOI: 10.1145/3822509).

As defined in "What Is a Smart Contract?", a smart contract is a program that records conditions and the actions to take when those conditions are met on a ledger, and executes them without human judgment whenever someone calls it. A backdoor is a privilege left in that contract by its creator, acting as a mechanism that allows them to handle the assets created by that contract however they please (DOI: 10.1145/3822509).

This number counts the contracts that hold such authority. It does not mean there were 280,000 scams. "What Is a Smart Contract?" noted that there is a distance between something being marked as having a vulnerability and it actually being looted. Authority is the same way, as there is a distance between having the authority and that authority being used as an exit. This article follows that distance.

One of the most frequently repeated losses in cryptoassets looks different from a dramatic break-in. A token is created, people buy it, and one day that token can no longer be sold or the money put into buying it disappears. This kind of accident is called a rug pull. The term comes from the image of yanking a rug out from under someone's feet. A rug pull is when the developer who created a token deliberately abandons the project and walks away with the investors' money (arXiv:2403.01425).

In "Where Are My Coins?", an exchange was a place where coins were swapped for money or other coins, and such exchanges commonly held the customers' keys instead. A decentralized exchange is a place that allows coins to be swapped directly between users without entrusting their assets to an intermediary (arXiv:2109.00229). Another definition of a rug pull is precisely the act of draining the assets from this exchange's token pool—the place where assets are gathered to be used for exchanges—leaving users with worthless tokens (arXiv:2504.07132).

When this happens, has the code broken?

This article does not evaluate any tokens or projects, nor does it provide a checklist saying that doing things this way is safe. Many of the cited papers are preprints released on arXiv and elsewhere before undergoing peer review.

The widespread idea about decentralized exchanges is this: asset custody is not delegated to others, trading rules can be publicly verified by anyone, and transactions are completed without a trusted third party (arXiv:2201.07220). That same nature works in reverse as well. Services built on smart contracts run without a trusted intermediary, but it has been pointed out that the immutability from "What Is a Smart Contract?"—the property that code once uploaded cannot be changed—along with the property that anyone can upload and use it without permission, also makes large-scale scams easy to carry out (arXiv:2603.11324, preprint).

That widespread idea misreads "can be verified" as "has been verified." A paper (SoK) that systematically organizes decentralized finance as a whole divides the security of this ecosystem into technical security and economic security, diagnosing that at the time the paper was written, sufficient research had accumulated for the former, while the latter was largely unexplored (arXiv:2101.08778). The question of whether there is a bug in the code is different from the question of who can take what from whom under these rules. Rug pulls belong to the second question.

An Accident Occurred Without Breaking the Code

When a 2024 preprint manually collected 103 actual rug pull incidents and sorted them by method, two branches emerged (arXiv:2403.01425). Contract-related rug pulls happen through malicious functions inside a smart contract, specifically harmful features among the ones the contract calls. Transaction-related rug pulls happen entirely through cryptoasset transactions without using any malicious functions.

The former is a case where an exit is carved into the code, and the latter is a case where well-behaved code performed an allowed action. Neither side is an intrusion.

Another SoK (a 2024 preprint) that reviewed academic literature and industry data together the same year classified the root causes of rug pulls into 34 types. Among them, six categories newly added based on industry discussions are burning, hidden owners, ownership transfer, unverified contracts, external calls, and fake liquidity locks (arXiv:2403.16082). Their nature is apparent from their names alone.

To read fake liquidity locks, one must know about pools. A liquidity pool is a device followed in "A Smart Contract Cannot See the Outside World", a puddle holding two types of tokens, determining prices by the ratio of the amounts held, and swapping them with each other. Traders exchange against this pool instead of an order book. A person who puts assets into the pool receives a token proving their share, and taking that share back dries up the pool.

Liquidity withdrawal is the act of taking back the share put into the pool and drying up the pool. Liquidity locking is an indication that those shares have been tied up so they cannot be taken back for a certain period. The presence of fake liquidity locks on the list means that the indication of locking itself is also something that must be verified.

In "What Is a Smart Contract?", a vulnerability was a gap where the creator produced unintended results. A significant portion of NFT rug pulls have a hidden backdoor at their core, and this backdoor differs from such unintended bugs. They are deliberately coded and often hidden so as to be hard to recognize, bypassing standard code audits that read code to find gaps before uploading. This is the critical awareness of a 2025 preprint that scanned 49,940 NFT contracts—each being a distinct token—through large-scale static analysis. However, this study reports grades assigned to discovered risk patterns, and the authors state that they did not conduct actual attacks (arXiv:2506.07974).

Static analysis is a method of examining properties by looking only at code structure without running the program. Therefore, it can produce results without an actual attack, and for the same reason, it cannot answer whether that authority will actually be abused.

The same result occurs even if there is no trace in the code. A 2026 preprint that measured rug pulls on Solana, another blockchain, contrasts it this way. While Ethereum's rug pulls often rely on malicious contract logic, on Solana, the execution of fraud shifts toward manipulating actions on the ledger because of a unified standard token program. When 68 community-reported incidents were manually verified and benchmark data was created with 117 verified rug pull tokens, three representative behavioral patterns emerged: abuse of freeze authority that prevents moving tokens in an account, liquidity withdrawal, and pump-and-dump where prices are inflated and then dumped (arXiv:2603.24625).

The same result comes through a different path. When a standard program is used, there is nothing that can be called malicious code, and the authorities that the standard inherently grants—such as the authority to freeze accounts—are used as-is. The method of reading code to distinguish whether it is malicious loses its power here. Being public and being read are different things. Most of the contracts covered by the above studies had their source code public. Even so, large-scale static analysis and manual verification were required to expose the patterns within them, and what was exposed even then went only as far as "such authority exists."

Which Privileges Act as Signals

Privileges remaining in code typically exist as functions that only the contract's owner—specifically, an address designated to invoke special capabilities—can use. Why such privileges act as signals can be broken down into three parts.

The first is the privilege to touch the supply. If the total amount can be increased, the share of people who already bought that token can be diluted at will. In an exhaustive survey of backdoors, the single most common type appearing without mixing with other types was the privilege to mint new cryptoassets (DOI: 10.1145/3822509). Code that touches the supply does not end as just an exit route for the owner alone. A 2026 preprint introduces a tool to find non-standard supply adjustment functions in token contracts, and replays actual transactions to show that such functions become profit opportunities for others as well (arXiv:2603.07996). Non-standard supply adjustment functions can also become a surface that third parties can extract from.

The second is the privilege to block selling. In the exhaustive backdoor survey, the most frequent type was blocking transfers to other addresses. At the end of this lineage lies a trap that keeps the direction of buying and selling open only one way. When 10,000 pools randomly chosen from major decentralized exchanges were examined through past transaction analysis and transaction simulation, 8,443 abnormal pools emerged. The structure is one where a trader can put in valuable assets and receive tokens, but cannot swap them back (arXiv:2309.13501, 2023 preprint). This number must be read with caution. The abnormalities are based on the authors' classification and simulation criteria, come from a random sample, and do not mean that all pools classified as abnormal are scams.

The third is a structure that can reclaim liquidity, representing the most direct exit route. Liquidity withdrawal was one of the three representative behavioral patterns picked out by Solana measurements (arXiv:2603.24625), and fake liquidity locks attach here. Locks are put forward as a basis for reassurance, but in the aforementioned SoK (preprint), fake locks were one of the root causes and one of the nine causes that existing tools fail to handle (arXiv:2403.16082). A mark used as a basis for reassurance sat in a blind spot of verification.

Signals Outside of Permissions, and Repeating Scams

There is also a branch that looks for signals in actions instead of permissions. A representative example is wash trading. Wash trading is the act of inflating trading volume and attention by buying and selling among themselves even though the owner does not actually change.

When an alarm model was built by dividing the wash trading of meme tokens—tokens named after trends or jokes—into three shapes of self-trading, paired trading, and circular trading, alarms sounded an average of 3.81 hours ahead in some samples. This is a value measured across 7 meme tokens and 33,242 records on a chain called BSC (arXiv:2603.13830, 2026 preprint). The more valuable part of this paper is the evaluation the authors made by reporting their own errors. Precision is the proportion of what was called dangerous that was actually dangerous. Recall is the proportion of what was actually dangerous that was caught. The authors note themselves that this system is closer to a high-precision primary screener than a high-recall automated alarm. In this small evaluation of 7 tokens, it means that when an alarm sounded it was usually correct, but many things were missed.

Wash trading is both a detection signal and a variable that distorts measurement. If you follow serial scam organizations that repeat multiple rug pulls, structural patterns such as stars, chains, and fund flows emerge from about 384,000 scam addresses behind simple one-day rug pulls on two exchanges. Scam token contracts within the same cluster resembled each other by an average of over 70%, while different clusters resembled each other by less than 30%. The same 2024 preprint introduces a new profit calculation formula that reflects the share of wash traders, reporting that existing formulas inflate profits by at least 32% and 24% on the two exchanges, respectively (arXiv:2412.10993).

Scams were production lines churning them out on repeat. Across 758 rug pulls on 10 NFT marketplaces, one collection attempted 37 times within three months, and executors of different projects used the same wallet to move money around (arXiv:2304.07598). Applying the aforementioned 2026 preprint's self-measurement pipeline to 100,063 new tokens launched in the first half of 2025 across three Solana decentralized exchanges (Orca, Raydium, and Meteora), 76,469 were identified as rug pull tokens, and a manual audit of 382 random samples estimated the label false positive rate at 0.26% (arXiv:2603.24625). If you view rug pulls only as a matter of individual project morality, this repetition becomes invisible.

From Counting to Screening Out Ahead of Time

The first step in this field was counting. When a 2021 study gathered and analyzed every transaction related to a single decentralized exchange (Uniswap V2), over 10,000 scam tokens emerged, and the authors estimated this to be roughly 50% of the tokens listed on that exchange (arXiv:2109.00229). The original authors wrote that this method could spot scam tokens at an early stage, but subsequent research reported that this method is accurate only after a scam has taken place, prompting a shift toward screening them out before malicious manipulation occurs (arXiv:2201.07220).

Precision and recall, as defined earlier, usually move in opposite directions. If you lower the alarm threshold to catch more, recall goes up and precision drops. Unless you look at the two numbers separately, every detection paper looks wonderful.

While the numbers measuring scale vary by study, the direction is the same. A preprint tracking Ethereum and BSC from their inception through 2022 found that about 60% of tokens stopped activity in less than a day, and the profit made by 1-day rug pulls using disposable tokens was estimated at 240 million dollars (arXiv:2206.08202). A 2023 preprint looking at major decentralized exchanges reports that 44 to 50% of tokens exhibit "scam-like" traits and investor losses reach about 1.7 billion dollars. The authors describe this as a cat-and-mouse game, noting that while scam techniques are becoming subtle, victims are also learning (DOI: 10.2139/ssrn.4490180, preprint).

Placing this entire field on one scale is the aforementioned SoK (2024 preprint). Remeasuring existing datasets and detection tools across a 34-root-cause taxonomy yielded sharp results. Existing public datasets numbering 2,448 covered only 7 out of the 34 causes, covering about 20%. A newly built dataset of 2,360 created by the authors raised this ratio to 54%. The tools fared better, with 14 detection tools able to identify 25 out of the 34 causes (73.5%). However, nine causes were not addressed by any tool, among which were fake liquidity locks, hidden fees, ownership transfer, account freezing, and wash trading (arXiv:2403.16082).

Forms That Evade Detection Rules

Traditional detectors assume simple scenarios. The setup looks like a deployer holding a liquidity share and selling off heavily once or twice within a day to collapse the pool. A 2025 preprint points out that many real-world cases do not fit this assumption. A fragmented rug pull is a tactic that splits the extracted share across both time and actors, drying up the pool without drawing much attention. The authors named and formalized it this way. Out of 303,614 target liquidity pools, 105,434 were classified into this type, and the proportion of cases where the owner's wallet directly participated in sales dropped significantly to 33.1% in this type (arXiv:2511.15463).

How those variations are structured is not covered in this article. What the research reports is that such variations exist and are large in scale, meaning simple rules that watch a single owner wallet work that much less.

There is another similar finding. A preprint analyzing 319,166 liquidity pools across 6 major decentralized exchanges since 2018 separated scams that slowly drain funds over a long period from typical rug pulls, naming them slow liquidity drains. Cumulative losses exceeding $103 million were identified across 3,117 pools (arXiv:2503.04850). Eyes that only look for rapid collapses cannot see these drains. What rules ultimately determine is what counts as an incident.

How to Read Detection Numbers

Let's place two detection performance numbers side by side. A detector that looks at both code and transactions reports a precision of 95.3% and a recall of 93.8% on a dataset of rug pull events manually analyzed by the authors (arXiv:2506.18398, 2025 preprint). A tool that searches for malicious functions reports a precision of 91.8% and a recall of 85.9% across 69 open-source contracts associated with rug pull events (arXiv:2403.01425, 2024 preprint).

These numbers cannot be compared with one another. Each is measured on its own dataset, its own label definition, and its own time window, and almost all of them are the result of the tool's creators evaluating their own tool. The earlier picture of the SoK re-measuring 14 tools under the same standard is much closer to the actual state of this field.

Both tools also produced results when applied broadly to real tokens, and the precisions reported then were 90.7% and 84.9%, respectively. The latter value was measured on real token contracts on Ethereum (arXiv:2506.18398; arXiv:2403.01425). The fact that benchmark performance and real-world performance differ is itself information. This is also why research that reports both numbers together is more reliable than research that does not.

A more fundamental problem is how the evaluation is structured. Temporal leakage is when information that could not have been known at the time of prediction gets mixed into the judgment materials. If you "predict" a collapse using values that only become visible after the collapse, the performance looks wonderful, but it is useless in actual practice. One early-detection preprint points out that existing methods mainly rely on post-incident ledger signals and frequently suffer from temporal leakage. They also state that across 1,000 manually labeled token projects, all judgment materials were extracted solely before the liquidity withdrawal, thereby preserving the order of causality (arXiv:2603.11324). A dataset paper that puts chronological ordering front and center emerged from this same critical awareness (arXiv:2602.21529).

Some research honestly produces results pointing in the opposite direction. This is a 2026 preprint that attempted to transfer a concept drift response technique validated in malware detection—namely, a technique attempting to continuously track how judgment criteria drift over time—to rug pull detection. The authors state that while strictly dividing 633 real token projects on Ethereum chronologically for evaluation, they found and corrected leakage in the stage of choosing the model's configuration settings (hyperparameter tuning). The result was that a simple baseline model that periodically retrained itself performed slightly higher than drift-adapted clustering. The score combining precision and recall (F1) was 0.891 versus 0.873, and the fluctuation in precision over time was also much smaller. The clustering side showed a noticeably lower false positive rate in a few splits, but its recall was low and unstable. The authors present this as a negative result in this feature set (DOI: 10.21203/rs.3.rs-10510157/v1, preprint).

In a body of literature where papers overwhelmingly report that their own tool won, papers that report losing contain more information than average.

The label—that is, the definition of what counts as a rug pull—is determined before performance. When comparing within a single study two criteria for a rug pull on two decentralized exchanges on a blockchain called TON—one defining it as a sharp drop in the total assets entrusted to a pool (total value locked) and the other defining it as transactions suddenly stopping—the two definitions excelled on different metrics (arXiv:2509.01168, 2025 preprint). This is why there is no single answer to "How common are rug pulls?" Estimates such as 44% to 50% of major decentralized exchange tokens (2023 preprint), about 50% of tokens listed on one exchange (2021 study), and 76,000 out of 100,000 new tokens across three Solana exchanges (first half of 2025) measure different definitions, surfaces, and time periods. The moment you copy any one of them over as "the current market fraud rate," it becomes a false sentence.

Ability is in the Code, Intent is Outside the Code

Here is the most unresolved question in this article. Many of the privileges flagged as warning signs are also used for normal operations. There are tokens whose supply adjustment is part of the design, assets whose movement between certain accounts must be blocked due to regulations or contracts, and contracts that must be fixable when flaws are revealed.

The last case is the upgradeable contract from "What Is a Smart Contract?", meaning a contract written so that the code specifying what it does can be swapped out even after it is uploaded. The immutability that once uploaded code cannot be changed has been pointed out as making large-scale scams easy (arXiv:2603.11324), and it also prevents patching flaws found later. That is why they are written to be fixable, but being fixable means someone has the power to fix them. To put it in the words of the primer, the person holding the repair key becomes a new entity that must be trusted. When that very power that allows flaws to be patched is held in hands with a different intent, it does something else. Because this is a property of the design rather than a finding of any single paper, no detector can eliminate this symmetry itself.

A 2026 preprint that looked for privilege control flaws in NFT contracts checked 795 popular collections and identified 241 vulnerabilities, the vast majority of which (214 cases) were flaws where privilege checks were bypassed, while 12 cases involved loosely managed privileges (arXiv:2604.15118). Having privileges in itself is not a flaw, and how broad is too broad cannot be determined by code alone.

That is why there is a branch of thought that has changed the question altogether. It is to read the developer's intent instead of vulnerabilities. A preprint in this branch (2022) introduces a model that automatically distinguishes developer intent, noting that after vulnerability detection achieved early results, intent detection became a more urgent issue as malicious intent caused massive losses (arXiv:2211.10724).

The very existence of such attempts tells us the nature of the problem. What can be read from the code is ability, and what we want to know is intent. And intent is not inside the code. What the intent detection model actually reads is also the traces left in the code, not the human mind.

The most painful evidence actually comes from the code disclosure side. Research dealing with scams in Initial Coin Offerings (ICOs), where coins are first sold to raise funds, concludes that it is extremely difficult to predict scams with information available at the time of issuance. And it adds one unexpected observation. Issuers who uploaded their code to public repositories were actually more likely to become targets of phishing and hacking attempts. The authors therefore suggest that a third party is needed to certify the quality of issuers (DOI: 10.1007/s11187-021-00471-y).

The claim that "privileges are scattered" is also something to check. Governance concentration refers to how heavily those votes are clustered in a few hands in protocols where rules are set by casting votes with tokens. A 2026 study that actually measured the governance concentration of 52 token protocols sums it up like this: "Token allocation is a launch document, and governance concentration is a living institutional state." Token allocation, maturity, and circulation volume at launch did not explain the concentration that settled in afterwards (insider allocation Pearson r = 0.09, p = 0.55, N = 50), and what remained related was how many insider wallets remained among top holders at the time of the survey (Spearman rho = 0.44, p = 0.005, N = 39). The authors state that this is a descriptive association arising from a single cross-section and is not a causal claim (DOI: 10.3389/fbloc.2026.1853465). Buying and selling those votes themselves is looked at separately in "The Power to Change the Rules Is Also for Sale".

This distinction—that we must look at the current state rather than the launch document—shares the same shape as the privilege problem covered in this article. Rather than the promises written in the whitepaper, the problem is what this contract currently allows whom to do.

Another axis of defense is on the human side. In a qualitative study observing an online crypto-asset community, the community armed each other with guidance for newcomers and shared experiences of victimization, while simultaneously creating norms that normalized scams as the "price of decentralization" (DOI: 10.1177/02697580231215840).

What Can and Cannot Be Verified

We can now use the starting sentence—that a rug pull is not a hack, but a privilege—more precisely.

What can be verified in the code is what privileges exist. Can the total supply be increased? Can other people's transfers be blocked? Can deposited liquidity be taken back? What is the lock display actually binding? The first three questions can be checked in principle, and methods to count them at scale exist (DOI: 10.1145/3822509; arXiv:2506.07974; arXiv:2604.15118). However, the lock display was the cause that none of the 14 tools examined by the 2024 SoK covered (arXiv:2403.16082).

However, these four questions are not a checklist. Even if all answers are "no," safety is not proven. There are paths that leave no trace in the code (arXiv:2603.24625), forms that bypass simple rules have been reported (arXiv:2511.15463), and the causes covered by the public dataset as of 2024 were only a fraction of the total (arXiv:2403.16082, preprint). Saying that something can be verified means no more than that.

What cannot be verified in the code is whether the person holding those privileges will use them. This is different from the limits caused by a lack of information. That information is not inside the code. The fact that this field shifted its question from vulnerability detection to intent detection (arXiv:2211.10724), and that studies on initial coin offerings (ICOs) concluded it is extremely difficult to predict scams using information available at the time of issuance (DOI: 10.1007/s11187-021-00471-y), both face the same wall. The high scores produced by detection studies that claim to screen things before manipulation are values measured on their own respective data.

Therefore, audits and public disclosure do not verify intent in their place. An audit tells you what the code can do, and public disclosure keeps that verification from relying on someone else's word. Both are valuable, but they are not statements about intent. Detection studies do not cross this wall either, nor do they try to. The most honest sentences seen in this article were all about their own limits: the evaluation that it is closer to a primary sorter than an automatic alarm (arXiv:2603.13830), the result where a simple baseline model narrowly outperformed in an evaluation designed to prevent leakage (DOI: 10.21203/rs.3.rs-10510157/v1, preprint), and the diagnosis that existing public datasets as of 2024 cover only 20% of the causes (arXiv:2403.16082).

So the question to ask is "What guarantees what?" rather than "Is this token safe?"

Code guarantees rules. It also guarantees whom those rules allow to do what. It guarantees nothing beyond that. In particular, it never guarantees that an allowed action will not be executed. This is why a rug pull does not look like a hack. A rug pull is not the moment the system broke down, but the moment an action that the system has allowed from the beginning finally takes place.

Erasing this distinction leads you astray in two directions. One is the side that believes code is verified because it is public, and the other is the side that writes off the whole thing as a scam for that very reason. What the research actually says lies between the two. The list of verifiable things is short but real, and everything outside that list remains the domain of trust.

Even among the studies cited in this article, new detectors and new variants have alternated. This article does not predict the winner of that race. The rules of the race are clear: the code tells you only who can do what, and what comes after is always up to people. Knowing where the line between what can be verified and what must be trusted is drawn is the most practical gain these studies have provided.

Source Papers

• "The Backdoor Injures Its Cryptocurrency: An Empirical Study of Backdoor Attacks on Ethereum Smart Contracts" (2026) — DOI: 10.1145/3822509 — A comprehensive survey of open-source Ethereum contracts. Out of 288,440 cases including potential ones, 211,687 are backdoored or transfer-blocking, with minting-type contracts holding the highest single proportion.
• "SoK: Comprehensive Analysis of Rug Pull Causes, Datasets, and Detection Tools in DeFi" (2024) — arXiv:2403.16082 (preprint) — Classification of 34 root causes. Public dataset coverage is roughly 20%, 14 tools identify 25, and nine cannot be handled by any tool.
• "CRPWarner: Warning the Risk of Contract-related Rug Pull in DeFi Smart Contracts" (2024) — arXiv:2403.01425 (preprint) — Manual classification of 103 real-world incidents. The origin of the contract-related versus transaction-related dichotomy.
• "From Hype to Collapse: Investigating Rug Pull Scams on Solana" (2026) — arXiv:2603.24625 (preprint) — The pathway of moving into on-chain actions without leaving traces in the code. Freeze authority abuse, liquidity withdrawal, and pump-and-dump.
• "Exposing Hidden Backdoors in NFT Smart Contracts: A Static Security Analysis of Rug Pull Patterns" (2025) — arXiv:2506.07974 (preprint) — Static security analysis of 49,940 NFT contracts. The critical awareness that backdoors are not bugs, but rather designed to bypass audits.
• "SolRPDS: A Dataset for Analyzing Rug Pulls in Solana Decentralized Finance" (2025) — arXiv:2504.07132 (preprint) — Extraction of suspicious liquidity pools from 4 years of Solana DeFi data.
• "Do not rug on me: Zero-dimensional Scam Detection" (2022) — arXiv:2201.07220 (Published in Mathematics 2022) — The stage of moving from post-hoc labeling to prior prediction. The formal description of conventional wisdom also originates here.
• "SoK: Decentralized Finance (DeFi)" (2021) — arXiv:2101.08778 (preprint) — Distinction between technical security and economic security. The premise of this article.
• "LROO Rug Pull Detector: A Leakage-Resistant Framework Based on On-Chain and OSINT Signals" (2026) — arXiv:2603.11324 (preprint) — The statement that immutability and permissionlessness facilitate scams, alongside an evaluation design that utilizes only features preceding liquidity withdrawal.
• "TMRugPull: A Temporally Sound Multimodal Dataset for Early RugPull Detection" (2026) — arXiv:2602.21529 (preprint) — 1,000 cases of temporally leak-free labeling.
• "Drift-Aware Incremental Clustering for Cryptocurrency Rug-Pull Detection: An Empirical Comparison" (2026) — DOI: 10.21203/rs.3.rs-10510157/v1 (preprint) — A negative result where a simple baseline model won after discovering and correcting a tuning-stage leak.
• "RPHunter: Unveiling Rug Pull Schemes in Crypto Token via Code-and-Transaction Fusion Analysis" (2025) — arXiv:2506.18398 (preprint) — A code-and-transaction fusion detector. Reporting benchmarks and real-world application performance together.
• "Trade or Trick? Detecting and Characterizing Scam Tokens on Uniswap Decentralized Exchange" (2021) — arXiv:2109.00229 (Published in ACM POMACS 2021) — Identification of roughly 10,000 scam tokens, estimated at about 50% of listed tokens.
• "Token Spammers, Rug Pulls, and SniperBots: An Analysis of the Ecosystem of Tokens in Ethereum and BSC" (2022) — arXiv:2206.08202 (preprint) — Roughly 60% of tokens cease activity within a day, with 1-day rug pull profits estimated at 240 million dollars.
• "Scam Alert: Can Cryptocurrency Scams Be Detected Early?" (2023) — DOI: 10.2139/ssrn.4490180 (preprint) — 44 to 50% of tokens exhibit scam-like characteristics, with losses of roughly 1.7 billion dollars. A "game of cat and mouse".
• "How To Cook The Fragmented Rug Pull?" (2025) — arXiv:2511.15463 (preprint) — Fragmented rug pulls split across time and actors. Direct participation of the owner wallet at 33.1%.
• "Slow is Fast! Dissecting Ethereum's Slow Liquidity Drain Scams" (2025) — arXiv:2503.04850 (preprint) — 3,117 slow liquidity drains identified across 319,166 liquidity pools, totaling over 103 million dollars.
• "Early Rug Pull Warning for BSC Meme Tokens via Multi-Granularity Wash-Trading Pattern Profiling" (2026) — arXiv:2603.13830 (preprint) — Wash-trading-based alerts. The authors themselves position it as a primary filter rather than an automated alert system.
• "Serial Scammers and Attack of the Clones: How Scammers Coordinate Multiple Rug Pulls on Decentralized Exchanges" (2024) — arXiv:2412.10993 (preprint) — Roughly 384,000 scam addresses, with contract similarity over 70% within clusters and under 30% between clusters.
• "Understanding Rug Pulls: An In-Depth Behavioral Analysis of Fraudulent NFT Creators" (2023) — arXiv:2304.07598 (preprint) — 758 cases across 10 marketplaces. 37 occurrences for a single collection in three months, with identical wallets across executors.
• "Why Trick Me: The Honeypot Traps on Decentralized Exchanges" (2023) — arXiv:2309.13501 (preprint) — 8,443 anomalies found among 10,000 random pools.
• "More to Extract: Discovering MEV by Token Contract Analysis" (2026) — arXiv:2603.07996 (preprint) — The observation that non-standard supply control functions also serve as extraction surfaces for third parties.
• "NFTDELTA: Detecting Permission Control Vulnerabilities in NFT Contracts through Multi-View Learning" (2026) — arXiv:2604.15118 (preprint) — 241 permission control vulnerabilities across 795 collections. The "loose permission management" category.
• "Detecting Rug Pulls in Decentralized Exchanges: Machine Learning Evidence from the TON Blockchain" (2025) — arXiv:2509.01168 (preprint) — Comparison of total value locked collapse criteria and activity cessation criteria within a single study.
• "Deep Smart Contract Intent Detection" (2022) — arXiv:2211.10724 (preprint) — A shift from reading vulnerabilities to reading intent.
• "Initial coin offerings, information disclosure, and fraud" (2021) — DOI: 10.1007/s11187-021-00471-y — The conclusion that predicting fraud via issuance-time information is extremely difficult, and the observation that issuers who made their code public actually became targets.
• "Auditing governance concentration beyond token allocation: a live-governance study of 52 token protocols" (2026) — DOI: 10.3389/fbloc.2026.1853465 — Allocation represents launch documents, whereas concentration represents a living institutional state. The authors explicitly state this is not causal.
• "'I guess that's the price of decentralisation…': Understanding scam victimisation experiences in an online cryptocurrency community" (2024) — DOI: 10.1177/02697580231215840 — Norms where the community arms its members while simultaneously normalizing scams as "the price of decentralization".