Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Crypto Genie
v1.0.0AI-powered cryptocurrency safety assistant with database-first architecture. Protects users from phishing, honeypots, rug pulls, and ponzi schemes. No extern...
⭐ 0· 604·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The code and docs match the stated purpose: local SQLite DB checks (crypto_check_db.py) and a background Etherscan sync (sync_worker.py) to populate the DB. Dependencies (httpx, cryptography) and an encrypted key manager are consistent with fetching and storing an Etherscan API key. Minor surprises: the manifest and docs mention multi-source verification (ChainAbuse) but the visible code primarily references Etherscan; duplicate/odd entries in blockchain_detector.py indicate code-quality issues but not malicious intent.
Instruction Scope
SKILL.md instructs installation, optional setup of ETHERSCAN_API_KEY (via setup.sh or env var), cron/systemd for background sync, and running scripts that create and use a local DB under ~/.config/crypto-genie. The runtime instructions stay within the stated purpose (fetching from Etherscan and analyzing transactions), but they automatically queue unknown addresses for background sync and ask the user to store an API key (potentially in environment or systemd unit). There is no obvious instruction to read or transmit unrelated host data, but some helper scripts (verify_package.sh, setup.sh) are present and should be inspected for network operations.
Install Mechanism
There is no remote download URL for arbitrary code; installation is local via install.sh which creates a Python venv and pip-installs requirements.txt. This is a commonly used but still potentially risky pattern: pip installs execute code from PyPI. The installer runs in 'silent' mode (redirects stdout/stderr) which can hide important prompts or errors during install — that increases the chance a user misses unexpected behavior.
Credentials
Registry metadata lists no required environment variables or primary credential, but SKILL.md and multiple scripts clearly expect an ETHERSCAN_API_KEY (env var or interactive encrypted storage). That mismatch is important: the skill needs an API key to function (the sync worker will send it to Etherscan), yet the manifest does not declare this requirement. The systemd example also embeds ETHERSCAN_API_KEY in the unit file (a risky practice). No other unrelated credentials are requested in visible files, but the missing declaration and the recommendation to store the API key in environment/systemd are security/usability concerns.
Persistence & Privilege
The skill does not request 'always: true' and does not claim autonomous elevated privileges. It does recommend installing a systemd service in docs (which would require system-level changes and could run continuously under a specified user). That is optional in the docs, but users should not blindly copy the systemd snippet (it hardcodes User=ubuntu and absolute paths). The skill stores its DB and encrypted keys under ~/.config/crypto-genie, which is reasonable for a local tool.
What to consider before installing
What to check before installing/using this skill:
- ETHERSCAN_API_KEY is required in practice (setup.sh or ETHERSCAN_API_KEY env var), but the registry metadata does not declare this — expect to provide that secret. Prefer the interactive encrypted setup (./setup.sh) to avoid placing the key in plaintext env variables or systemd unit files.
- Inspect secure_key_manager.py and setup.sh to confirm how your API key is encrypted and stored (verify PBKDF2 iteration count, salt handling, and that keys are not written to logs). The README claims AES-256 + PBKDF2; validate that implementation before trusting it.
- Review sync_worker.py and verify_package.sh for any network endpoints beyond Etherscan (ChainAbuse, telemetry, or custom domains). The background worker makes outbound API calls; only give it the minimum credential (Etherscan) and be sure you trust the code that uses it.
- Run the installer in an isolated environment (container or VM) first. The installer pip-installs packages from PyPI — confirm requirements.txt and installed packages are acceptable and do not introduce supply-chain risks.
- Do not blindly copy the systemd unit provided in docs: it hardcodes User=ubuntu and suggests embedding ETHERSCAN_API_KEY in the unit. If you create a service, set an appropriate user, and avoid putting secrets in the unit environment in plaintext (use the encrypted store instead).
- Check verify_package.sh and any other helper scripts for remote downloads or short/obfuscated URLs; these would be higher risk. If you see downloads from non-standard or personal domains, do not run them.
- Given some code-quality issues (duplicate keys in blockchain_detector, truncated/placeholder code for other chains), treat this package as moderately immature: perform extra auditing if you plan to use it on a production machine.
If you want, I can: (1) show the contents of secure_key_manager.py and sync_worker.py and point out exact lines to review, (2) list requirements.txt contents so you can vet packages, or (3) produce a safe installation checklist you can follow to sandbox and test the skill.Like a lobster shell, security has layers — review code before you run it.
latestvk970p31agd30tf809p8jdnepc981hd9m
License
MIT-0
Free to use, modify, and redistribute. No attribution required.