---
title: 'TradeTrap: DEX Scam and Evaluation Framework'
url: https://www.emergentmind.com/topics/tradetrap
type: topic
---

# TradeTrap: DEX Scam and Evaluation Framework

TradeTrap denotes, in the decentralized-exchange literature summarized from "From Programming Bugs to Multimillion-Dollar Scams: An Analysis of Trapdoor Tokens on Uniswap," a class of ERC-20 sell-blocking scam tokens that allow users to buy but prevent them from selling, thereby trapping incoming high-value assets in a Uniswap liquidity pool until the creator or privileged addresses withdraw the paired asset [2309.04700]. In closely related work on DEX honeypots, the same underlying phenomenon is described as a malicious pool in which the AMM and router are legitimate but the token contract embeds restrictive or backdoored logic, so traders can exchange ETH or WETH for the fraudulent token yet cannot exchange it back under normal conditions [2309.13501]. The term also appears in later literature in a different sense, as the name of a unified stress-testing framework for LLM-based autonomous trading agents [2512.02261].

## 1. Core definition and economic setting

In the DEX-scamming sense, a TradeTrap is a token-level mechanism rather than an AMM-level failure. Uniswap V2 is agnostic to token logic, and the sell-blocking behavior resides in the ERC-20 contract: logical bugs and owner-only features are placed on the sell path, or fee logic is tuned so that selling becomes economically impossible [2309.04700]. This is why the pool can appear liquid and tradable while remaining non-exitable for ordinary traders.

The practical transaction pattern is consistent across the literature. An attacker deploys a token with hidden sell constraints, seeds a Uniswap V2 or V3 pool against a valuable asset such as ETH or WETH, manufactures credibility through similar names, social hype, or wash trading, and induces victims to swap into the fraudulent asset. The trap manifests when a trader attempts the reverse leg: the sell reverts, is silently discarded, or yields only a negligible fraction of the AMM-quoted output. The attacker then exits by removing liquidity or swapping collected tokens for WETH or ETH [2309.13501].

This design is distinct from centralized-exchange fraud. CEX scams rely on off-chain custody and centralized listing or withdrawal controls, whereas DEX honeypots exploit token contract logic in a permissionless listing environment. A plausible implication is that DEX security at the protocol layer does not imply safety at the token layer; the decisive attack surface is the transfer semantics of the listed ERC-20 rather than the pool invariant itself.

## 2. Contract-level mechanisms and concealment tactics

The primary taxonomy in the Uniswap Trapdoor study classifies sell-blocking tokens by the main mechanism used to prevent selling: conditional assertion, trading fee manipulation, and numerical exceptions [2309.04700]. Conditional assertion tokens impose hard conditions on transfers to the liquidity pool. A representative pattern is a pre-sell gate in a hook or modifier, such as `require(isEnabled[msg.sender])` in `_beforeTokenTransfer` when `to == uniswapV2Pair`, so only the creator can sell. Another pattern is the silent ignore of sells, for example `if (snipers[to]) return;` inside `_transfer`, with the pool address inserted into `snipers`, so `to == pair` is discarded rather than reverted.

Trading fee manipulation traps use apparently standard tokenomics to confiscate the transfer amount on sell or across a buy-sell cycle. One design applies a fixed confiscatory fee on both paths, so a buy works but loses about \(90\%\), and the sell loses another \(90\%\), producing a net loss of about \(99\%\) over a round trip. Another design begins with modest fees to attract buyers and later uses an owner call such as `sellFee` to raise `sellmktFee` to \(99\%\), pushing the total sell fee to \(105\%\), so sellers receive nothing. The essential feature is not merely high taxation but owner-tunable fee control after deployment.

Numerical-exception traps rig arithmetic so that only the sell path triggers overflow, underflow, or division by zero. The study reports contracts in which `totalSellTax` is raised from \(0\%\) to \(1000\%\), so `rAmount = amount − fee` underflows and reverts on sell, as well as contracts where fees are set to zero as bait and `swapBack` later computes `realTotalFee == 0` and divides by it only on sell.

