How Telegram Bots Hide Malicious Contracts

What a hidden contract actually is

The bot screen shows a token name, a price and a Confirm button. The transaction your wallet actually asks you to sign is a call to a contract address the bot picked and never displayed. Those are two different things, and the gap between them is where a hidden contract lives.

Two layers in one screen

Every trade through a Telegram bot involves two layers:

• The token. The asset you think you are buying, identified by a ticker and a pair.
• The contract your wallet is told to call. Usually a router, a spender, or a batch executor that moves funds on your behalf. This is the address that receives your approval and your money.

A token can be fine and the contract underneath still be wrong. The reverse is also true.

The bot is a remote control

You are not trading from your phone. The bot builds the transaction off screen, on its own servers, and hands it to your wallet to sign. Your wallet is the only place the target address appears before you approve it. Everything you saw in the Telegram chat, the token name, the price, the confirmation message, was written by the bot's interface, not by the chain.

So the concealment is not a hack of your device. Nothing has to be infected. It is simply a gap between what the bot's display says and what the payload contains.

Verify the address, not the ticker

The habit that protects you is checking the contract address your wallet names, not the token symbol the bot shows. Two different tokens can share a ticker. A router address can be swapped for another.

A bad token, one you cannot sell or that taxes every transfer, is a separate failure mode, covered further down.

Trading memecoins can lose all of the money you put in.

The signature you give, not the token you buy

A trade inside a Telegram bot feels like one action: you type an amount, tap Confirm, and a token appears in your wallet. On chain it is usually two actions, and only one of them is about the token you wanted. The other is about who you let near your balance.

Two things you can sign

• An approval or a permit. It grants a spender address the right to move a token out of your wallet. It does not move anything by itself.
• The swap. A call to a router contract that exchanges one token for another.

Both are signatures from you. They point at different addresses, and each one deserves its own look.

What an allowance actually is

An allowance is a number stored on chain. In plain words: this address may move up to this much of my token. It is a standing permission, not a transfer. Nothing leaves your wallet at the moment you approve. That is exactly why an approval can sit quietly for months and still matter.

Why unlimited approvals are common

Most bot flows ask for the maximum once, so you do not have to approve again before every trade. It saves a step and a confirmation screen on each buy. The cost is that the permission stays open at full size until you change it or revoke it.

Permit signatures

Some flows use a permit: a signed message instead of a transaction. It costs no gas and can look like a harmless login prompt. It can still grant a spending right, so treat a permit request with the same care as a transaction. Check what it authorises and when it stops being valid.

The sequence to expect

1. An approval of your token to a spender address.
2. A swap call to a router address.

Two targets to check, not one. If a bot shows only a token name and a price, the two addresses are the part you are not seeing.

An approval with no swap attached is still a completed grant. If the swap reverts, or you close the bot mid-flow, the allowance remains.

Finally, keep the two questions apart. A token can be sound and the approval terms bad. A token can be bad and the approval terms ordinary. Checking the token tells you nothing about the spender, and checking the spender tells you nothing about the token.

Four ways a bot can conceal the contract it calls

A bot's messages show a token, a quote and a Confirm button. The transaction it builds calls a contract you never see in the chat. There are several standard ways that contract stays out of view.

1. A router address that differs from the documentation

The bot's docs name a router contract. The live trade calls a different address. To check, take the address from the documentation and open your swap transaction on a block explorer, then read the contract the wallet actually interacted with. If they do not match, either the docs are stale or the router changed without notice.

On the explorer: the "interacted with" address on the swap does not equal the router address in the docs.

2. The proxy pattern: same address, different code behind it

A proxy contract is a fixed address that forwards to a separate implementation contract. The address stays the same while an admin swaps the code behind it. An address that looked clean last month can behave differently today, and the explorer will still show the same familiar string. Read the contract page and look for a proxy label and the implementation address it points to. If that implementation address has changed since you last checked, the behaviour may have changed with it.

On the explorer: a "proxy" tag on the contract page, and an implementation address that is not the one you reviewed.

3. A fresh contract per user

Some bots deploy a separate contract for every user. Your trade routes through an address created for you, with no history, no shared behaviour and nothing to compare against a published address. This is why "there is no contract address in the docs" is a warning sign: without a named address, you cannot verify what you are signing, and no one else can check the same target.

On the explorer: the contract you called was deployed days or hours ago, by another contract, and its transaction history is almost entirely your own wallet.

4. A router chosen at trade time

Some bots select a routing contract when the trade is built, sometimes from a list of candidates. The same button produces a different target on different days, which makes a single verified address meaningless.

On the explorer: two identical trades from your wallet show two different target contracts.

5. Batched calls

A multicall bundles several actions into one transaction: the swap is the headline, while an approval or a transfer sits further down the list.

On the explorer: the method reads "multicall" or similar, and the decoded input contains more than one call. Read every entry, not just the first.

Legitimate bots use all five patterns for legitimate reasons: upgrades, gas savings, per-user accounting. The problem is disclosure, not the technique. A bot that names its router and explains when it changes is doing the thing that lets you check.

Reading the confirmation screen before you tap

