Telegram Trading Bot Autopsy: 7 Bots Audited for Contract Security (Banana Gun, Maestro, Unibot Code Review)

Why $635M in lifetime volume flows through unaudited Telegram executors—and the critical vulnerabilities draining wallets through the transferFrom exploit vector.

The Telegram Execution Layer: Convenience at the Cost of Custody

The rise of Telegram trading bots represents crypto’s most dangerous UX trade-off. By bridging the gap between social messaging and on-chain execution, bots like Maestro, Banana Gun, and Unibot have processed over $635 million in lifetime volume (per Arkham Intelligence tracking), offering retail users sub-second sniping, copy-trading, and MEV protection through simple chat commands.

The architecture is seductively simple: users connect wallets to Telegram bots, approve token spending limits, and execute trades via bot-hosted smart contracts. Yet this convenience creates a custodial honeypot—the bot’s executor contracts hold sweeping approvals over user wallets, often with unverified code, upgradeable proxies, and arbitrary transferFrom privileges that have already resulted in $2.8M+ in documented exploits.

This technical autopsy examines seven prominent Telegram trading bots through the lens of contract verification, exploit history, and privileged access patterns. The findings reveal a sector operating without standardized audits, where “anti-rug” features mask fundamental vulnerabilities in approval architecture.

The Anatomy of Vulnerability: Common Contract Patterns

Before dissecting individual bots, understand the universal attack vector plaguing Telegram executors:

The transferFrom Exploit (Selector: 0x23b872dd)

The critical vulnerability across Maestro and Unibot implementations involves arbitrary approval exploitation:

1. User approves bot executor to spend Token X (infinite allowance typical)
2. Bot contract exposes external transferFrom calls without access controls
3. Attacker calls transferFrom(victim, attacker, amount) directly on the token contract using the bot’s prior approval
4. Funds drain without user signature or transaction initiation

This pattern exploits the approval delegation model—once a user approves a bot’s executor contract, any party can invoke transfers if the contract doesn’t verify msg.sender against the original approver.

Proxy Upgrade Abuse

Multiple bots utilize transparent proxy patterns (OpenZeppelin) for “upgradeability,” creating admin key risks:

• Implementation contracts can be swapped to malicious logic
• No timelocks or multisig governance on upgrade functions
• $500K+ lost to “upgrade attacks” where benign executors were replaced with drainage logic

The Primary Autopsies: Three Critical Cases

1. Maestro: The $780K Hemorrhage

Contract Address: 0xd7d170dd009ad0de82943ea2fe8c0e8999272a98 (Ethereum Mainnet)
Chains: Ethereum, BSC, Solana, Base, Tron, TON
Exploit Loss: 280 ETH ($500K+) + secondary 106-user drain

Code Review Findings: Maestro’s platform token (MAESTRO) presents as a basic ERC-20 with unverified executor logic. The critical failure lies in the bot’s trade execution contracts (not the platform token itself), which utilize proxy patterns without implementation verification.

Vulnerability Details:

• Arbitrary TransferFrom: Executor contracts permit unauthenticated transferFrom calls via the 0x23b872dd selector, allowing attackers to drain approved wallets without bot interaction
• Proxy Upgrade Vector: Upgradeable proxy architecture enabled the implementation swap that caused the $500K ETH heist—admins replaced benign logic with drainage code
• Access Control Absence: No onlyOwner or role-based restrictions on critical token movement functions

Exploit Timeline:

• Primary Heist: $500K ETH stolen via malicious proxy upgrade
• Secondary Wave: 280 ETH drained from 106 users via the transferFrom vector
• Current Status: Post-exploit remediation unclear; users must manually revoke approvals via Revoke.cash

Risk Assessment: Critical—Unaudited executors with proven exploit history; proxy centralization creates persistent drainage risk.

2. Unibot: The Architecture of Appropriation

Contract Address: 0xf819d9cb1c2a819fd991781a822de3ca8607c3c9 (Ethereum Mainnet)
Chains: Ethereum (Uniswap-focused)
Exploit Loss: 355 ETH stolen

Code Review Findings: Unibot’s platform token (UNIBOT) is verified on Etherscan, revealing OpenZeppelin standard ERC20 with variable tax mechanics and SafeMath implementations. While the token itself shows medium risk (owner controls tax settings and burns), the executor infrastructure mirrors Maestro’s fatal flaws.

