Poison Token

A poison token's defining feature is a non-standard ERC-20 transfer function that intentionally deviates from the expected behavior. Instead of simply moving tokens from A to B, the function may:

• Revert on specific conditions (e.g., if the recipient is a DEX pool).
• Charge excessive fees that are siphoned to the attacker.
• Lock tokens in the recipient's address, making them unusable. This breaks the fundamental assumption of composability, causing transactions in integrated protocols to fail.

These tokens are engineered to exploit the composability of DeFi, where protocols seamlessly interact. They target common patterns:

• Liquidity Pool Deposits: A user approves and calls addLiquidity on a DEX; the non-standard transferFrom fails, causing the entire transaction to revert and potentially locking funds.
• Flash Loan Repayments: A flash loan contract attempting to repay using the poison token will fail, allowing the attacker to steal the borrowed assets.
• Proxy/Upgradeable Contracts: May exploit storage collision during delegate calls.

Attackers deploy poison tokens to trigger specific failure modes in victim contracts:

• Griefing: Simply preventing a protocol's function from completing, often to disrupt operations or extract a ransom.
• Fund Theft: Causing a failure in a conditional flow (like a flash loan repayment) that allows the attacker to seize collateral.
• Governance Attack: Blocking the execution of a governance proposal by ensuring a token transfer within the proposal's logic fails. The 2021 MakerDAO governance attack, where a 'shadow token' disrupted proposal execution, is a canonical example.

Protocols must implement defensive checks to avoid poison token vulnerabilities:

• Using balanceOf Checks: Instead of relying solely on the return value of transfer or transferFrom, check the recipient's balance change before and after the call.
• Employing a Deny List: Maintaining an on-chain or off-chain list of known malicious token addresses.
• Standard Compliance Verification: Using libraries like OpenZeppelin's SafeERC20 wrapper, which uses safeTransfer to handle non-compliant tokens.
• Isolating External Calls: Treating all token interactions as potentially hostile and isolating them in the transaction flow.

The exploit exists due to a gap between the de facto standard and the formal EIP-20 specification. The EIP states a transfer must return true on success but does not mandate specific behavior for failures beyond reverting. Malicious tokens comply technically (they revert) but do so strategically to cause maximum damage. This highlights the risk of relying on unverified external contracts in a trustless environment.

It is crucial to distinguish poison tokens from simple scam tokens:

• Poison Token: A technical weapon. Its code is designed to actively break other systems. It may have no value itself.
• Scam/Rug Pull Token: A financial scam. It uses standard code but involves malicious human action (e.g., minting unlimited supply, removing liquidity). A poison token attack is a smart contract exploit; a rug pull is a market manipulation and exit scam. The former breaks code, the latter breaks trust.

A token that charges a percentage fee on every transfer, which is not reflected in the token's balanceOf return value. This breaks the standard assumption that balanceOf(to) == previousBalance + amount. When a protocol calculates rewards or liquidity based on the inaccurate balance, it creates an accounting mismatch that can be exploited.

• Example: A user deposits 100 tokens, but due to a 10% fee, the contract only receives 90. The protocol still credits the user for 100, allowing them to withdraw more than the contract holds.

A token where the holder's balance automatically increases or decreases at set intervals, independent of transfers. This violates the expectation of a static balanceOf return. If a protocol snapshots a user's balance for rewards or voting power before a rebase, the value becomes incorrect, allowing for manipulation.

• Key Feature: The totalSupply and individual balances change programmatically, often to peg to another asset's value.

A token that overrides the standard transfer or transferFrom functions with custom logic that can block transactions based on conditions like sender, receiver, time, or amount. This can trap funds inside a protocol's smart contract.

• Attack Vector: A user deposits the token into a lending protocol. Later, the token's contract blocks transfers from the protocol's address, making it impossible to withdraw or liquidate the collateral, freezing the protocol's funds.

A fee structure that applies dynamically based on transaction size or holder balance. Large transfers (often deemed "whale" transactions) incur prohibitively high fees, sometimes up to 99%. This targets protocols that perform large, automated transfers for functions like liquidity provisioning or large liquidations.

• Impact: A lending protocol attempting to liquidate a large position could have almost the entire collateral seized eaten by fees, rendering the liquidation pointless and insolvent.

A token that distributes a portion of every transaction fee as rewards to existing holders, directly to their wallets. This continuously changes the token's totalSupply and the balances of all holders, including smart contracts. Protocols holding these tokens see their balance fluctuate unpredictably, breaking internal accounting for collateral value or pool reserves.

A centralized function allowing the token deployer to add addresses to a blacklist, preventing them from sending or receiving the token. This is a severe form of transfer restriction. If a DeFi protocol's core contract is blacklisted, all user funds denominated in that token within the protocol become permanently frozen and unrecoverable.

Some tokens implement transfer fees (e.g., a 1% tax on sends). While sometimes legitimate, attackers can weaponize this. If a protocol's logic assumes balanceOf reflects the actual received amount, it can be tricked. For example, a user might appear to provide 100 tokens as collateral, but due to the fee, only 99 arrive. If the protocol lends based on the 100 figure, it creates an instant, risk-free bad debt position for the attacker.

A classic poison token exploit involves overriding the standard balanceOf function. The token returns a manipulated balance, such as always reporting a user's balance as type(uint256).max. An unsuspecting protocol that uses this to check collateralization ratios would see the attacker as infinitely solvent, allowing them to borrow all available assets without ever being liquidated.

Protocols defend against poison tokens through rigorous token whitelisting and security audits. Key technical mitigations include:

