StorJ Agent

Autonomous economic agent that earns BTC & SOL by selling storage, compute, and bandwidth. Pays its own hosting, manages subagents, posts tweets, and replica...

Do NOT run or deploy this skill with real secrets or real funds. Specific concerns and next steps: - Stop: the repo already contains hardcoded API keys, a Supabase key, Storj credentials, and Twitter tokens in source files and twitterdata.txt. Treat those values as compromised. - Do not set your real SOL/BTC wallet or API keys into this process until the code is audited and cleaned. - Fixes required before trusting: remove all hardcoded secrets; use only environment variables as documented; remove any leftover credential files; and rotate any keys that were leaked in these files. - Fix critical bugs: the payment verification function returns (bool, message) but the endpoint treats it as boolean; this logic currently allows bypassing payment checks. Also fix the replay-protection flow (do not mark a signature as used before verifying payment and ensure atomic checks against a durable store). - Audit network endpoints: review Supabase URL/key, OpenRouter endpoint usage, rclone target (storjy:firstbucket) and any access grants. Treat the included SUPABASE_KEY/STORJ_ACCESS/ACCESS_GRANT as compromised and rotate them. - Principle-of-least-privilege: run any further tests in an isolated environment (no real wallets, no production keys), and disable autonomous operation until you can confirm correct verification and security controls. - If you need this functionality, ask the author for a clean release that: uses env vars only, documents exactly which keys are needed, removes embedded test data/base64 dumps, and includes unit tests demonstrating correct payment verification and replay-resistance. If the source/author is unknown or cannot explain these issues, consider this skill untrustworthy.

Type: OpenClaw Skill Name: storj-agent Version: 2.0.0 The skill bundle is classified as suspicious due to critical security vulnerabilities. Multiple sensitive API keys and secrets (OpenRouter, Twitter, Supabase, Storj) are hardcoded in `mainapp.py` and `services/tasking.py`, directly violating the `SKILL.md` instruction to use environment variables. More critically, the `upload_file_rclone` function in `services/tasking.py` is vulnerable to shell injection, as it uses unsanitized user-provided `filename` directly in a `subprocess.run` command, allowing arbitrary command execution on the host system. Additionally, `blockchain/blockchain.py` includes a `generate_wallets` function that saves private keys to a local JSON file, marked 'FOR TESTING ONLY', which poses a risk if misused.