Binance Dca Tool
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is coherent for Binance DCA, but it can place real recurring crypto buy orders with Binance API keys and does not clearly bound approvals, spend limits, credential scope, or scheduling duration.
Only install or use this if you are comfortable granting Binance trading access. Start on Binance testnet, use a restricted API key with withdrawals disabled, avoid storing secrets directly in cron, set small explicit budgets, and require confirmation before any live or recurring buy.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If run with valid Binance keys, the skill can immediately spend real funds on crypto purchases that may not be reversible.
The script defaults to Binance's live API, defaults buy orders to MARKET, and sends a signed POST to the order endpoint without a built-in confirmation, dry-run default, or spend cap.
BASE_URL="${BINANCE_BASE_URL:-https://api.binance.com}" ... type="${3:-MARKET}" ... resp=$(api_signed "POST" "/api/v3/order" "$query")Use testnet first, add an explicit confirmation step before every live buy, set a maximum order amount, and make dry-run/projection the default until the user approves execution.
A user may not realize installation/use involves granting trading-capable Binance account access, including balances, trade history, and order placement.
The skill requires high-impact Binance credentials for signed account actions, while the supplied registry metadata says there are no required env vars and no primary credential, under-declaring the credential boundary.
Requires two environment variables (never hardcode these): export BINANCE_API_KEY="your-key"; export BINANCE_SECRET_KEY="your-secret"
Declare the Binance credential requirement in metadata and instruct users to create a restricted API key with withdrawals disabled, least-privilege spot-trading permissions, IP restrictions where possible, and separate testnet credentials for testing.
A scheduled job could continue buying crypto automatically after the original task, spending funds until the user notices or removes it.
The documentation encourages persistent scheduled buys using credentials, but the example does not include an end date, total budget, per-run confirmation, or explicit cleanup/disable instructions.
For automated recurring buys, suggest setting up a cron job or OpenClaw cron: ... 0 9 * * 1 BINANCE_API_KEY=... BINANCE_SECRET_KEY=... /path/to/dca.sh buy BTCUSDT 50
Require clear user approval for any schedule, include an end date or maximum total spend, prefer alerts plus confirmation before each live order, and document how to pause or remove the schedule.