How to Detect a Token With a Trading Cooldown or Max Transaction Limit

18 October 2026

You detect a trading cooldown or a max transaction limit by reading the token contract's source code - usually on a block explorer - and looking for specific functions and state variables that impose time delays or per-transaction caps. These mechanisms restrict when and how much you can buy or sell, and they are often invisible in a swap interface's warning screen.

This page walks through the exact checks, step by step. It assumes you already know how to verify a contract address and read basic code on a block explorer. If not, start with the site's guide on verifying a token address before you proceed.

What these restrictions look like

A trading cooldown is a time delay between transactions from the same wallet. A common pattern is a variable like _cooldownPeriod or _lastTradeTime, where the contract stores the block timestamp of the last trade and refuses new trades until a certain number of seconds have passed. Some tokens apply this only to selling, others to both buy and sell.

A max transaction limit is a cap on the number of tokens (or their value) that can move in a single swap. The contract checks the amount being transferred against a stored limit - often named _maxTxAmount, _maxTx, or _maxTransfer - and reverts the transaction if the amount exceeds it. The limit might apply to buys, sells, or both. It may also apply to transfers between any two wallets, not just trades.

Both mechanisms are usually implemented as modifiers or as internal checks inside the _transfer function. You do not need to understand Solidity deeply, but you do need to know what to look for.

Step 1: Open the Contract on a Block Explorer

Go to the verified contract page for the token's address. You want the Contract tab, then Code (or Read/Write if the source is already verified). If the source is not verified, stop here - you cannot reliably check these conditions without reading the code. A token that hides its source is a risk in itself.

If the source is verified, search the code for these keywords:

• cooldown
• maxTx
• maxTransfer
• _max
• timeLock
• delay

Most tokens with these features use names close to these. But do not rely on naming alone. A token can use a non-standard name like _limit or _interval. So also look at the _transfer function itself.

Step 2: Read the _transfer Function

This is the heart of the matter. Every ERC-20 transfer - including buys and sells - eventually calls _transfer internally. Find that function in the code. It will typically look like a function with parameters (address sender, address recipient, uint256 amount).

Inside _transfer, look for two things:

2a. A check on the amount

You are looking for a line like:

require(amount <= _maxTxAmount, "Transfer exceeds max limit");

Or:

require(amount <= _maxTxAmount && amount <= _maxWalletAmount, "Limit exceeded");

Sometimes the check is written as an if statement that reverts:

if (amount > _maxTxAmount) revert();

The exact wording does not matter. What matters is that the function compares the incoming amount to a stored variable and reverts if the amount is too large. If you see that, the token has a max transaction limit. Check whether the check applies to both buys and sells. Some contracts apply it only when sender is a pair (a DEX pool) or only when recipient is a pair. You can usually tell by looking at the surrounding if conditions - they will check for addresses like uniswapV2Pair or pancakeswapPair.

2b. A time check

Look for a line that reads the current block timestamp:

uint256 currentTime = block.timestamp;

And then a comparison:

require(currentTime >= _lastTradeTime[msg.sender] + _cooldownPeriod, "Wait");

Or:

require(block.timestamp - _lastTrade[sender] > _cooldown, "Cooldown active");

Some contracts store the last trade per wallet in a mapping, like _lastTradeTime[user]. Others use a single global timestamp for all traders. The effect is the same: a delay between allowed transactions.

If you see a block.timestamp comparison in _transfer, or in a modifier attached to _transfer, that is a cooldown. Note that some tokens apply the cooldown only to selling, and some only to buying. Check which side uses the pair address as sender or recipient to determine which direction is restricted.

Step 3: Check the State Variables

Once you see the checks, trace back to the variables they read. Scroll up in the code to find declarations like:

uint256 public _maxTxAmount = 1_000_000 * 10**18;
uint256 public _cooldownPeriod = 60; // 60 seconds

These values are set at deployment, but they can often be changed later. Look for setter functions:

• setMaxTxAmount(uint256 newAmount)
• setCooldownPeriod(uint256 newSeconds)

If those setters exist and are not restricted to onlyOwner - or if they are callable by anyone - that is a serious red flag. But even with onlyOwner, an owner can change the limit or cooldown at will. That is not a flaw by itself, but it means the contract can be made more restrictive after you buy.

Also check whether the variables are public. If they are, you can read their current values on the Read Contract tab of the explorer without searching the code.

Step 4: Use the Read Contract Tab

If the contract is verified, go to Read Contract on the explorer. Look for the variable names you found in the code. If _maxTxAmount is public, it will show there. Same for _cooldownPeriod or whatever they are called.

This gives you the current value. But remember: a contract can change these values later. Reading them tells you the situation now, not the situation after the owner calls an update function.

Step 5: Check for Exemptions

Many tokens with these restrictions include exemptions. For example:

• The owner might be exempt from the max transaction limit.
• A whitelist might allow certain addresses to bypass the cooldown.
• The DEX pair itself might be exempt from limits.

Look for a function like isExcludedFromLimit(address) or isExcludedFromCooldown(address). These are often public mappings or functions. If you can read them, check whether your own wallet address is exempt. It almost certainly is not - unless you are the deployer - but the point is to understand who can trade freely. If only the owner is exempt, the limit applies to everyone else.

What you are actually looking for

• A max transaction limit is not necessarily a scam. Many legitimate tokens use them to prevent large dumps or to comply with certain regulations. The risk is if the limit is extremely small (e.g., 0.1% of supply) or if the owner can change it to near-zero after launch.

• A cooldown is more unusual. It is common in "anti-bot" or "anti-whale" designs. But a cooldown of several minutes or hours makes the token effectively illiquid for that period. If you need to sell quickly, you cannot.

• A changeable limit is the real danger. A token that lets the owner update the max transaction amount or cooldown period can be manipulated. The owner could set a tiny limit to freeze all trading, then remove it later.

What to do if you find one

If the token has a cooldown or max limit, decide whether the restriction is acceptable for your intended holding period. A 30-second cooldown is minor. A 24-hour cooldown is a different asset class entirely. A max transaction limit at 1% of supply might still allow you to sell a normal-size position. At 0.01%, it does not.

Check whether the setters are onlyOwner. If they are, the team can change the rules. That is not inherently evil - but it means you are trusting them. If the setters are public or callable by anyone, the token is unsafe to trade at all.

Finally, run a test transaction with a tiny amount. You already know how to simulate buy and sell tax from the site's other guide. Do that. A small trade will fail if the limit or cooldown is active, and the error message will often tell you exactly which condition failed.

That error message - not the code - is the ground truth.

Back to token safety