Catching the Rug: Spotting Solana Memecoin Fraud in the First Five Minutes

Paper: 2608.20271 Authors: Jianghai Li, Pavel Kuznetsov, Yury Yanovich, Konstantin Nott-Whaley, Igor Vodolazov Categories: cs.AI, cs.DC

The Gap

Almost everything published on rug pulls studies Ethereum. That is a problem, because the mechanics do not transfer. On Ethereum, a rug pull typically hides in the smart contract: a mint function, a transfer hook, an owner-only withdrawal that the buyer never read. Detection research accordingly grew up around code-level analysis — audit the bytecode, flag the dangerous opcodes.

Solana’s memecoin market works differently. It is the leading chain for memecoins by both trading volume and token count, and its rug pulls are predominantly driven by liquidity manipulation and social dynamics rather than contract backdoors. That removes the feature that Ethereum-focused methods depend on: there is often nothing incriminating in the code at all. A detector built on code-level signals has nothing to read.

The urgency comes from the timescale. Assembling 6.4 million tokens over seven months, the authors find that the vast majority exhibit rug-pull characteristics within one hour of launch. A detector that needs a day of history is not protecting anybody. The useful prediction horizon is minutes, and the honest question is whether anything learnable happens inside that window.

   [ETHEREUM RUG PULL]                    [SOLANA RUG PULL]
   hidden in smart contract               liquidity manipulation
   mint / transfer hook /                 + social dynamics
   owner-only withdrawal                  (no code-level backdoor)
        |                                       |
        v                                       v
   code-level analysis works              code analysis has NOTHING to read
        |                                       |
        +-------------------+-------------------+
                            v
                [GAP] no detection method for the
                      dominant memecoin chain
                            |
                            v
                [TIMESCALE] vast majority rug within
                            1 HOUR of launch
                            |
                            v
                useful horizon = MINUTES, not days

The Increment

One sentence: Before this paper, rug-pull detection was a code-auditing problem with nothing to audit on Solana; after it, classic machine learning on the first five minutes of trading data detects fraudulent memecoins at a horizon short enough to matter.

Core Mechanism

The pipeline is deliberately unglamorous, and the authors make that a finding rather than an apology. The dataset is 6.4 million Solana tokens over seven months — large-scale, and the first of its kind for this chain. From that, the only inputs used are the first five minutes of trading data. No code-level features, because as established, there are usually none to use. On those features, classic models do the work, with gradient boosting (XGBoost) the strongest performer.

That result deserves emphasis precisely because it is unexciting. This is not a case where a deep architecture was needed. The signal in five minutes of early trading is strong enough that a well-tuned tree ensemble reads it, which means the barrier to protecting investors was never modelling sophistication — it was that nobody had assembled the data at the right timescale and looked.

The second contribution is about generalization, and it is where the paper earns its keep. Detection models are trained on one venue and deployed on another, and different Solana launchpads have different populations. The authors evaluate cross-platform transfer between PumpFun and Raydium and find the expected domain shift — then show that multi-source data fusion substantially mitigates it, improving detection reliability. That is a practical finding: a single-venue model degrades when it meets the other venue, and mixing sources is the fix.

   CATCHING THE RUG: PIPELINE

   [6.4M Solana tokens over 7 months]
                 |
                 v
   +--------------------------------------------+
   | FEATURE WINDOW: first 5 minutes of trading |
   |   no code-level features                   |
   |   (Solana rugs are liquidity + social,     |
   |    so there is usually nothing in the code)|
   +---------------------+----------------------+
                         v
   +--------------------------------------------+
   | MODEL: classic ML, XGBoost strongest       |
   |   -> robust detection at a 5-minute horizon|
   +---------------------+----------------------+
                         v
   +--------------------------------------------+
   | GENERALIZATION: PumpFun <-> Raydium        |
   |   single-venue model  -> domain shift      |
   |   multi-source fusion -> mitigates it      |
   +--------------------------------------------+

   TIMING: vast majority rug within 1 hour of launch
           -> a 5-minute detector is early enough

