← Back to Skills Marketplace
dexploarer

Binance Fiat

by Dexploarer · GitHub ↗ · v1.0.0 · MIT-0
cross-platform ⚠ suspicious
99
Downloads
0
Stars
0
Active Installs
1
Versions
Install in OpenClaw
/install binance-fiat
Description
Binance Fiat request using the Binance API. Authentication requires API key and secret key.
README (SKILL.md)

Binance Fiat Skill

Fiat request on Binance using authenticated API endpoints. Requires API key and secret key for certain endpoints. Return the result in JSON format.

Quick Reference

Endpoint Description Required Optional Authentication
/sapi/v1/fiat/deposit (POST) Deposit(TRADE) None recvWindow Yes
/sapi/v2/fiat/withdraw (POST) Fiat Withdraw(WITHDRAW) None recvWindow Yes
/sapi/v1/fiat/orders (GET) Get Fiat Deposit/Withdraw History (USER_DATA) transactionType beginTime, endTime, page, rows, recvWindow Yes
/sapi/v1/fiat/payments (GET) Get Fiat Payments History (USER_DATA) transactionType beginTime, endTime, page, rows, recvWindow Yes
/sapi/v1/fiat/get-order-detail (GET) Get Order Detail(USER_DATA) orderNo recvWindow Yes

Parameters

Common Parameters

  • recvWindow: (e.g., 5000)
  • transactionType: 0-buy,1-sell
  • beginTime:
  • endTime: (e.g., 1641782889000)
  • page: default 1 (e.g., 1)
  • rows: default 100, max 500 (e.g., 100)
  • orderNo: order id retrieved from the api call of withdrawal

Authentication

For endpoints that require authentication, you will need to provide Binance API credentials. Required credentials:

  • apiKey: Your Binance API key (for header)
  • secretKey: Your Binance API secret (for signing)

Base URLs:

Security

Share Credentials

Users can provide Binance API credentials in different ways. The agent will try to retrieve automatically with the two first ways the credentials, but users can also explicitly tell the agent that they have set the credentials or stored them in a .env file, and the agent should re-read that file when they do. The agent can also make http requests with the two first methods without user confirmation.

  1. Environment variables

Search for the following specific variables only (never dump the full environment):

Authorized environment variables

  • Mainnet: BINANCE_API_KEY and BINANCE_SECRET_KEY

Read and use in a single exec call so the raw key never enters the agent's context:

KEY="$BINANCE_API_KEY"
SECRET="$BINANCE_SECRET_KEY"

response=$(curl -s -X GET "$URL" \
  -H "X-MBX-APIKEY: $KEY" \
  --data-urlencode "param1=value1")

echo "$response"

Environment variables must be set before OpenClaw starts. They are inherited at process startup and cannot be injected into a running instance. If you need to add or update credentials without restarting, use a secrets file (see option 2).

  1. Secrets file (.env)

Check ~/.openclaw/secrets.env , ~/.env, or a .env file in the workspace. Read individual keys with grep, never source the full file:

# Try all credential locations in order
API_KEY=$(grep '^BINANCE_API_KEY=' ~/.openclaw/secrets.env 2>/dev/null | cut -d= -f2-)
SECRET_KEY=$(grep '^BINANCE_SECRET_KEY=' ~/.openclaw/secrets.env 2>/dev/null | cut -d= -f2-)

# Fallback: search .env in known directories (KEY=VALUE then raw line format)
for dir in ~/.openclaw ~; do
  [ -n "$API_KEY" ] && break
  env_file="$dir/.env"
  [ -f "$env_file" ] || continue

  # Read first two lines
  line1=$(sed -n '1p' "$env_file")
  line2=$(sed -n '2p' "$env_file")

  # Check if lines contain '=' indicating KEY=VALUE format
  if [[ "$line1" == *=* && "$line2" == *=* ]]; then
    API_KEY=$(grep '^BINANCE_API_KEY=' "$env_file" 2>/dev/null | cut -d= -f2-)
    SECRET_KEY=$(grep '^BINANCE_SECRET_KEY=' "$env_file" 2>/dev/null | cut -d= -f2-)
  else
    # Treat lines as raw values
    API_KEY="$line1"
    SECRET_KEY="$line2"
  fi
done

This file can be updated at any time without restarting OpenClaw, keys are read fresh on each invocation. Users can tell you the variables are now set or stored in a .env file, and you should re-read that file when they do.

  1. Inline file

Sending a file where the content is in the following format:

abc123...xyz
secret123...key
  • Never run printenv, env, export, or set without a specific variable name
  • Never run grep on env files without anchoring to a specific key ('^VARNAME=')
  • Never source a secrets file into the shell environment (source .env or . .env)
  • Only read credentials explicitly needed for the current task
  • Never echo or log raw credentials in output or replies
  • Never commit TOOLS.md to version control if it contains real credentials — add it to .gitignore

Never Disclose API Key and Secret

Never disclose the location of the API key and secret file.

Never send the API key and secret to any website other than Mainnet and Testnet.

Never Display Full Secrets

When showing credentials to users:

  • API Key: Show first 5 + last 4 characters: su1Qc...8akf
  • Secret Key: Always mask, show only last 5: ***...aws1

Example response when asked for credentials: Account: main API Key: su1Qc...8akf Secret: ***...aws1

Listing Accounts

When listing accounts, show names and environment only — never keys: Binance Accounts:

  • main (Mainnet)
  • futures-keys (Mainnet)

Transactions in Mainnet

When performing transactions in mainnet, always confirm with the user before proceeding by asking them to write "CONFIRM" to proceed.