These behaviors are frequently concealed. The supplied catalogue reports misleading naming such as `snipers` for a blacklist, tagging the pool as a “zero address,” or naming `findNinetyPercent` as `tenPercent`; blank revert messages; single-character variable names; dummy initialization functions that are never called; incomplete ownership renouncement in which a secondary privileged address retains control; and trap placement outside `_transfer`, including modifiers, nested functions, external contracts, and bytecode-only `botProtection` dependencies [2309.04700]. A recurrent misconception is that a visible renounce of ownership implies safety; the observed pattern of secondary admin control shows that this is not sufficient.

## 3. Attack effects, user-visible symptoms, and relation to honeypots

A complementary taxonomy classifies DEX honeypots by the effect observed by the victim rather than by the code-level mechanism: Invalid Buy, Unauthorized Transfer, Cannot Sell, and Invalid Sell [2309.13501]. This effect-oriented view is broader than the narrower TradeTrap definition but overlaps substantially with it.

Invalid Buy occurs when the amount actually credited to the buyer is far below the AMM-expected output, often because a hidden or dynamic buy tax is applied or because the contract emits a `Transfer(amount)` event while crediting only a small fraction of that amount to the recipient balance. Unauthorized Transfer occurs when the victim’s balance is later reset to zero or drained without approval, including owner-only functions that directly mutate balances or post-buy monitoring in which recent buyers are selectively zeroed out. Cannot Sell is the canonical Trapdoor effect: the sell transaction reverts outright because of blacklist or whitelist logic, anti-bot gates, block or time conditions, or owner-only sell paths. Invalid Sell denotes the case in which the sell succeeds but the realized proceeds are at most a small fraction of the AMM quote because of dynamic sell taxes or effective sell clamps such as `maxSellAmount`.

The behavioral signatures are deliberately operationalized. The honeypot study uses a \(50\%\) discrepancy threshold between AMM-estimated output and realized balance deltas for Invalid Buy and Invalid Sell, and repeated consistent reverts in simulated sell transactions for Cannot Sell. For Unauthorized Transfer it cross-checks `Transfer` and `Approval` events against `balanceOf(account)` so that unexplained balance drops or transfers without sufficient allowance can be detected [2309.13501]. This suggests that event logs alone are not a reliable forensic source, because malicious tokens may use deceptive event emissions as part of the attack surface.

## 4. Detection pipelines, semantic indicators, and machine learning

The main detection system associated with the Trapdoor-token literature is TrapdoorAnalyser, a fine-grained pipeline that combines a Brownie-based dynamic buy-and-sell test with contract-semantic inspection and opcode-based machine learning [2309.04700]. The dynamic stage runs `TokenBuyingTest` and `TokenSellingTest`: the buying test simulates transfer from pool to investor and asserts success with received amount at least `amount × (1 − 0.3)`, while the selling test simulates transfer from investor to pool and asserts success with pool receipt at least `amount × (1 − 0.3)`. If buy succeeds and sell fails, or the sell fee is confiscatory, the token is flagged for semantic analysis. The formal trade mechanics are given as
$$
R_x R_y = (R_x + \Delta_x(1 - \gamma))(R_y - \Delta_y),
$$
with \(\gamma = 0.003\).

The semantic stage manually inspects source code or decompiled logic for indicators that imply sell blocking. The supplied indicator list includes conditions on `to == uniswapV2Pair` that require whitelist membership or owner status; `blacklist[to]` or `blacklist[pair]`; silent early returns when `to == pair` or `snipers[to]`; owner-callable fee setters such as `sellFee` and `setSellFees`; `maxSellAmount` updates to `0` or `1`; arithmetic using `totalSellTax` or `realTotalFee` that can exceed the amount or divide by zero; `shouldSwapBack` gates that only fire on one path; external `botProtection` checks with obfuscated names; and ownership renouncement that leaves trap switches under secondary control. Error-log generation records revert status, often blank error messages, and fee deltas from balance checks, so the tool can cross-check indicators against observed failures and produce explainable traces.