The wallet popup is the last place where the transaction is described by something other than the bot. Read it as a separate document, because that is what it is.

What the screen is telling you

• Contract interaction. The wallet is calling a contract, not sending a payment to a person. The label is generic; the address underneath it is the part that matters.
• Spender or recipient. For an approval, this is the contract allowed to move your tokens. For a swap, it is the router. Note it down and compare it on a block explorer afterwards.
• Amount. An unlimited approval usually appears as "Unlimited" or as a very long number (2^256-1). It grants spending of that token until you revoke it. Pause before signing one for a bot you have not checked.
• Network. A trade signed on the wrong chain sends funds somewhere other than where you meant them to go.
• Fee estimate. A rough cost of the transaction itself, not the bot's trading fee.

Details that are easy to skim past

A truncated address in the middle of the screen is easy to glance over. Read the first four and last four characters and hold them against the address you expect.

The wallet shows an address, not a reputation. It has no way to tell you whether that address is honest.

The token symbol comes from the token contract and can be set to anything. A token called USDC or ETH tells you nothing about the contract behind it.

Before you tap

Four things to confirm:

1. The spender or router address matches the one in the bot's documentation.
2. The amount is what you meant to approve, and whether it is unlimited.
3. The network is the chain you chose.
4. The action matches what the bot said it would do.

If any of these does not match, reject the prompt. Rejecting costs nothing; a signed approval stays in place until you revoke it.

Checking the contract on a block explorer

The bot's screen and your wallet's confirmation both sit in front of the chain. The explorer sits on it. Whatever a bot displays, the transaction it sent is public, and that is where you check the contract you actually dealt with.

Open the transaction

Take the hash from your wallet's activity list, or from the bot's message if it shows one, and paste it into the explorer for the right chain: Solscan for Solana, Etherscan for Ethereum, BscScan for BNB Chain, Basescan for Base. Read the "interacted with" or "to" address, then compare it with the address the bot publishes, character for character. Do not compare labels. A tag like "Router" is set by the explorer or a third party and can be wrong, copied or attached to an address that only looks familiar.

What each screen shows for the same trade

The spender matters as much as the target

Open the token transfer lines inside the transaction. If one is an approval, note the spender address: that is the contract allowed to move your token later. Open the spender's own page and read what it is. A verified contract with published source code, an unverified contract, or a plain wallet address that has no business spending your tokens.

Worked example: an approval, then a swap

1. An approval transaction appears first. Open it and read the spender address. That is the address the bot will use to move your token.
2. The swap transaction follows. Open it and read the router, program or contract address it called, plus the amount that moved.
3. Compare both addresses with the ones the bot publishes in its documentation or channel. If the spender or the router is not the published one, you are not looking at the bot's stated setup.

The explorer records what happened, not whether it was safe

It shows which address was called, which token moved and how much. It will not tell you the address is friendly. A verified contract only means the source code matches the deployed bytecode; harmless code and hostile code can both be verified. Nothing on the page warns you that a router was swapped or that a contract can move funds you approved earlier.

Keep the addresses you verified

Write down the router, the spender and the token contract once you have checked them. On the next trade, compare the new transaction against that list. If an address changes and the bot's documentation has not, stop before you sign.

Malicious contract versus honeypot token versus fake bot

Three different failures get called "a scam bot", and each needs a different response. In all three, the thing that harms you sits somewhere other than the chat window.

Malicious contract or spender

Here the token can be perfectly ordinary. The contract you approve holds an allowance over your balance, and it can use that allowance later, in a transaction you never see. The bot screen shows a trade; the chain records an approval to an address you did not choose.

Ask: which address did my wallet approve, and do I recognise it?

Honeypot token

The trap is inside the token contract: transfer rules that stop a sale or take a cut on the way out. The bot routes exactly as it says; the asset itself is built to keep you in. That failure belongs with token checks, a separate subject from the bot's routing.

Ask: can a wallet that bought this token actually sell it?

Fake bot

An impersonator account copies the real bot's name and logo, with a handle changed by a character or two. It asks for a seed phrase, or sends a confirmation screen that leads to a contract nobody published. Only the handle listed on the bot's own website is the real one, and no bot needs your seed phrase. Never share it with anyone.

Ask: did I open this bot from the project's own website?

The overlap

A fake bot usually ends in a bad contract, because getting you to sign is the impersonator's whole job. If you cannot place your situation, treat it as the contract case and check the approval first.

Compare which bots publish their contract addresses and safety features before you approve anything.

Limiting the damage before anything goes wrong

You cannot audit every contract you touch. You can decide in advance how much a bad one is able to take.

Trade from a wallet that only trades

Keep one wallet for bot trading and fund it with only the balance you are willing to trade from. Leave long term holdings in a different wallet that never connects to a bot, never signs an approval and never imports a key into a chat. If an approval turns out to be malicious, the loss stops at the trading balance.

Read the amount field

Where the flow lets you set an approval amount, set it to what the trade needs instead of accepting the default. An unlimited approval is the difference between losing the tokens you meant to swap and losing the whole balance of that token. The confirmation screen shows the amount; read it before you tap.

Revoking stops future spending, not a past transfer