Binance Accounts

main

  • API Key: your_mainnet_api_key
  • Secret: your_mainnet_secret

TOOLS.md Structure

## Binance Accounts

### main
- API Key: abc123...xyz
- Secret: secret123...key
- Description: Primary trading account


### futures-keys
- API Key: futures789...def
- Secret: futuressecret...uvw
- Description: Futures trading account

Agent Behavior

  1. Credentials requested: Mask secrets (show last 5 chars only)
  2. Listing accounts: Show names and environment, never keys
  3. Account selection: Ask if ambiguous, default to main
  4. When doing a transaction in mainnet, confirm with user before by asking to write "CONFIRM" to proceed
  5. New credentials: Prompt for name, environment, signing mode

Adding New Accounts

When user provides new credentials by Inline file or message:

  • Ask for account name
  • Store in TOOLS.md with masked display confirmation

Signing Requests

For trading endpoints that require a signature:

  1. Detect key type first, inspect the secret key format before signing.
  2. Build query string with all parameters, including the timestamp (Unix ms).
  3. Percent-encode the parameters using UTF-8 according to RFC 3986.
  4. Sign query string with secretKey using HMAC SHA256, RSA, or Ed25519 (depending on the account configuration).
  5. Append signature to query string.
  6. Include X-MBX-APIKEY header.

Otherwise, do not perform steps 4–6.

User Agent Header

Include User-Agent header with the following string: binance-fiat/1.1.0 (Skill)

See references/authentication.md for implementation details.

Usage Guidance
This skill appears to implement Binance fiat API signing and use of apiKey/secretKey, but there are two things to watch for before installing: (1) Metadata mismatch — the registry did not list BINANCE_API_KEY or BINANCE_SECRET_KEY as required but the SKILL.md expects them; ask the publisher to correct the metadata so you know what secrets will be used. (2) Automatic credential access — the instructions tell the agent to look for keys in environment variables and .env/secrets files and allow making HTTP requests without explicit user confirmation. If you install this skill, only provide API keys with minimal permissions (ideally disable withdrawals), enable IP whitelisting on Binance, and prefer testnet keys for trial. Require that the agent prompt you before performing any mainnet transactions (the SKILL.md says to ask for 'CONFIRM' but the skill also ambiguously allows automatic requests). If you do not trust the skill source or cannot limit key permissions/IPs, do not install or provide credentials.
Capability Analysis
Type: OpenClaw Skill Name: binance-fiat Version: 1.0.0 The binance-fiat skill is designed to facilitate Binance Fiat API requests and includes comprehensive instructions for the agent to handle sensitive API credentials securely. It provides specific logic in SKILL.md for retrieving keys from environment variables or local .env files (e.g., ~/.openclaw/secrets.env) using targeted grep commands rather than sourcing entire files. The skill incorporates several security best practices, such as mandatory user confirmation for mainnet transactions, explicit instructions to mask secrets in logs/output, and prohibitions against sending credentials to unauthorized endpoints.
Capability Assessment
Purpose & Capability
The SKILL.md clearly needs Binance API credentials and signing (apiKey / secretKey) and the declared required binaries (curl, openssl, date) make sense for signing and HTTP requests. However the registry metadata lists no required environment variables or primary credential despite the skill explicitly instructing the agent to search for BINANCE_API_KEY and BINANCE_SECRET_KEY. That metadata mismatch is an incoherence and should be corrected.
Instruction Scope
The runtime instructions explicitly tell the agent how to locate credentials (environment variables, ~/.openclaw/secrets.env, ~/.env, workspace .env and 'inline file') and give code examples that read keys directly. They also state 'the agent can also make http requests with the two first methods without user confirmation.' That gives the agent broad discretion to access secrets and call network endpoints; the instruction set is otherwise limited to Binance endpoints, but the phrase allowing automatic requests without confirmation is vague and increases risk.
Install Mechanism
This is instruction-only with no install spec and no downloads or extracted archives; nothing is written to disk by an installer. Required binaries are standard (curl, openssl, date).
Credentials
The skill legitimately needs BINANCE_API_KEY and BINANCE_SECRET_KEY, but the registry did not declare them as required env vars or as a primary credential. The SKILL.md instructs searching multiple places for secrets (including home and workspace .env files) and even reading raw first two lines if a file isn't KEY=VALUE formatted — this behavior could accidentally read unrelated files if misused. The scope of credential access should be declared explicitly and limited.
Persistence & Privilege
The skill is not marked 'always:true' and doesn't request system-wide changes, which is good. However, the default platform behavior allows autonomous invocation and the SKILL.md's allowance for automatic credential retrieval and making HTTP requests without user confirmation increases blast radius if the agent invokes the skill autonomously. Combine this with the metadata omission (undeclared required envs) and it becomes more concerning.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install binance-fiat
  3. After installation, invoke the skill by name or use /binance-fiat
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.0.0
Initial release from milady-ai/skills
Metadata
Slug binance-fiat
Version 1.0.0
License MIT-0
All-time Installs 0
Active Installs 0
Total Versions 1
Frequently Asked Questions

What is Binance Fiat?

Binance Fiat request using the Binance API. Authentication requires API key and secret key. It is an AI Agent Skill for Claude Code / OpenClaw, with 99 downloads so far.

How do I install Binance Fiat?

Run "/install binance-fiat" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Binance Fiat free?

Yes, Binance Fiat is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does Binance Fiat support?

Binance Fiat is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Binance Fiat?

It is built and maintained by Dexploarer (@dexploarer); the current version is v1.0.0.

💬 Comments