Think of it as a bouncer who can only watch the first five minutes of the party. The traditional fraud detector is an auditor who reads the building’s blueprints — looking for a hidden back door in the contract. On Solana, there is no hidden door: the building is a tent, and the crime is that the host folds the tent an hour in and leaves with the entry fees. What the bouncer can see in five minutes is telling: how fast the crowd arrived, whether the “VIPs” are actually buying or only being advertised as buying, whether liquidity is being quietly withdrawn while the music plays. None of that requires reading any code, and all of it is visible almost immediately. The catch is that the bouncer trained on one club’s crowd does worse at a different club — hence mixing venues.

Key Concepts

• Liquidity manipulation as the attack surface: on Solana, the fraud lives in how the liquidity pool is created, funded and drained, plus the social pressure that recruits buyers, rather than in contract code. This is what makes code-level detection structurally inapplicable rather than merely less effective.
• The prediction horizon: how much history a detector is allowed to see before it must commit. Here the constraint is forced by the data — most rugs complete within an hour — so the authors target five minutes. Choosing the horizon first is the right methodology, because a detector evaluated at an unrealistic horizon is measuring nothing useful.
• Cross-platform domain shift: the degradation that occurs when a detector trained on one launchpad is applied to another. Multi-source data fusion is the demonstrated mitigation, and it is the paper’s main practical recommendation for anyone deploying such a model.

Framework Shift

Before (Ethereum-style, code-centric):
  token -> read smart contract bytecode
        -> flag mint / hook / owner-withdraw patterns
  Assumes: the fraud is IN THE CODE
  On Solana: usually nothing to flag
  Horizon: whatever history is convenient

After (Solana-style, behaviour-centric):
  token -> first 5 minutes of trading behaviour
        -> gradient boosting
  Assumes: the fraud is IN THE MARKET DYNAMICS
  Trained on 6.4M tokens / 7 months
  Horizon: 5 minutes (forced by data: rugs at 1h)
  Deploy: fuse multiple venues to survive domain shift

From auditing what a contract is allowed to do, to watching what a market actually does in its first minutes, the core shift is reading intent from behaviour when the code has been stripped of intent.

Expert Assessment

Problem choice: Strong, and well-motivated by the chain’s actual economics. Recognising that a whole class of detection technique is inapplicable — not merely weaker — on the dominant memecoin chain is the contribution that opens the work, and the one-hour rug statistic justifies the five-minute horizon rather than leaving it as arbitrary.

Method maturity: The method is a tree ensemble, and the paper is honest that this suffices. The interesting engineering is in dataset assembly and feature timing, not modelling — 6.4 million tokens over seven months is a considerable undertaking and it is the actual bottleneck the field faced. A reader hoping for a novel architecture will be disappointed; a reader who wants a working detector will not be.

Experimental integrity: The cross-platform evaluation is the paper’s most valuable methodological move, because a detector reported on one venue is nearly uninterpretable for deployment. Showing that domain shift is real and that multi-source fusion mitigates it is the kind of finding that changes how others build. The standing caution is inherent to the label: determining ground-truth rugs at scale requires a definition, and how borderline tokens are classified will drive measured performance more than any modelling choice. The paper would be stronger if it opened the label definition to scrutiny.

Writing quality: The market analysis that surfaces the one-hour rug statistic is doing real work — it converts “early detection would be nice” into “five minutes is the required horizon”, and everything downstream follows. Where it could be more specific is the feature set: the early-trading signals that carry the detection are named only loosely, and concrete examples would help practitioners reproduce and extend the work.

Verdict: accept — a practical, well-scoped benchmark and detector for a chain that had none, with a generalization finding that is more useful than the headline accuracy.

Takeaways

• Match the detection horizon to the attack. If the fraud completes in an hour, a model needing a day of history is decoration; let the data choose the window.
• When moving a fraud detector across venues, assume domain shift and fuse sources. Training on a single launchpad and deploying to another is the failure mode this paper exists to prevent.
• Do not reach for deep architectures before confirming that the signal is not already linearly separable by a tree ensemble. Here, gradient boosting on five minutes of data was enough, and saying so is more useful than a bigger model.
• Ask whether the code-level features you rely on actually exist in the target domain. On Solana they largely do not, and a method built on absent features fails silently rather than loudly.