Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Whale Alert Monitor 鲸鱼预警
v1.0.0🐋 Whale Alert 大户监控 - 追踪加密货币巨鲸动向、大额转账预警、交易所资金流向分析。 当你想追踪聪明钱的每一步,监测大户交易行为时使用此技能。
⭐ 0· 46·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
Capability signals
These labels describe what authority the skill may exercise. They are separate from suspicious or malicious moderation verdicts.
OpenClaw
Suspicious
high confidencePurpose & Capability
The code and scripts match the stated purpose (wallet tracking, transfer monitoring, exchange flow and alerting). However the package metadata (_meta.json) and payment.py introduce unexpected billing infrastructure: _meta.json declares a billing integration requiring SKILLPAY_API_KEY / SKILLPAY_USER_ID, and SKILL.md advertises SkillPay pricing, yet the registry 'requirements' lists no required env vars. Also payment.py contains a hard-coded BILLING_API_KEY constant — a secret embedded in source — which is disproportionate to a typical monitoring tool and inconsistent with the declared env-based billing configuration.
Instruction Scope
SKILL.md instructs running the provided python scripts (whale_tracker, transfer_monitor, exchange_flow, holding_analyzer, monitor_daemon). The scripts read environment variables for notifications (TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID, DISCORD_WEBHOOK_URL, CUSTOM_WEBHOOK_URL) and payment.py expects SKILLPAY_USER_ID (or falls back to 'anonymous_user'). SKILL.md shows config placeholders like ${TELEGRAM_BOT_TOKEN} but the skill's declared requirements list no env vars — an inconsistency. The runtime instructions mention billing and imply the skill will verify/charge on start; payment.py's require_payment() is intended to run at skill start (per comments), which would cause external network calls to a billing endpoint and may terminate execution if payment fails. The SKILL.md does not document whether the skill will call the billing API automatically, nor whether local secrets will be used for billing, leaving ambiguous runtime behavior.
Install Mechanism
There is no install spec (instruction-only from registry perspective) and no downloads or external installers. The package includes Python scripts that run locally; nothing in the manifest attempts to fetch or execute code from arbitrary URLs. This is the lower-risk install model, though code will run locally when the user executes scripts.
Credentials
Declared requirements list no environment variables, but the code expects multiple secrets and config values: TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID, DISCORD_WEBHOOK_URL, CUSTOM_WEBHOOK_URL, and SKILLPAY_USER_ID (and the metadata references SKILLPAY_API_KEY). Worse, payment.py contains a baked-in BILLING_API_KEY (a long-looking API key) rather than using the env var named in _meta.json. Requiring billing credentials and notification webhooks is plausible for this skill, but leaving them undeclared in the registry and embedding a billing key in source is disproportionate and suspicious.
Persistence & Privilege
The skill is not set to always:true and does not request elevated platform privileges. It writes local files like alert_configs.json, alert_history.json and log files (normal for a monitoring daemon). It does not appear to modify other skills or global agent settings. Autonomous invocation is allowed by default but not combined here with other privilege escalations.
What to consider before installing
Key issues to consider before installing or running this skill:
- Hard-coded billing key: payment.py contains a baked-in BILLING_API_KEY. Embedded secrets are a security risk (leakage, abuse). Ask the author to remove the key and require the billing API key via an environment variable or other secure secret store. If you already ran this code, consider the key compromised and contact the billing provider to rotate/revoke it.
- Billing behavior unclear: _meta.json and SKILL.md indicate SkillPay billing; the code includes functions that will call the billing API and may terminate the skill if payment isn’t verified. Confirm whether the skill will attempt to charge or call the billing endpoint automatically on start, and whether it can run in a read-only/demo mode without network billing calls.
- Undeclared environment variables: The registry entry declares no required env vars, but the scripts expect TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID, DISCORD_WEBHOOK_URL, CUSTOM_WEBHOOK_URL, and SKILLPAY_* vars. The mismatch is an operational risk — the skill may attempt external network calls or fail unexpectedly. Require the author to document and declare required env vars in metadata.
- Network calls: Alerting and billing make outbound HTTP requests (SkillPay, Telegram, Discord, custom webhooks). If you run this in an environment with sensitive data or restricted network access, be mindful of where alerts/payment calls go.
- Code review & testing: The bulk of the scripts use simulated data for demonstrations (many fetch_* functions generate synthetic data), but confirm which modules actually call blockchain APIs in your deployed version. Run the code in an isolated environment first and audit all network interactions (e.g., with a proxy) before giving it access to production secrets.
- Recommended actions: 1) Ask the author to remove hard-coded secrets and to publish clear env var requirements; 2) Request explicit documentation on when billing calls are made and to which user_id; 3) Run the skill in a sandboxed environment and monitor outbound traffic; 4) Rotate any exposed keys if you or your environment already used them.
Given these inconsistencies and the embedded API key, treat the package as suspicious until the billing integration and secret management are clarified or fixed.Like a lobster shell, security has layers — review code before you run it.
latestvk97ey59q6vf8ddejtt033z542184a43j
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
Runtime requirements
🐋 Clawdis
