Telegram Bot Honeypot Tokens Explained
What a honeypot token is, how its contract blocks your sell, and why a Telegram bot's sell button or auto-sell cannot get you out, plus the checks to run before you buy.
Published 2026-11-13
What a honeypot token is
A honeypot token is a token whose contract accepts buys but blocks sells, or makes selling so difficult that a holder effectively cannot get out. The trap is written into the token's own code before anyone trades it.
The block lives in the contract
The restriction sits on chain, inside the token contract. It is not in the Telegram bot, not in your wallet and not in the app you tap. The bot can only send a transaction asking the contract to move tokens; if the contract says no, nothing happens to your balance. That is why a token can look normal in a bot's interface and still be impossible to sell.
How the contract blocks a sell
The common patterns are:
- A blacklist or ban mapping. The owner can add any address to a list that is refused transfers. It is often applied to an address right after it buys.
- A trading switch. A flag such as
tradingEnabledortradingOpenstays on for launch and is switched off later, freezing everyone who bought. - Whitelist-only transfers. Only the owner and a set of approved addresses can send tokens, so buyers can receive but never send.
- Sell conditions. A maximum sell amount, a cooldown between sells, a limit on how many holders may sell per block, or a rule that only addresses on a list can sell at all.
Traps built to look healthy
Some honeypots let one small sell through, often from a second wallet, so the chart shows a normal-looking sale and holders assume the token works. Others allow selling only from the deployer's own addresses. The point is the same: the buy side is open, the exit is not.
Who the honeypot is for
The contract is written to trap the buy side. The deployer keeps tokens that others cannot exit while liquidity sits in the pool, and buyers who cannot sell watch the price without being able to act on it.
Money put into a memecoin can be lost in full, and a honeypot is one of the ways that happens. This is a description of how contracts work, not legal, tax or financial advice.
How a Telegram bot ends up buying one
The trade starts with a contract address. You paste it into the bot, choose an amount in SOL or ETH, and confirm. The bot builds a swap transaction and signs it with your wallet key. The transaction goes to a router, the router calls the token contract, and the contract approves the transfer in. That approval is all the buy needs to go through.
Three steps, seconds apart
- Paste the token contract address into the bot.
- Pick the amount and confirm.
- The bot signs, the router executes, and the token contract accepts the incoming transfer.
At no point does the sequence ask the contract what it will do when you sell.
Speed removes the pause where a check would fit
New pairs, one-tap buying and the habit of acting on a chart screenshot leave no gap between the decision and the signed transaction. A contract can be written so that the buy path is open and the sell path is closed, and the buy still looks normal from the bot's side. That is the whole design of a honeypot.
Sniping lands you at the moment the deployer sets the rules
A sniper buys at pair creation, which is exactly when the deployer still controls every rule in the contract. Banana Gun supports sniping and limit orders; its site states an Ethereum trade fee of 0.5% and an Ethereum snipe fee of 1% (https://bananagun.io/). You can see which bots offer this on /feature/sniping.
Copy trading and group calls skip the context
A contract address forwarded in a chat arrives on its own, with no name, no chart and no history. The buy is two taps, and the forwarding account carries no responsibility for what the contract does.
The bot only executes
A Telegram bot signs the buy and the sell. It does not audit the token, read the contract source, or know that a blacklist was applied to your address after your buy. Two traders can use the same bot on the same token and get opposite results: one sells, the other cannot, because the difference sits in the contract, not in the bot.
Honeypot, rug pull and tax token: three different traps
Traders use "honeypot", "rug pull" and "tax token" as if they mean the same thing. That blur makes the risk harder to reason about, because each trap fails at a different point and each one leaves you a different set of options.
The three traps apart
A honeypot blocks the sell inside the token contract. The buy is processed normally. The transfer out is refused, whether by a blacklist that includes your wallet, a trading switch the owner controls, an owner-only transfer rule or a sell condition that cannot be met.
A rug pull works on the market rather than on your transaction. The deployer removes the liquidity the token trades against, or sells a large supply into the pool. Your tokens still transfer; there is simply very little left to sell them into.
A high-tax token lets the sell go through but takes a large share of it. The tax rate is often adjustable by the owner, so it can be raised after you buy, including to a level that makes selling pointless.
Side by side
| Trap | What happens on buy | What happens on sell | What the trader can do |
|---|---|---|---|
| Honeypot | Buy succeeds, tokens arrive in your wallet | Transfer rejected by the contract; sell fails again and again | Nothing at token level. Revoking approvals, changing bot or changing RPC does not change the contract's transfer rules |
| Rug pull (liquidity removal) | Buy succeeds against a live pool | Sell executes into a pool that has been drained or heavily sold into, at a near-zero price | Sell early if liquidity is still there; accept that the value is gone |
| High or adjustable tax token | Buy succeeds, sometimes with a buy tax | Sell executes, but a large percentage is taken; the rate can be raised after launch | Sell and accept the loss, or hold and watch the rate change |
The practical difference is where the exit stands. A honeypot has no exit at all. A rug pull leaves an exit that is worth almost nothing. A tax token leaves an exit at a bad price but a real one.
Why the labels matter
If your sell fails because of a blacklist, no approval revoke, second bot or different RPC endpoint will free the position. Those fix permissions and connections, not contract logic. With a tax token, the cost is a percentage you can measure before you sell. With a rug pull, the market moved and your only decision is when to take what remains.
The traps also overlap. One contract can carry both a sell tax switch and a blacklist, and a deployer can rug a token that is not a honeypot. Judge the contract and the liquidity together rather than picking a single label.
Why your bot's sell button and auto-sell fail
A sell is one transaction, and the token contract can veto it
When you tap sell, the bot builds a swap transaction that sends your tokens to a router and receives SOL or ETH back. The router then calls the token contract's transfer function. That call is the gate. If the contract allows the transfer, the swap settles and your wallet balance changes. If the contract reverts, the whole swap fails. The tokens stay in your wallet, and the bot shows a failed transaction or a repeated error. Nothing moves in a failed swap.
An exit order is only a scheduled sell
A take-profit, stop-loss or auto-sell order does not sit inside the token contract. It is a sell transaction the bot schedules to fire when a price condition is met. If transfers are blocked, the order fires, the contract reverts, and the position stays open. Auto-sell protects you against a price that turns, not against a contract that refuses the transfer. That is why the exit has to be checked before you buy, not configured after.
Why the token still looks alive
Several things make a honeypot look normal:
- The chart shows a price. The liquidity pool exists and buys keep landing, so the chart updates. A price is not proof that a sell will work.
- A small buy succeeds. Buys are the part the contract allows.
- A sell from a fresh wallet sometimes works. A blacklist is applied per address, so a wallet that was never flagged can sell while yours cannot.
- Failed sells still cost network fees on chains where the transaction is submitted.
What a bot can and cannot do
GMGN lists Auto-sell / TP-SL as a feature, alongside sniping, copy trading and limit orders, and its docs state a 1% Solana trade fee. Those tools fire a sell on your behalf with speed. None of them can make a contract accept a transfer it is built to reject. The bot is the hand that presses sell; the contract decides whether the sell goes through.
How to check a token before you buy through a bot
The check happens before the bot builds a transaction, on the token contract itself. Open the token address in a block explorer such as Etherscan, Basescan or Solscan and read the contract, not the chart.
Read the contract, starting with verification
If the source code is not verified, stop there. Unverified code can do anything and you cannot read the sell rules. On a verified contract, open the Read and Write tabs and see which functions the owner can call.
Functions that control selling
Names differ between tokens, but the pattern repeats:
blacklist,ban,setBlacklist,addToBlacklist: addresses that cannot transfer.tradingEnabled,tradingOpen,enableTrading: a switch that can be off, or turned off later.whitelist,excludeFromFee,isExcludedFromFee: addresses that bypass rules the rest of the market follows.setTaxes,updateSellTax,setFees: a sell tax that can change after your buy.maxTxAmount,maxWallet: limits that can block a sell larger than the cap.
Then check ownership. If the owner is a wallet rather than a renounced (zero) address, that wallet can usually call those functions.
Renounced ownership is not proof of safety
A renounced owner only means the deploy function cannot be called again. A privileged address can still be excluded from fees or whitelisted, and a separate contract the owner controls can hold the rules. Read who is excluded, not just who owns.
Holder distribution and liquidity
A deployer wallet that still holds a large share of supply, combined with a sell restriction, is the classic setup. A liquidity lock or burn is a check on the pool, not on the token's transfer rules. It does not make a token sellable.
What each check proves
| Check | What it tells you | What it does not tell you |
|---|---|---|
| Verified source code | The sell rules can be read | That the rules will stay the same |
| Owner address | Who can call the privileged functions | That a renounced owner removed every restriction |
| Liquidity lock or burn | The pool cannot be pulled today | That the token transfers freely |
| Test sell from your wallet | The contract accepts a sell right now | That it will accept one tomorrow |
The test sell is the clearest proof
Send a small buy and immediately try to sell the whole amount. If the sell fails, stop. Do not send more funds to "activate" trading or to "unlock" the token. Test from the wallet you plan to trade with: blacklists apply per address, so a sell from a different wallet is weaker evidence.
Honeypot checkers are a heuristic
A honeypot token checker can spot known patterns and simulate a sell against the current rules. It cannot know whether the owner will switch a rule on later. A pass is one signal, not proof. No bot setting changes what the contract allows.
Red flags in the token, not in the bot
A bot cannot make a bad contract good. When a trade goes wrong, the useful question is what the token contract lets its owner do, not which bot signed the transaction.
Switches the owner still holds
If the contract has a trading switch, the owner can pause buying and selling whenever they like, including an hour or a day after launch when the chart looks healthy. A pause that lands after you bought leaves you holding a position with no way out. Read the contract for functions named like pause, enableTrading, setTradingOpen or tradingEnabled.
Taxes that change after your buy
A sell tax that is set at launch is visible. A setter function is not. Look for a function that lets the owner change the sell tax, the buy tax or the transfer fee to any value. The rate you checked before buying can be replaced before you sell.
Renounced ownership with a hidden role
Renouncing ownership means little if another privileged role still exists: a separate role mapping that grants mint or burn rights, a proxy admin who can swap the implementation, or a minter who can change balances. Check the contract's roles and the proxy admin slot, not only the owner field.
Anti-bot rules that shrink the exit
Restrictions presented as anti-bot protection are also restrictions on you: a cooldown between transfers, a per-wallet holding cap, or a maximum sell size that drops after launch. Each one limits how much you can actually sell.
The social layer around the contract
Treat the source of the contract address as part of the risk. Warning signs:
- The address comes from an account created the same day.
- The token only appears in call channels, with no other presence.
- A buy button is pushed at you in a group.
Only use the Telegram handle published on the bot's own website. Fake bots impersonate real ones and take deposits.
Bot choice reduces speed and execution risk, not contract risk.
What to do when you are already stuck
Start with the hard part: if the token contract blocks transfers, no on-chain action forces a sell. There is no button, tool or setting that makes the contract accept a transfer it is written to reject. The tokens stay in the wallet, and the money spent on them is gone.
Revoking approvals does not unlock the token
Revoking token approvals removes permission for a contract or spender to move your tokens. It does not change the token's own transfer rules, so it will not free a honeypot position. Do it anyway, as routine wallet hygiene, then move on.
Changing bots, wallets or settings changes nothing
Switching to another bot, raising slippage, using a different RPC or importing the wallet elsewhere gives the same result. The limit sits in the token contract, not in the tool that sends the transaction. A second buy to "activate trading" or "average down" only adds funds to a position you cannot exit.
Recovery offers are a second scam
Anyone who contacts you promising to unlock a stuck token, recover funds for an upfront fee, or asking for a seed phrase or private key is running a second scam on top of the first. Never share a seed phrase with anyone, including a bot that looks official. Legitimate recovery does not exist for a contract that refuses transfers.
What is left to do
- The wallet still works for other assets. Treat the stuck position as lost rather than something to trade around.
- Record the contract address so the same token is not bought again from another wallet.
- Run the pre-buy checks on the next trade, and test the sell before sizing up.
A token position can lose all of the money put in. This is not financial advice.
Choosing a bot that gives you an exit
The useful criterion is simple: pick a bot that lets you set a limit order, an auto-sell or a take-profit before or immediately after the buy. The exit is then defined while the entry is still fresh, instead of being improvised when the price has already moved. Bots with limit order support are grouped on /feature/limit-orders.
What an exit order can and cannot do
An auto-sell or take-profit order is a sell transaction the bot builds and signs when your trigger is hit. It does not make the token transferable. If the contract blocks transfers, the order fires and fails like any other sell. So set the exit, then run the small test sell described earlier. A bot gives you the tool to exit; only the contract decides whether the tool works.
Bots with sourced exit tools
| Bot | Exit tools | Chains | Trade fee |
|---|---|---|---|
| GMGN | Auto-sell / TP-SL, limit orders, sniping, copy trading | Solana, BNB Chain, Ethereum, Tron | Solana 1%, per GMGN's fee docs |
| Banana Gun | Sniping, limit orders | Ethereum, Solana, BNB Chain, Base | Ethereum 0.5%, Ethereum snipe 1%, per bananagun.io |
| MevX | Limit orders, copy trading, MEV protection | Solana, Ethereum, BNB Chain, Base, Tron, Sui, Avalanche | Not published in its docs |
| Sigma | Sniping, limit orders, copy trading | Ethereum, Base, Avalanche, BNB Chain, Unichain, Solana | Solana 0%, other five chains 1%, per Sigma's fee docs |
Banana Gun's snipe fee is worth knowing before you use it for a new pair: sniping and a cheap trade are not the same order.
MEV protection is a separate problem
MevX lists MEV protection, and it matters at entry and exit on the chains where it is offered. It addresses front-running and sandwiching, where another party reorders your transaction for profit. That is a different failure from a contract that refuses to transfer your tokens, and MEV protection does not make a honeypot sellable. Treat it as execution quality, not as a safety check on the token.
Browse by chain, then set the exit
Bots differ by chain, so start with /chain/solana if you trade Solana pairs, or /bots for the full list. Choose one that lets you place the exit before you buy, and keep the test sell in your routine.
When you have two candidates, put Banana Gun and GMGN side by side before you choose the bot you trade new pairs through.
Frequently asked questions
Can a Telegram trading bot tell me if a token is a honeypot?
A bot sends the trade you confirm. It does not read a token's contract for you, so a honeypot check is a separate job. Open the token on a block explorer, read the verified source for functions that block transfers, blacklist addresses or pause trading, and check whether the owner keeps special rights over the contract. Then test the sell path: a simulation that buys and immediately sells in one transaction shows whether the token can be sold at all. Keep the first real trade small.
Why did my buy go through but my sell keeps failing?
A buy that fills and a sell that keeps failing is the classic honeypot pattern, but not the only cause. The contract may block sells above a wallet size limit, apply a cooldown, charge a sell fee close to the whole amount, or allow trading only for the owner's addresses. It can also be liquidity: the pool has no room for your size at your slippage setting. Open the failed transaction on a block explorer to see whether it reverted on the token transfer or on the price check. Failed transactions still cost network fees.
Does revoking approvals free a honeypot token?
Revoking an approval only withdraws a contract's permission to move your tokens. It does not change the token's code, so it cannot make a blocked sell work. In a honeypot the block sits inside the token contract: the transfer reverts, or the sell routes most of the value into a fee wallet. Revoking is still worth doing after you touch an unfamiliar contract, because it limits what that contract can do with your balance later. To sell you have to approve again, which is why revoking is not an escape route.
How can I test a token before buying a large position?
Buy the smallest amount the pool accepts, sell it straight away, and compare what you receive with the quote you were shown. That single round trip exposes a blocked sell, an extreme sell tax and thin liquidity. Before that, read the contract on a block explorer and look at holder concentration. Budget for the cost: a round trip pays network fees twice plus the bot's trade fee, for example Bloom's fee docs state a 1% trade fee on every supported chain. Scale up only after the small sell settles.
Is a honeypot the same as a rug pull?
No. A honeypot is a token contract built so buys succeed and sells fail, trapping money already inside. A rug pull is an exit: the people behind a token remove liquidity, dump a large supply or abandon the project, and the price collapses for everyone holding. One is a mechanism in the code, the other is an action taken by the team. A token can do both. Either way, money put into a memecoin can be lost in full, and a price that has already fallen is not automatically a discount.