A taxonomy of market abuse

Wonder

1. Why does a token contract need an admin key if it is supposed to be permissionless?
2. How can two identical trades result in different prices depending on who submits them first?
3. If code cannot prevent social engineering, what part of the market remains vulnerable?

Explore

Part IA taxonomy of market abuse

1. Market abuse falls into six distinct layers, each exploiting a specific structural weakness. The contract layer involves retained powers like minting or freezing; the market-structure layer includes thin pools and curve designs; the ordering layer exploits transaction sequencing; the fake-activity layer inflates volume and holder counts; the social layer manipulates trust through impersonation; and the wallet layer drains assets via phishing. Each layer falls to one of four defenders (code, market design, cryptography or people), and this level shows that tools for each already exist. It is written for builders and users alike.
2. The contract layer is where theft often begins. If a developer retains mint authority, they can print new tokens at will and sell them against existing holders. Freeze functions allow them to block specific wallets from selling, effectively trapping capital. Upgradeable proxies let developers swap the underlying code after launch. These are not bugs; they are features that create an attack surface. Removing these keys eliminates the threat but also removes the ability to fix critical errors or respond to emergencies.
3. Ordering attacks exploit whoever can see pending transactions before they are ordered. Front-running occurs when a trader sees a pending order and submits their own transaction with a higher fee to execute first. Sandwiching involves buying just before a victim’s large swap and selling immediately after, profiting from the price impact caused by that swap. These losses fall on ordinary traders who receive worse execution prices. Slippage limits cap potential losses but do not prevent the attack itself.
4. Launch attacks exploit the speed of first-come pricing. Snipers buy tokens in the very first block of a launch, often using bundles to group multiple transactions together for atomic inclusion. Sybil wallets allow a single actor to control many addresses, disguising concentration and farming per-wallet rewards. These attacks rely on cheap address creation and reward structures that are not linear in holdings. Detection usually requires analyzing funding graphs after the fact.
5. Fake activity inflates metrics that drive attention. Wash trading involves buying and selling tokens between one’s own wallets to create artificial volume. Volume bots churn trades to climb trending lists, while dust spraying creates fake holder counts. When every trade pays a fee, wash trading becomes expensive, but when trending algorithms weight unique wallets, Sybil attacks become profitable. These distortions mislead investors about genuine market interest.
6. The social layer exploits human trust rather than code. Undisclosed paid promotions, impersonation of official accounts, and coordinated pump-and-dumps require no technical vulnerability. Phishing sites and malicious approvals drain wallets directly from users. Code can make these attacks visible through on-chain history verification, but it cannot prevent them. These threats live in the behavior of people, not the logic of contracts.

Part IIWhat code can fix, and what it cannot

7. Contract logic defines what is possible. If code retains a mint function accessible only to an administrator, that key remains a permanent attack surface. Removing the mint authority entirely eliminates the risk of uncontrolled inflation. Similarly, deleting sell-tax variables or freeze functions prevents honeypots and blacklist abuse. These are binary choices: the power exists, or it does not.
8. Market structure determines execution order. In sequential processing, the first buy in a block gets the best price. Batch clearing mechanisms group transactions within a time window and execute them all at one uniform clearing price. This neutralizes front-running and sandwiches within the batch, because every order gets the same price: going first, or wrapping someone else’s order, earns nothing.
9. Some risks are bounded but not eliminated. A creator holding forty percent of supply can dump it, crashing the price for early buyers. Code can lock or vest a creator’s supply, but cannot stop an unlocked holder from selling. This is market risk, distinct from theft. Buying in an earlier block can also still pay. Designers must accept that volatility from large holders is an inherent feature of permissionless markets, not a bug to be patched.
10. Social engineering lives outside the codebase. Phishing links, impersonated accounts, and paid promotions exploit human trust, not computational vulnerabilities. No smart contract can verify whether an influencer disclosed their stake before calling a token. These attacks persist regardless of technical security because they operate on attention and belief, not state transitions.
11. An honest design document lists which attack classes are eliminated by code, which are neutralized by market mechanics, and which remain irreducible to human behavior. It states explicitly: mint abuse is impossible; sandwich attacks are mitigated by batching; phishing remains a personal security responsibility. This transparency allows users to price their risk accurately rather than assuming total safety.
12. Open a block explorer for an EVM token with verified source code and look for functions such as `mint`, `pause` or `owner`; on Solana, check the mint and freeze authorities and the program’s upgrade authority instead. Verify whether these functions are callable by anyone or restricted to a specific address. If no such functions exist and the contract is not upgradeable, those attack vectors are structurally absent, not merely disabled.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Chainalysis, Crypto Crime Report (2024)
• P. Daian et al., 'Flash Boys 2.0' (IEEE S&P 2020)
• SPL Token documentation
• OpenZeppelin proxy documentation
• E. Budish, P. Cramton & J. Shim, 'The High-Frequency Trading Arms Race' (QJE 2015)