The bytecode classifier uses opcode frequency vectors extracted from bytecode, with 283 unique opcodes or features, so classification remains possible without verified Solidity source. The reported models are Random Forest, XGBoost, LightGBM, KNN, and SVM, with tree-based models dominating: LightGBM achieves accuracy \(0.983\), precision \(0.989\), recall \(0.988\), and \(F1\) \(0.989\); Random Forest achieves accuracy \(0.980\), precision \(0.993\), recall \(0.981\), and \(F1\) \(0.987\); XGBoost achieves accuracy \(0.980\), precision \(0.986\), recall \(0.987\), and \(F1\) \(0.987\). The most discriminative opcodes reported as more frequent in Trapdoor tokens are `GT`, `LT`, `OR`, `NOT`, `MUL`, and `SLOAD`, with average frequencies such as `GT (20 vs 11)`, `LT (24 vs 16)`, `MUL (28 vs 12)`, `OR (10 vs 4)`, `NOT (14 vs 9)`, and `SLOAD (66 vs 42)`.

One methodological nuance is worth recording exactly. The abstract states that TrapdoorAnalyser “outperforms the state-of-the-art commercial tool GoPlus in accuracy,” whereas the detailed summary also states that the paper “does not benchmark against GoPlus or other third-party scanners” and instead focuses on explainable code-level analyses and opcode classifiers [2309.04700]. The coexistence of these statements is part of the supplied record.

## 5. Empirical prevalence, case studies, and operational implications

The reported measurement window covers tokens listed on Uniswap V2 from May 2020 to January 2023. The data collection pipeline gathered 131,172 unique token addresses; after filters it retained 4,150 suspicious tokens, 2,723 with source, and a final verified Trapdoor dataset of 1,859 tokens, alongside a non-malicious set of 621 high-value tokens, for a total of 2,480 used for machine learning. The same paper’s abstract also describes “the very first dataset of about 30,000 Trapdoor and non-Trapdoor tokens on UniswapV2” [2309.04700].

The quantified damage is substantial. The 1,859 Trapdoor tokens extracted 133,677 ETH, approximately US\$220M, from 53,318 investor addresses. Fifty-nine percent had lifetimes under 24 hours, although some lived over a year; the example “Mommy Milkers” is reported to have approximately 1,400 victims. A further 15.7% mimicked the names or symbols of high-value tokens such as “BONE.” In related large-scale screening of DEX honeypots, 10,000 pools were randomly sampled from Uniswap V2 and V3, and 8,443 were flagged as abnormal: 2,395 Invalid Buy, 5,083 Unauthorized Transfer, 5,104 Cannot Sell, and 3,216 Invalid Sell, with some pools triggering multiple categories [2309.13501].

The named case studies illustrate the main patterns with transaction-path specificity. AquaDrops (`0x3E19C4…F34d9`) uses `_beforeTokenTransfer` to enforce `require(_enable[from])` when `to == pair`, and `_enable` is populated only with the creator, so buys succeed and sells revert with a blank message for everyone else. LGT (`0xc67979…e2ca57`) includes the pool in a `snipers[to]` list and returns early in `_transfer`, so sells are silently discarded with no transfer and no explicit error. Seppuku (`0xF49C17…CB670`) misnames a roughly \(90\%\) deduction function as `tenPercent`, so the round-trip loss is about \(99\%\). 88 Dollar Millionaire (`0xe053Cf…E4925`) later sets `sellmktFee` to \(99\%\) through `sellFee`, so the total sell fee becomes \(105\%\). CPP4U (`0x9314e4…49804`) raises `totalSellTax` to \(1000\%\), causing underflow. Squid-X (`0x42a412…49a43`) sets buy and sell fees to zero as bait, then triggers division by zero in `swapBack` on the sell path [2309.04700].

