Inspiration
Most people can't read Solidity, so before sending funds to a smart contract they either blindly trust it or avoid Web3 entirely out of fear. Scam contracts and rug pulls succeed precisely because their risk signals are buried in code that only developers can parse. I wanted to build something that closes that gap — turning raw on-chain data into a plain-English answer to the question "is this safe?"
What it does
ChainGuard is a Telegram bot that lets anyone check a smart contract before trusting it. A user sends /check <contract address>, and the bot:
- Pulls live on-chain data from Etherscan — verification status, source code, contract name, compiler version, and whether it uses a proxy pattern
- Sends that data to Google Gemini, which explains in plain English what the contract does
- Returns two separate risk scores instead of one blended rating:
- Centralization Risk — how much power the contract owner holds (mint, pause, blacklist, upgrade functions)
- Scam/Malicious Pattern Risk — signs specific to rug pulls and honeypots (hidden code, functions that trap regular users' funds while letting the owner withdraw, deceptive proxy patterns)
Splitting these two scores solves a real weakness in simpler contract-checking tools: a legitimate project with owner privileges (like a major stablecoin's mint function) and an actual scam contract can look identical under a single "risk score." ChainGuard tells users which kind of risk they're actually looking at.
How I built it
- Python backend running on Replit, built entirely on mobile
- Telegram Bot API for the user-facing interface
- Etherscan API for on-chain contract data (source code, verification, proxy detection)
- Google Gemini API (free tier) for natural-language contract analysis and risk scoring
- Secrets (bot token, API keys) managed via Replit's environment variables, not committed to the repo
Challenges I ran into
- Getting Gemini's model name right — an early version pointed to a deprecated model and failed silently with a generic error, which took some digging through logs to trace
- Designing prompts that produce consistent, structured risk categories rather than freeform text, so the two-score system stays reliable across different contracts
- Balancing accuracy vs. oversimplification — early single-score results conflated legitimate admin controls with actual scam patterns, which led to the two-category redesign
What I learned
- How to reason about smart contract risk beyond just "is the code verified" — ownership structure and function permissions matter as much as verification status
- How to build and ship a working AI agent end-to-end entirely from a mobile device
- The importance of testing against multiple real contracts (not just one) to catch cases where a model's first output looks right but isn't actually distinguishing risk types correctly
What's next
- Extending contract analysis to additional chains (e.g. Solana, Algorand)
- Adding historical transaction pattern analysis to catch behavioral red flags, not just code-level ones
- A lightweight web dashboard alongside the Telegram bot for users who prefer a browser interface
Built With
- etherscan-api
- google-gemini
- python
- telegram-bot-api
Log in or sign up for Devpost to join the conversation.