Vulnerability Details:

• Identical TransferFrom Exposure: Same transferFrom vulnerability as Maestro—executor contracts expose arbitrary spending approvals to external callers
• Variable Tax Setter: Contract owner can modify transaction taxes post-deployment, creating “soft rug” potential where fees can be set to 100%
• Privileged Functions: Owner maintains authority over LP token burns and contract pausing, though not explicitly exploited in documented incidents

Exploit Mechanics: The 355 ETH theft followed the approval-draining pattern: users who had previously approved Unibot’s executor contracts for trading found their wallets drained when attackers called transferFrom directly on token contracts using Unibot’s delegated approval.

Risk Assessment: High—Verified token code shows centralized control vectors; executor contracts remain unverified and vulnerable to the same approval exploits as Maestro.

3. Banana Gun: The Unverified Speed Demon

Contract Address: 0x38e68a37e401f7271568cecaac63c6b1e19130b4 (Ethereum Mainnet)
Chains: Ethereum, Solana, Base
Exploit Loss: None documented (public)

Code Review Findings: Banana Gun’s BANANA token is verified (2023 deployment), showing standard ERC-20 implementation with Uniswap V2 router integration. The contract lacks complex logic—basic transfer functions with swapExactTokensForETHSupportingFeeOnTransferTokens for DEX interaction. Notably, the contract has renounced ownership (no Ownable functions active), reducing centralized manipulation risks at the token layer.

Security Architecture:

• No Custom Logic: Minimal attack surface at token level—relies entirely on Uniswap infrastructure
• Solana Opacity: Solana program IDs not publicly verified; Rust-based executors lack transparency compared to EVM counterparts
• Off-Chain Heavy: Trade execution relies heavily on Telegram-to-wallet signature flows, potentially reducing on-chain exposure but increasing custodial trust assumptions

Vulnerability Assessment: While no public exploits match Maestro/Unibot’s scale, Banana Gun’s Solana executors operate as black boxes—no program verification available for the Rust contracts handling Jupiter DEX routing. The “anti-rug” features (simulating sells before execution) provide UX safety but not contract-level security guarantees.

Risk Assessment: Medium-High—Clean token contract but unverified Solana programs; “MEV-resistant” claims unverified by third-party audit.

The Extended Roster: Four Additional High-Volume Bots

Beyond the primary three exploit cases, the Telegram trading ecosystem includes four additional high-volume platforms with distinct risk profiles:

4. Trojan: The Volume Leader (Multi-Chain)

Chains: Ethereum, BSC, Solana, Base, Avalanche, Arbitrum, Tron, Sonic, TON
Volume: #1 by lifetime trading volume (per CoinGecko)
Fee Structure: 1% per transaction

Security Profile: Claims MEV protection and anti-rug features, but no contract audits published. High volume creates attack surface; multi-chain deployment increases smart contract complexity across heterogeneous environments (Solidity vs. Rust vs. FunC for TON).

Critical Risk: No verified contract addresses publicly listed; users trade against unaudited executors with 9-chain exposure.

5. BONKbot: The Solana Specialist

Chains: Solana (SPL tokens via Jupiter DEX)
Fee Structure: 1% sniping, 0.5% manual trades

Security Profile: Developed by the BONK community, routed through Jupiter DEX (verified aggregator). Offers optional “anti-MEV” mode (slower execution for protection). Lower risk than Maestro/Unibot due to reliance on Jupiter’s verified programs rather than custom executors.

Vulnerability: Optional MEV protection implies standard mode exposes users to sandwich attacks; custody model still requires wallet connection to Telegram interface.

6. SolTradingBot: The Referral Engine

Chains: Solana
Notable Feature: 30% referral program

Security Profile: Sniping and DCA functionality with heavy emphasis on referral mechanics. No public contract verification found; high referral payouts (30%) suggest Ponzi-like mechanics where early users are paid by new deposits rather than trading fees.

Red Flag: Unsustainable fee structures often precede contract drainage or “soft rug” events where devs extract liquidity.

7. Wagie Bot: The Cross-Platform Trader

Chains: Ethereum, BSC, Arbitrum
Platforms: Telegram + Discord

