How to Check a Telegram Bot's Smart Contract
How to tell a bot's router, its deposit address and the token contract apart, and check each one on the explorer before you approve or deposit.
Published 2026-11-09
Three addresses people mix up
A trader opens an explorer with a bot's name in mind and pastes in an address. Often it is the wrong one. Three different things get called "the bot's contract":
- The router, or program. The contract the bot calls to execute a trade on your behalf. It is the same for every user. Once you approve it, it holds whatever allowance you granted.
- Your deposit address. The address the bot generates for you personally, where you send funds before trading. It holds the money you have handed to the bot, not your approval.
- The token contract. The coin you are buying or selling. It defines the asset and belongs to that token's team, not to the bot's team.
This article checks the first two: the router you approve and the deposit address you fund. Token-level questions are a separate job with a separate method. A honeypot check, a transfer tax reading or a Solana freeze authority check each need their own steps, and doing them on the router tells you nothing about the coin.
There is a fourth address people paste: a wallet address, usually one posted by a "support" account in a chat. That is not a contract. There is no code, no functions and nothing on the explorer to read. Treat any message that offers a support wallet as a reason to close the chat.
The rule for everything below is simple. An address means nothing on its own. It means something only when it matches the address the bot's own documentation publishes, character for character.
This is a five-minute check, not a certificate of safety. The aim is narrower and more useful: to know exactly what you are approving, and to whom.
What each address actually controls
| Address | Who it belongs to | What it holds |
|---|---|---|
| Router or program | The bot, shared by all users | Your token approval and the trades it can make with it |
| Deposit address | You, generated by the bot | The funds you send to trade with |
| Token contract | The token's own team | The asset itself: supply, taxes, mint and freeze rules |
| "Support" wallet from a chat | Nobody you can identify | Nothing to read. Do not send funds |
Get the address from the bot's own documentation, not from a chat
The address is only as good as the page you copied it from. Keep the chain of custody intact: the bot's website first, the documentation linked from that site second, the address on that documentation page third. Anything that skips a step in that chain is a weaker source.
Follow the documentation link from the bot's own domain
Open the bot's website yourself, find the link to its documentation, and follow it from there. The page you land on should sit on the project's own docs domain. Copy the contract address or program ID from that page, character for character, and keep the tab open.
Why chat is the wrong source
A pinned message can be edited. A group admin can be an impostor. A forwarded screenshot can be altered, and a DM offering "support" can come from anyone. An impersonator bot can copy a name, a logo and even the layout of a docs page closely enough to fool a quick glance. Chat is where address swaps spread, not where you confirm one.
Cross-check the handle in the documentation
Before you copy anything, look at the Telegram handle the documentation names and compare it with the bot in your chat list. If the handle differs by even one character from the one you are messaging, stop and start again from the website.
| Bot | Official handle | Page |
|---|---|---|
| Banana Gun | @BananaGun_bot | /bot/banana-gun |
| Maestro | @maestro | /bot/maestro |
| Sigma | @Sigma_buyBot | /bot/sigma |
| Trojan | @solana_trojanbot | /bot/trojan |
| BONKbot | @bonkbot_bot | /bot/bonkbot |
Bots with documentation you can check against
Several bots publish enough detail on their own sites to make an address comparison possible: Banana Gun, Bloom, BONKbot, GMGN, Maestro, Pepeboost, Sigma, Trojan and Unibot. The pages above are a starting point, and /bots lists the full set.
Some bots publish no contract details at all. That is simply a fact about their documentation: there is nothing on the page to hold next to the explorer. Treat it as a missing check, not a substitute for one.
The working habit
Documentation tab on one side, block explorer tab on the other, the address compared in both, and only then an approval or a deposit. Keep that layout in place every time you return to the bot.
EVM contract address versus Solana program ID
On EVM chains the address holds the code
An EVM contract address is 0x followed by 40 hexadecimal characters. The bytecode sits at that address, and everything else is read from it: balances, events, function calls.
Etherscan and its chain equivalents let a deployer publish the source code behind that bytecode. The explorer then compiles the published source and compares the output to the bytecode actually deployed. When the two match, the contract is marked verified. That comparison, and only that comparison, is what "verified" means: the code you are reading is the code that runs.
On Solana the program ID points somewhere else
A Solana program ID is a base58 public key. The executable code is not stored inside that account. It lives in a separate program data account, and the program account points to it. There is no EVM-style verified source badge to look for on Solscan.
What you can read is the program account's upgrade authority field and the address holding it. If the field is set, that key can replace the program's code later, after you have already sent funds. If the field is empty, the program can no longer be changed.
The approval model differs too
On EVM chains, a bot normally asks for an ERC-20 allowance per token, and you sign that approval in your own wallet. On Solana, bots more often give you a deposit address to send funds to, with token account delegates in between. The check moves accordingly: on EVM you inspect the contract that will spend your allowance, on Solana you inspect the program and the wallet that receives your deposit.
| What to check | EVM chains | Solana |
|---|---|---|
| Address format | 0x plus 40 hex characters | base58 public key (program ID) |
| Source verification | Explorer compiles the published source and matches it to the deployed bytecode | No verified source badge; read the program account and its program data account |
| Upgrade control | Proxy admin or implementation slot; find who can upgrade | Upgrade authority field on the program account, and who holds it |
| Approval model | ERC-20 allowance per token, signed by you | Funds sent to a deposit address, with token account delegates |
| Explorer used | Etherscan and its chain equivalents | Solscan |
The practical result: a "verified contract" link proves something useful on EVM and proves nothing on Solana, where the question is who holds upgrade authority over the program.
Read the contract page on the explorer
The explorer page answers one question: what is this contract, and who can change it? Read it in a fixed order so you do not stop at the first green badge.
The verified badge is a starting point
A verified source on Etherscan, Basescan or Solscan means the published code compiles to the bytecode deployed at that address. It means nothing else. It does not say who controls the contract, whether the functions are safe, or whether the team can move your tokens. Verification is a match, not an endorsement.
Deployer and first transaction
Open the deployer address and the date of the contract's first transaction. A router deployed days before a large launch announcement deserves a second look: real infrastructure usually predates the marketing. Note whether the deployer wallet is still active and what else it has deployed.
The source tab
Read the contract name, the compiler version and the imports. An odd name, a copied library, or code that imports a second contract you have not opened is a prompt to keep reading. It is not a verdict on its own.
Write functions, and who may call them
Go to the write tab and sort the functions into two groups: anyone can call, and owner only. These are the ones that decide how much power sits with the team:
pauseorenableTradingblacklistsetFeeRecipientorsetTaxsweeporwithdrawtransferOwnership
If a single function can move token balances out of the contract, find out who may call it.
Owner: a wallet or a contract
Check the owner address. If it is a plain wallet, one private key controls those functions. If it is a contract, open it: a multisig or a timelock spreads or delays that control. A single wallet with sweeping rights is the risk worth naming.
Ignore the token balance
The token balance shown on a router page reflects what sits in the contract at that moment, not what the contract can do to your funds. A full router and an empty one can carry identical code.
Keep the bot's documentation page open in one tab and the explorer in the other, and check the address before you approve anything.
The functions that decide how much power the bot holds
The spender in an approval
When you approve a token, you name one address that may move up to a set amount of that token from your wallet. That address is the spender, and for a Telegram trading bot it is normally the bot's router. Everything the contract can do afterwards starts from that permission, so it is worth reading the code before you grant it.
What to search in the source
Open the verified source on the explorer and search for transferFrom. Then follow every function that calls it. You want to confirm two things: the amount moved comes from the allowance you granted, and the destination is a swap target used to execute a trade. If transferFrom can be called with an amount or a recipient you never set, the approval means more than "trade this much of this token".
Owner-only functions worth naming
Scan the contract for functions restricted to the owner or admin address. The ones that matter most:
- Pause trading, which can strand funds mid-trade.
- Blacklist an address, which can block your wallet from selling.
- Change the fee recipient, which redirects the fee you pay.
- Change the router or swap target, which alters where your tokens are sent.
- Rescue or sweep tokens, which can move balances out of the contract.
Any of these is a lever someone holds over your position. Some are normal maintenance. Read who holds them and how they are called.
Your approved tokens versus everyone's balance
A contract that moves only what each user approved is bounded by those approvals. A contract that can move balances held inside it, for any user, is a different kind of power: one address can reach funds that were never approved to it. That design needs a strong, stated reason to exist before you deposit.
Where the fee goes
Find the fee calculation and the address that receives it. Then check whether that address is hardcoded or set by an owner function. A fee recipient that can change without notice means the number you read in the docs is not the whole story.
If you cannot read Solidity
Three checks cover most of the ground: the source is verified on the explorer, the owner is not a single wallet, and the address matches the one in the bot's documentation. If any of the three fails, do not approve.
Proxy contracts and upgrade authority
A proxy contract separates the address from the code. You approve one fixed address, and that address points at a separate implementation contract that does the actual work. The team can swap the implementation later and the address you approved stays exactly the same. This is normal engineering, not a trick, but it means "I checked the contract" describes a moment, not a permanent state.
The two slots that matter
On EVM chains, both values live in known storage slots:
- Implementation slot
0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbcholds the address of the contract that currently runs. - Admin slot
0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103holds the address allowed to change it.
Read them and you know which code is live and who can replace it. Note the admin address: if it is a plain wallet rather than a timelock or multisig, one key controls the contract you approved.
On the explorer
Etherscan and its equivalents tag proxy contracts with a "Proxy" label on the contract page and show the current implementation address next to it. Two tabs, "Read as Proxy" and "Write as Proxy", show the functions of the implementation contract rather than the proxy shell. Use them when you want to see what the live code can actually do.
On Solana
There is no proxy pattern, but there is the same risk in a different shape. Open the program account page and look for the upgrade authority. If an authority is set, the program can be replaced with new code; if it has been cleared, it cannot.
Why the check has a shelf life
An upgrade after your approval changes what your approval can do. The address is unchanged, so nothing on your side looks different.
The habit
Re-check the implementation and upgrade authority after any upgrade announcement, and revoke approvals you no longer need.
A worked example: find the spender in an approval
Say you approved a token to a bot yesterday and now want to know exactly what you allowed. The approval is not hidden inside the bot: it is a log on a public transaction, and it names the address that can move your tokens.
Open the transaction, then its logs
Find the approval transaction in your wallet's history and open it on the explorer for that chain. Switch to the logs view. Each log carries a topic 0 identifier for its event type. An ERC-20 approval uses:
0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925
Read the three values
The Approval event writes three things:
| Field | What it holds |
|---|---|
| owner | Your wallet address, the one whose tokens are being approved |
| spender | The address allowed to move those tokens |
| value | How many tokens the spender may move |
The spender is the field you care about. Copy it.
Open the spender, then compare it with the docs
Paste the spender address into the same explorer. You land on an address page, and if it is a contract you will see a contract name and whether the source code is verified. Read the name, then take the full address, character for character, and compare it to the router address in the bot's documentation. Check the first four and last four characters, then the middle. A match is the entire point of the exercise: it confirms that the address which gained power over your tokens is the one the bot publishes.
Read the amount
If the value is the maximum number the token contract allows, the explorer shows it as unlimited. An unlimited approval lets the spender move that token from your wallet at any time until you revoke it, so it is worth knowing which tokens you have approved that way.
The Solana equivalent
Solana has no ERC-20 approval, so the same question has a different answer. Open your token account on Solscan and read the delegate field: it names the address allowed to move that token balance. Compare the delegate to the program ID in the bot's documentation, the same way you compared the spender to the router.
Match the address you interact with to the address you verified
Two address patterns show up in every Telegram bot, and they are checked in different ways.
The router: one address for everyone
The router (or the Solana program) is the same contract for every user of the bot. That makes the check simple: verify it once against the bot's documentation, then confirm the address the bot asks you to approve is character for character the same.
Bots with public docs, such as Maestro, Banana Gun or BONKbot, give you something to compare against. A router address copied from a chat message gives you nothing.
The deposit address: yours alone
The deposit address is yours. It should differ from every other user's, and it is where funds sit until the bot trades them. Check it in the bot's own interface against what you actually sent: same address, same chain, same amount.
That address can be one of two things:
- A contract the bot controls. Read its functions on the explorer before sending anything, especially anything that can move funds out.
- A plain wallet. Whoever holds its private key holds your money while it sits there. Most Telegram bots are custodial in exactly this way, and a bot holding a private key can lose the funds it holds.
When the addresses disagree
If the docs list one router and the bot asks you to approve a different one, stop and ask before approving. Rotations happen legitimately: a new router published in the docs is checkable, a "new router" announced only inside the chat is not.
Finally, a seed phrase never belongs in any bot chat, whatever the addresses say.
Red flags, and bots that publish nothing to check
The flags worth stopping for
- Unverified code. The explorer shows bytecode with no matching source, so nobody outside the team can see what the contract does.
- A contract deployed days before the launch announcement. Brand new code has had no time in public, and you cannot tell a fresh deployment from a replacement for one that was already used.
- A single address that can move user funds. If one wallet can sweep balances or change who receives tokens, your funds depend on whoever holds that key.
- An address that does not match the docs. A mismatch means one of the two is wrong, and the explorer is the one to trust.
- A "new router" announced only inside the chat. An address that appears first in a Telegram message has no second source to confirm it.
- "Support" asking you to approve or send funds. No legitimate support process needs a token approval or a transfer from your wallet to help you.
Each of these removes the thing you came for: a fixed, public address you can compare against.
When there is nothing to check
A bot that publishes no contract and no docs gives you nothing to verify. That is a reason to skip it, not a reason to guess, and not a reason to accept an address from a stranger who offers one.
Documentation beats a pinned message
A pinned Telegram message is not documentation. The same account can edit or delete it later, so the address you checked yesterday is not necessarily the address shown today. A docs page on the bot's own domain is the reference to hold.
Where the router matters most is sniping, because a snipe approves and spends in one step: see /feature/sniping. For chain-specific bot lists, use /chain/solana and /chain/ethereum.
Keep the bot's documentation page open in one tab and the explorer in the other, and check the address before you approve anything.
A repeatable check, chain by chain
The routine is the same on every chain. Only the explorer and the labels on the page change.
The routine
- Open the bot's own website. Follow its documentation link from there, not a link posted in a chat.
- Copy the contract address or program ID from that page and leave the tab open.
- Open the explorer for the chain: Etherscan for Ethereum, Basescan for Base, BscScan for BNB Chain, Solscan for Solana.
- On EVM, confirm the source code is verified. On Solana, confirm the program account is executable and is the one the docs name.
- Read the owner and upgrade control. Note whether a proxy, an admin or an upgrade authority can change the code later.
- Before approving, check the spender in your wallet matches the address you verified. If it does not, stop.
- Write down the address and the date you checked it.
The step people skip
Run the whole routine again after any upgrade or "new contract" announcement. The address you approved last month can run different code today, and a message inside the chat is not documentation.
When the trade is a snipe
A snipe approves and spends within seconds, so the router check has to happen before the token goes live, not after the transaction is signed. If the router is unverified when the pair opens, there is no time left to check it. See /feature/sniping.
What the routine cannot tell you
It does not tell you whether a token is a honeypot, whether a team will act honestly, or whether a trade will make money. It only tells you which contract you are dealing with and what that contract is allowed to do with your funds. Trading memecoins can lose all of the money put in.
Before you pick a bot
Put Banana Gun and Maestro side by side on /compare/banana-gun-vs-maestro and check which one publishes contract details you can actually verify. The wider list is on /bots.
The rule: an address copied from documentation and matched on the explorer is the only version worth acting on.
Frequently asked questions
How do I find a Telegram bot's contract address?
A trading bot usually has no single contract address of its own. There are two worth checking: the router or program the bot uses to execute swaps, and the token contract you plan to trade. Get both from the bot's own website: open the site, follow the link to its documentation, and copy the address from the docs page. Do not copy addresses from pinned chat messages, forwarded posts, or anyone who messages you first.
How do I confirm the contract address and bot handle are official?
Start at the bot's own website, follow the link to its documentation, and copy the address from there rather than from a chat message. Compare it character by character with what you were about to use, reading the whole string instead of just the first and last characters, which are the easiest to fake. Do the same for the Telegram handle: the username must match exactly, since impersonator bots copy display names and profile pictures. Bookmark the docs page and return to it each time rather than trusting a link someone sends you.
Is a verified contract on Etherscan safe to use?
Verification means the published source code matches the bytecode deployed at that address. It says nothing about who controls the contract, whether it can be upgraded, or what the owner can do. Open the contract's read and write functions and look for anything that can move user funds, pause withdrawals, change fees or mint tokens. Check who holds owner rights: a single wallet with broad powers is a different risk from a renounced or timelocked setup. Read the documentation alongside the code, and treat verification as a starting point, not a safety mark.