Revocations are made in your wallet, or with a revoke tool on the same chain as the approval. Revoking removes the allowance, so the spender cannot move that token again. It does not reverse a transfer that has already happened. If funds left the wallet, revoking is cleanup, not recovery.

Check the handle every time you reopen the chat

Impersonator bots are common, and a saved chat can be replaced by a copy with a similar name. Compare the handle against the bot's own website each time, not once. Sourced examples: Banana Gun is @BananaGun_bot, GMGN is @GMGN_sol_bot and Maestro is @maestro.

Prefer bots that document their safety features

• GMGN lists auto-sell and take-profit / stop-loss.
• MevX lists MEV protection.
• Banana Gun covers Ethereum and Solana.
• Maestro covers many chains, from Solana and Ethereum to TON and Tron.

None of these steps make a bad contract safe. They bound what it can cost you when one gets through.

What a bot that publishes its contracts looks like

The practical test is simple: can you find the address the bot calls, written out as text you can copy, and compare it with the address on your wallet screen?

Addresses, chain by chain

Useful documentation names the router contract and any helper contracts a bot uses, separately for each chain it supports, with the chain labelled and a block explorer link beside each address. Copyable text matters. An image of an address, or a screenshot of an explorer tab, cannot be pasted into a search field when your wallet shows an unfamiliar contract.

A page that lists only features (sniping, copy trading, limit orders) is a different document. Features describe what a bot does; addresses describe what it touches. The first list tells you nothing at the moment you need it.

Audits, as one signal

A named auditor with a link to a published report is worth having. Treat it as one signal among several, not a clean bill of health: an audit covers the code it reviewed, at the time it reviewed it, and cannot vouch for the address asking for your approval today.

A stated fee page

A bot that sets out its fees in plain text is at least telling you what it takes. A published fee page belongs to the same habit as published addresses: the numbers that affect you are written down rather than discovered later.

Examples

• GMGN publishes fee and feature documentation and lists auto-sell / TP-SL.
• Maestro documents multi-chain coverage across the chains a reader is likely to trade.
• Banana Gun documents Ethereum and Solana in its own material.
• MevX documents MEV protection as a feature.

Compare which bots publish their contract addresses and safety features before you approve anything. See the full bot list side by side on /bots and pick one whose documentation you can actually verify. If you trade on one chain, start with the /chain/solana and /chain/ethereum lists.

Frequently asked questions

Can a Telegram bot drain my wallet without me approving anything?

It depends on what you gave the bot. If you imported a private key or seed phrase into a bot, that bot can sign and send transfers without a wallet confirmation each time, so it can move funds without a fresh approval. If you only granted token allowances, the bot can spend up to the allowance, not the whole wallet. A bot cannot drain a wallet that never shared a key or approval. Use only the official bot handle from the bot's own website, because impersonator bots are common. Review token approvals regularly and remove the ones you no longer use.

How do I find the contract a bot called during my trade?

Copy the transaction hash from your wallet or bot message, then open it in a block explorer for that chain. On EVM chains, check the "To" address, the logs and the internal transactions. The token transfer often comes from a router or aggregator, not the token contract itself. On Solana, open the transaction in Solscan and read the program instructions to see which program IDs were invoked. Save the hash before you trade again. Compare the spender or program ID with the token and bot you intended to use.

What is the difference between a malicious contract and a honeypot token?

A malicious contract is broader: it can be a router, approval spender or proxy that takes funds or permissions in ways you did not intend. A honeypot token is a specific trap in a token contract: buying may work, but selling is blocked, limited or taxed heavily. A honeypot is one possible malicious token, while a malicious contract may never issue a tradeable token at all. For tokens, check whether sells work and whether owner powers can change taxes. For contracts, check which address gets your approval and what functions it can call.

Does revoking an approval undo a transfer that already happened?

No. Revoking an approval stops future token pulls under that allowance. It does not reverse a transaction that is already confirmed on-chain. Once funds have moved to another address, only the recipient can send them back. Revoke any remaining approvals, move leftover assets to a fresh wallet and keep the transaction hash. If the transfer came from a key you imported into a bot, treat that key as exposed and stop using it. Check every chain where you granted approvals, because revoking on one chain does nothing on another.

Why does the bot's contract address not appear in its documentation?

Documentation usually covers commands, fees and supported chains, not every router, aggregator or program the bot calls. Those addresses can change when a bot upgrades routing or deploys on another chain, and some bots rely on third-party contracts. An omitted address is not proof of malice, but it does mean you cannot compare a documented address with the one your wallet shows. Before signing, read the spender or program ID in the explorer and confirm it matches the token and route you intended to use. Treat any request for a seed phrase as a stop sign.

Is an audited bot protected from a malicious contract?

No. An audit usually covers specific bot code at a point in time. It may not cover every external router, aggregator, token contract or later upgrade the bot interacts with. A clean audit can sit alongside a malicious token or a dangerous approval. Treat audits as one signal, not a shield. Simulate the transaction, read the spender or program ID, revoke approvals you no longer need and keep only trading funds in a hot wallet. If the bot holds your private key, an audit does not remove that custody risk.