x402 Payments
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This is a coherent x402 payment helper, but it gives an agent broad wallet-spending authority and the approval/payment-limit boundaries need careful review.
Install only if you are comfortable giving the agent controlled spending ability. Use a fresh low-balance wallet, keep only the USDC you are willing to spend on Base, pin dependencies, prefer dry-run/manual approval, and avoid using WALLET_PRIVATE_KEY from a primary trading account.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
65/65 vendors flagged this skill as clean.
Risk analysis
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.
The agent may spend USDC from the configured wallet when it encounters paid endpoints, including unintended or repeated requests.
The skill explicitly permits autonomous payments and exposes a generic URL fetch path, so a mistaken or prompt-influenced agent could pay unintended x402 endpoints unless the user adds external controls.
This skill enables agents to autonomously make crypto payments... `python x402_cli.py fetch <url>`
Use a dedicated low-balance wallet, require explicit approval before paid fetches, restrict allowed payment domains/providers, and set a small hard spending limit.
The documented payment cap may not reliably protect the user in all provider response formats.
The local max-payment check is skipped when payment details cannot be parsed, after which the SDK is allowed to handle payment automatically; the artifact does not show an equivalent hard cap being passed into that fallback path.
except (json.JSONDecodeError, KeyError, ValueError, IndexError):
pass # Can't parse payment info, let x402 SDK handle it
# Use v2 SDK — handles 402 payment automaticallyEnforce the maximum payment limit inside the payment-signing path for every 402 response format, fail closed when price cannot be parsed, and log the exact amount before payment.
If a main wallet key is used, mistakes or dependency compromise could put more funds and account authority at risk than intended for API micro-payments.
The skill may use a general-purpose or trading wallet private key, not just a narrowly scoped payment credential, giving the payment flow authority over a sensitive cross-chain wallet identity.
Falls back to `WALLET_PRIVATE_KEY` if `EVM_PRIVATE_KEY` is not set... Your EVM address works on all chains — Polygon for trading, Base for x402 payments.
Do not use a primary trading wallet; create a separate Base wallet funded only with the small amount of USDC you are willing to spend.
Future dependency updates could change behavior in code that handles wallet signing and network payments.
The dependencies are purpose-aligned, but they are not pinned to exact versions even though they participate in wallet/account handling and payment signing.
x402[httpx,evm]>=1.0.0 httpx>=0.25.0 eth-account>=0.10.0
Pin exact dependency versions or use a reviewed lockfile before connecting a funded wallet key.