The practical implications are direct. Uniswap V2’s AMM cannot prevent sell-blocking traps because the malicious behavior lives in the ERC-20 contract, not the pool. The analysis is stated to be applicable to Uniswap V2 forks and other versions; concentrated liquidity in V3 does not eliminate sell-blocking traps, although routing differences may affect dynamic testing thresholds. Known evasions include post-deployment fee or switch toggles, masked owner roles, external `botProtection` contracts, silent discards without revert, blank error messages, and same-name impersonation. Recommended defenses include a small buy and immediate sell test against the exact pair address, inspection of `_transfer`, `_beforeTokenTransfer`, blacklists, whitelists, owner-only checks, `maxTxAmount` gating, and fee setters callable after deployment, as well as historical review of owner transactions that change fees or trading switches [2309.04700]. The honeypot literature adds that legitimate restriction logic can produce false positives; the example given is USDC-style blacklist or compliance logic, which may require manual review [2309.13501].

## 6. Later and distinct uses of the label

In later research, "TradeTrap" is also the title of a system-level evaluation framework for LLM-based autonomous trading agents. In that usage, it is not a DEX scam class but a unified closed-loop backtesting harness that decomposes an agent into market intelligence, strategy formulation, portfolio and ledger handling, and trade execution, then injects controlled perturbations such as data fabrication, MCP tool hijacking, prompt injection, memory poisoning, and state tampering under identical initial conditions of US\$5,000 capital, zero positions, and chronological replay of approximately 100 NASDAQ-100 constituents over October 1–31 [2512.02261]. The reported results show that small perturbations at a single component can induce extreme concentration, runaway exposure, and large drawdowns. For example, prompt injection moves an Adaptive agent from Total Return \(7.81\%\) and Max concentration \(39.17\%\) to Total Return \(0.89\%\), MDD \(8.12\%\), Sharpe \(0.29\), and Max concentration \(99.98\%\); state tampering drives a Procedural agent from Total Return \(0.91\%\) to \(-61.02\%\), MDD \(91.97\%\), Vol \(889.61\%\), Position Utilization \(646.86\%\), and final NAV US\$1,928.82.

Additional supplied summaries use the label in broader trade-analysis settings. One adapts "TradeTrap" to a maximum-entropy reconstruction of international trade networks with ridge regularization and a cost-augmented Wilson-type solution \(t_{ij} = A_i B_j E_i I_j \exp(-\beta c_{ij})\), using year-2000 NBER-UN World Trade Flows data to simulate tariff changes in FOOD and MACHINERY and reporting that halving U.S.\(\rightarrow\)Japan FOOD cost increases imports “drastically,” while doubling Japan\(\rightarrow\)U.S. MACHINERY export cost reduces those exports “drastically” and diverts flows toward the EU [1806.00605]. Another uses the label for a four-layer ensemble on UN Comtrade 2020–2024 aluminium data, combining Forensic Statistics, Isolation Forests, Network Science, and Deep Autoencoders to detect anomalies such as Hardware Masking, Void-Shoring, and Shadow Hubs; its empirical anchors include a global unit-price center around US\$8–9/kg, a high-risk cluster at median US\$167.59/kg, and a markup of roughly 1,900% [2512.14410]. A further theoretical use frames a “trade trap” as a bargaining problem under a preventive trade war, where “healthy” barriers \(b > 0\) can sustain inefficient peace by depressing war payoffs, with efficient peace at \(b = 0\) existing only if \(c_B \ge \overline{c}_B\) [2111.15598].

Taken together, these usages show that the label has bifurcated. In the cryptocurrency and DEX literature it primarily denotes a sell-blocking token or honeypot mechanism that traps traders inside a liquidity pool. In later financial-AI and international-trade work it names frameworks for adversarial evaluation, network reconstruction, anomaly triage, or strategic bargaining. The strongest commonality is structural rather than terminological: each usage concerns a system in which apparently ordinary trade or trading becomes constrained, manipulated, or strategically destabilized under hidden conditions.

Source: https://www.emergentmind.com/topics/tradetrap