x402-payment-tron
WarnAudited by ClawScan on May 10, 2026.
Overview
This payment skill is coherent for x402/TRON payments, but it can use a TRON private key to make payments and grant unlimited USDT allowance without clear spending limits or per-payment confirmation.
Only install this if you intend the agent to make TRON USDT payments. Use a dedicated low-balance wallet, start on testnet, avoid autonomous use with untrusted URLs, inspect every recipient/spender and amount, and revoke any unlimited USDT allowance after use.
Findings (5)
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.
A mistaken or malicious endpoint could cause the agent to authorize or spend wallet funds more broadly than the user expected.
The tool can call arbitrary x402 endpoints and automatically approve/pay when challenged, with no documented spend cap, recipient allowlist, or user confirmation before high-impact financial actions.
If payment is required (402), it automatically: ... Checks USDT allowance. If insufficient, it performs an **infinite approval** (MAX_UINT256) ... | `url` | string | Yes | Full URL to invoke |
Require explicit user confirmation for every payment and approval, show the recipient/spender and amount, enforce a maximum spend, and prefer exact allowances instead of unlimited approval.
Installing the skill may let the agent use a locally stored wallet key to authorize blockchain transactions.
The code reads a TRON private key from environment and multiple local config locations, including a fallback over all MCP server configs, then uses it for signing. This is powerful wallet authority and is broader than the registry credential declaration.
if (process.env.TRON_PRIVATE_KEY) { return process.env.TRON_PRIVATE_KEY; } ... path.join(os.homedir(), '.mcporter', 'mcporter.json') ... for (const serverName in config.mcpServers) ... return s.env.TRON_PRIVATE_KEY;Use a dedicated low-balance wallet, declare the private key as a primary credential in metadata, avoid scanning unrelated MCP server configs, and require user approval before any transaction signing.
A one-time invocation could create a long-lived allowance that exposes more USDT than the current payment amount.
An unlimited token allowance can persist after the immediate request and may affect future wallet safety if the approved spender or endpoint path is compromised or misused.
it performs an **infinite approval** (MAX_UINT256) to minimize future transactions
Approve only the needed amount, document revocation steps, and provide an option to disable automatic approval or limit it to trusted spenders.
A future dependency change could alter the code that handles wallet signing if the user rebuilds from source.
Development builds can fetch version-ranged dependencies and use npx. This is common, but dependency provenance matters more for a wallet-signing payment skill.
"build": "npx @vercel/ncc build src/index.ts -o dist" ... "@open-aibank/x402-tron": "^0.1.4", "tronweb": "^5.3.0"
Prefer a reviewed, pinned build with a lockfile and verify dependency provenance before using a wallet with real funds.
Users must trust the bundled JavaScript and its dependencies when running the prebuilt file.
The bundled file contains dynamic require via eval. It is not shown to evaluate user-controlled input and is likely dependency boilerplate, but it reduces audit clarity for the prebuilt executable.
module.exports = eval("require")("debug");Use a pinned, reproducible build and avoid running the prebuilt bundle with a high-value wallet unless the bundle has been independently verified.