Security Profile: Offers copy-trading and DCA strategies across multiple chains. Limited technical documentation available; Discord integration increases API key exposure risks beyond standard Telegram bot vulnerabilities.

Comparative Vulnerability Matrix

Data aggregated from Etherscan verification, CertiK reports, and exploit post-mortems (2024-2025). “Token Only” indicates platform token is verified but executor contracts remain unverified.

The Kill Chain: How Exploits Execute

Step 1: Approval Harvesting
Users must approve bot executors to spend tokens (e.g., “Approve USDT for trading”). Most bots request infinite allowance (type(uint256).max) to avoid repeated approval UX friction.

Step 2: Executor Exposure
Bot contracts expose low-level token functions (transferFrom, safeTransfer) without access modifiers. The vulnerable pattern:

function executeTransfer(address token, address from, address to, uint256 amount) external {

    IERC20(token).transferFrom(from, to, amount);  // No msg.sender validation

}

Step 3: Arbitrary Invocation
Attackers monitor approved wallets (via event logs) and directly call transferFrom on the token contract—not the bot—using the bot’s prior approval.

Step 4: Drainage
Funds move from victim → attacker, bypassing bot interfaces entirely. The bot’s approval acts as a persistent backdoor until explicitly revoked.

Risk Mitigation: The Paranoid Operator’s Protocol

Immediate Actions:

1. Revoke All Approvals: Visit Revoke.cash or Etherscan Token Approvals and remove unlimited approvals for:
   • 0xd7d170dd009ad0de82943ea2fe8c0e8999272a98 (Maestro)
   • 0xf819d9cb1c2a819fd991781a822de3ca8607c3c9 (Unibot)
   • Any Banana Gun executor addresses found in your transaction history
2. Use Burner Wallets: Isolate Telegram bot interactions to wallets holding <$1,000. Never connect primary cold storage to Telegram interfaces.
3. Verify Before Trust: Check contract verification on Etherscan. If the bot’s executor shows “Contract Source Code Not Verified,” treat as hostile.

Alternative Architectures:

• Self-Custodial Execution: Use Jupiter Terminal (Solana) or 1inch (Ethereum) directly—no Telegram intermediary holding approvals.
• Hardware Wallet Isolation: Execute trades via hardware wallet (Coldcard, Trezor) with transaction verification on-device, bypassing bot intermediaries entirely.

Conclusion: The Unaudited Infrastructure Crisis

The Telegram trading bot sector represents convenience maximalism at the expense of security minimalism. With zero public audits across the top seven volume leaders and documented exploits exceeding $2.8M, these platforms operate as unregulated custodians with sweeping wallet permissions.

Maestro and Unibot’s transferFrom exploits reveal a systemic pattern: in the rush to capture MEV and sniping fees, developers deployed executors with unauthenticated spending privileges, effectively creating honeypots where user approvals become persistent attack vectors.

The absence of contract verification, the prevalence of upgradeable proxies without timelocks, and the lack of access controls suggest that current exploit losses represent early indicators rather than isolated incidents. Until standardized audits (CertiK, Trail of Bits, OpenZeppelin) become industry norm rather than exception, these bots remain high-risk execution environments unsuitable for capital exceeding discretionary speculation limits.

For active traders requiring Telegram convenience: Use Banana Gun’s verified token contract and Solana integration (lower exploit history), maintain strict approval hygiene via Revoke.cash, and never deposit more than 5% of portfolio to bot-connected wallets.

Research conducted using ASCN.ai

Risk Disclosure: Telegram trading bots involve extreme smart contract risks including arbitrary approval drainage, proxy upgrade attacks, and unverified executor logic. The documented exploits (635 ETH+ stolen) represent confirmed losses; unaudited contracts may contain additional vulnerabilities. Always verify contract addresses independently before approving token spending. Not financial advice.

Further reading: 

Automated Trading Bots That Don’t Require Coding: 8 Platforms Compared on 12-Month Returns

AI Trading Bots: The Honest Guide (What Works, What Fails, What’s a Scam)

The Best Crypto Telegram Bots to Watch

How to Build a Bulletproof Crypto Trading Strategy

The Only 5 Crypto Trading Strategies That Work Long-Term (2026 Master Guide)