• Using internal balance tracking instead of relying on external balanceOf calls.
• Implementing time-weighted average price (TWAP) oracles resistant to single-block manipulation.
• Adding pause functions and circuit breakers to halt operations during anomalous price movements.
• Thoroughly vetting token standards and rejecting non-standard implementations.

Poison tokens are often deployed in conjunction with flash loans. An attacker borrows a massive amount of capital to:

1. Poison a liquidity pool (via donation).
2. Manipulate an oracle price using the poisoned pool.
3. Exploit the incorrect pricing on a lending protocol to borrow or liquidate assets.
4. Repay the flash loan and pocket the profit, all within a single transaction block. This combines oracle manipulation with capital efficiency for devastating effect.

The most common poison token exploit uses a fee-on-transfer mechanism. When a user attempts to swap for the token, a hidden tax is deducted after the DEX's price calculation. This causes the contract to send more tokens than it receives, resulting in a failed transaction and a loss of gas fees for the victim.

• Example: A token with a 10% transfer fee. The DEX calculates a swap for 100 tokens, but only 90 arrive in the user's wallet, causing a revert.

The primary mitigation is implementing a balance check before and after the token transfer. A secure contract will:

1. Record the contract's balance of the output token before the swap.
2. Execute the transfer to the user.
3. Verify the actual amount received equals (new_balance - old_balance).

If the received amount is less than expected, the transaction should revert to protect the user's funds.

Some poison tokens exploit token whitelist logic in contracts. If a DEX only checks if a token is not on a blacklist, an attacker can deploy a new, malicious token with the same interface. Robust security requires positive permissioning (a strict whitelist of known-good tokens) rather than just a list of known-bad ones.

To build resilient systems:

• Use established libraries: Rely on battle-tested DEX routers and liquidity pool implementations that have integrated balance checks.
• Implement slippage controls: While not a complete fix, minimum output amount parameters can provide a secondary defense.
• Audit token contracts: For projects launching their own tokens, ensure the contract does not contain unexpected fee logic that could be exploited by others.

End-users can mitigate risk by:

• Avoiding unknown tokens: Be highly skeptical of tokens with no verified contract source, low liquidity, or recent creation.
• Using reputable interfaces: Major front-ends often integrate basic poison token detection.
• Understanding transaction previews: If a swap preview shows an implausibly good rate for an obscure token, it is likely a trap.

Poison token attacks gained prominence around 2021-2022, targeting automated market makers (AMMs) like Uniswap V2. While the direct financial loss is typically limited to wasted gas fees, the attack creates network congestion and erodes user trust. The standardization of balance check mitigations in later protocol versions (e.g., Uniswap V3 routers) has reduced their prevalence.

A rug pull is a malicious exit scam where developers abandon a project and drain its liquidity. While a poison token is a specific technical attack, a rug pull is the broader fraudulent outcome. Key characteristics include:

• Withdrawal of Liquidity: Removing all funds from liquidity pools.
• Abandoned Project: Developers disappear, shutting down social channels.
• Asset Devaluation: The token's value plummets to near zero. Poison tokens are often the technical mechanism used to execute a sophisticated rug pull.

A honeypot is a smart contract that appears legitimate but contains hidden logic preventing users from selling their tokens. It is a close relative of the poison token. The core mechanism involves:

• One-Way Transactions: Users can buy but are blocked from selling via hidden require() statements or owner-controlled blacklists.
• Enticement: Often promoted with fake liquidity and social proof to attract victims.
• Distinction: While all honeypots are malicious, not all use the specific 'fee-on-transfer' or 'blacklist' mechanics of classic poison tokens.

A fee-on-transfer token is a legitimate ERC-20 design that applies a fee (e.g., for staking, burns, or treasury) on every token transfer. This benign mechanism is weaponized in poison token attacks. How it works:

• Standard Behavior: A percentage of a transferred amount is deducted and sent to a designated address.
• Exploitation: Malicious actors set the fee to an extreme value (e.g., 99%) or direct it to their own wallet.
• Critical Check: Protocols must check the actual balance change after a transfer, not just the amount parameter, to avoid poison token exploits.

Token sniping (or front-running bots) and blacklist functions are key components in advanced poison token schemes.

• Sniping Bots: Automated bots that buy new tokens immediately after liquidity is added, hoping to sell at a profit before the trap is sprung.
• Blacklist Exploit: The malicious contract includes an onlyOwner function to add addresses to a blacklist, blocking their transfers. The deployer blacklists the sniping bots after they buy, trapping their funds, while allowing unsuspecting retail buyers to enter.

A smart contract audit is a manual and automated review of a contract's code to identify security vulnerabilities, including poison token logic. It is the primary defense. Auditors look for:

• Hidden Transfer Fees: Unusual logic in _transfer, transfer, or transferFrom functions.
• Owner Privileges: Dangerous onlyOwner functions like setBlacklist or setFee.
• Balance Check Discrepancies: Ensuring protocols calculate deposits based on post-transfer balance changes. Relying on unaudited contracts significantly increases poison token risk.

Decentralized Exchanges like Uniswap have implemented safeguards to mitigate poison token and related scams. Key protections include:

• Token Warning Systems: Displaying clear warnings for unverified, recently created, or suspicious tokens.
• Liquidity Lock Transparency: Showing if pool liquidity is locked via a trusted service.
• Holder Distribution Analysis: Highlighting tokens with skewed distributions indicative of a potential rug pull. While helpful, these are not foolproof, and user due diligence remains essential.