other
- Location
SKILL.md:75- Finding
Reusable Agent Wallet Private Key Transmitted to a Remote MCP Service
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is related to trading, but it should go to Review because it can control live financial trades while its custody, confirmation, and credential boundaries are inconsistent.
Review this carefully before installing. Do not provide an agent private key to a remote MCP service unless you accept that service receiving durable trading authority. Treat generated preview URLs as sensitive, avoid autonomous trading defaults for live funds, and rotate any 1inch key exposed through generated signing pages.
SKILL.md:75Reusable Agent Wallet Private Key Transmitted to a Remote MCP Service
SKILL.md:711Skill Instructions Hijack Agent Output and Mandate Persistent Advertising
src/tools/web3-trader.tools.ts:4251inch Bearer API Key Embedded in Publicly Accessible Signing Pages
src/tools/web3-trader.tools.ts:452Smart-Swap Capability URL Disclosed to an External QR Generation Service
requirements.txt:1Automatically Installed Python Dependencies Are Not Reproducibly Pinned
install.sh:1Installer Recommends Piping Mutable Network Content Directly into a Shell
The declared description presents a full-featured DEX and derivatives trading skill with broad trigger coverage, wallet support, non-custodial signing, Hyperliquid limit/perp trading, and multiple risk-control features. The supplied code chunk is only an example script for querying a USDT→ETH swap price and obtaining a quote with transaction calldata for later manual signing. Its primary behavior is much narrower than declared. While the code is related to token swapping, it does not substantiate most of the declared capabilities, and the implementation appears to target a generic quote/route workflow rather than the described advanced Antalpha/Hyperliquid trading stack. Therefore this is a material description-behavior mismatch.
The declared description presents an end-user trading skill with DEX swaps, Hyperliquid CLOB/perpetual features, wallet integrations, and risk-control behavior. The actual supplied code chunk does not implement any of those behaviors; it is strictly an installer/setup script. It creates directories, copies a config file, installs Python requirements, sets file permissions, and instructs the user to obtain a 0x API key and use a CLI. While setup scripts can be a supporting detail, this chunk materially fails to represent the described trading functionality and instead points to a different integration surface (0x API) than the declared Antalpha/Hyperliquid-focused functionality. Therefore, the description does not accurately represent what this code chunk actually does.
There is a material description/behavior mismatch. The strongest issue is that the description prominently claims v1 instant swap support through an Antalpha AI DEX aggregator, but this code chunk contains no swap-routing or on-chain token swap logic at all; it is entirely a Hyperliquid trading CLI. The Hyperliquid-related parts of the description are broadly consistent: limit orders, perpetuals, leverage, close position, funding rate, risk control, balance pre-check, order modification, and failure recovery are all reflected in the code. However, the code also provides substantial read/query features (account, orders, positions, fills, order book, funding, asset metadata) and a risk-config management command that are not clearly described. Additionally, wallet support claims for MetaMask/OKX/Trust/TokenPocket are not supported by the code shown, which instead takes keys/owner addresses via CLI args or environment variables. Overall, the declared purpose overstates swap/wallet capabilities and only partially matches the actual Hyperliquid CLI behavior.
The description presents a combined DEX swap and Hyperliquid trading skill, with emphasis on instant swaps, wallet integrations, non-custodial browser wallet signing, and added safety controls. The supplied code, however, is narrowly a backend Hyperliquid client. It does support part of the declared Hyperliquid functionality: read-only account queries, limit/market orders, perpetual position management, leverage changes, TP/SL triggers, and agent-wallet mode. But it does not implement the declared swap behavior, does not integrate any DEX aggregator, and does not show wallet connectors for MetaMask/OKX/Trust/TokenPocket. Additionally, it supports direct private-key usage via constructor/environment variables, which is materially different from the claim that private keys never leave the user wallet. It also exposes a fund transfer capability (spot/perp USDC class transfer in direct-key mode) that is not mentioned in the description. Because the actual code’s primary behavior is only a subset of the declared purpose and includes materially different signing/resource assumptions, this is a mismatch.
The declared description presents a broad DEX and derivatives trading skill with swap support plus advanced v2/v2.0.1 capabilities: limit orders, perpetuals, leverage, risk controls, balance checks, order edits, and Hyperliquid integration. The supplied code does not implement those features. Instead, it only generates a self-contained HTML page for reviewing a swap quote and sending a prebuilt Ethereum transaction through injected wallet providers, with wallet deep links for MetaMask/OKX/Trust/TokenPocket and optional QR code generation. While the swap-related and multi-wallet/zero-custody aspects are consistent with part of the description, the claimed advanced trading functionality is absent, making the description materially broader than the actual behavior.
The code partially matches the declared DEX swap purpose: it can fetch swap prices/routes and build transaction data for user-signed swaps, consistent with a zero-custody wallet flow and mentions of supported wallets. However, the declared description emphasizes a much broader trading skill, especially v2 features such as Hyperliquid limit orders, perpetual contracts, leverage, long/short, close position, funding rate, and risk-control workflows. None of those capabilities appear in this code chunk. Instead, the implementation is limited to spot swap quote/transaction preparation and related utilities, plus export/generation of EIP-681 links, HTML pages, and QR codes. Because the declared description materially overstates the implemented functionality and the actual code has a narrower primary purpose, this is a mismatch.
The description claims a broad DEX trading skill with both swap and advanced derivatives/orderbook features, but this code chunk is narrowly a quote/price client for the 0x swap API. Its actual functions are limited to token symbol resolution, calling /price and /quote endpoints, formatting results, and reading an API key from YAML config. There is no code for Hyperliquid integration, limit-order submission, perpetual contracts, leverage, positions, TP/SL, funding rates, wallet connection/signing, or explicit risk-control workflows. The description therefore materially overstates the implemented behavior and names capabilities not present in the supplied code.
The description presents a comprehensive DEX trading skill spanning immediate swaps, Hyperliquid CLOB limit orders, perpetual contracts, long/short, leverage, TP/SL, funding rate, risk control, and order management. This code chunk does something narrower: it renders a smart swap signing page and client-side flow for Ethereum Mainnet that helps a user approve an ERC-20, optionally wrap ETH into WETH, sign EIP-712 order data, and submit that order to a server. The wallet support and zero-custody claim are broadly consistent, and this is related to DEX order execution. However, the actual behavior does not implement or expose the much broader trading/perpetual/risk-control feature set claimed in the description. Because the declared purpose materially overstates the skill relative to this code chunk’s actual functionality, this is a mismatch.
The declared description presents a much broader trading skill covering instant swaps, Hyperliquid limit orders and perpetuals, wallet integrations, and multiple safety/UX features. This code chunk is narrowly focused on 1inch Fusion: building a signable order payload and querying order status/order lists. That is materially different from the declared primary purpose and omits major advertised capabilities. While limit-order-related functionality exists, it is not Hyperliquid and not the described full trading stack. Therefore the description does not accurately represent this code chunk.
The declared description presents a full-featured DEX/derivatives trading skill with swap execution, Hyperliquid limit/perpetual order support, wallet integration, and risk controls. The provided code chunk does not implement any of those behaviors. Instead, it is a storage/helper service for persisting HTML files and constructing preview URLs. While such a component could support a trading product, this specific code’s primary purpose is file/output management, not trading. Therefore the supplied code chunk does not accurately represent the declared skill behavior.
The code is related to the declared swap domain, so it is not wholly unrelated; it does present a swap UI and uses user wallets for signing, consistent with zero-custody wallet-based execution. However, the declared description claims a much broader and more advanced trading skill: v1 aggregator swap plus v2 Hyperliquid limit orders, perpetuals, agent wallet signing, layered risk controls, balance checks, order modification, and failure handling. None of those advanced capabilities appear in this code chunk. Instead, the code’s actual function is narrowly to render an HTML page for a single Ethereum-mainnet swap transaction and trigger eth_sendTransaction through injected wallets or wallet deep links. That is a materially narrower behavior than the declared purpose, and it also includes an undeclared auto-prompt/auto-execution UX pattern. Therefore the description does not accurately represent what this supplied code chunk actually does.
The declared description presents a comprehensive trading skill covering spot swaps and advanced Hyperliquid trading features. The supplied code chunk is much narrower: it defines token constants and a NestJS service that calls the 0x allowance-holder API endpoints /price and /quote, parses responses, estimates gas from a sample quote, and resolves/list tokens. This supports swap quotation and transaction construction only. There is no evidence here of order placement on Hyperliquid, perpetual contract support, limit orders, position queries/closing, leverage controls, stop-loss/take-profit, wallet connection logic, signature handling, or explicit balance/risk confirmation flows. This is therefore a material description-behavior mismatch, even though the swap-related portion loosely aligns.
The description advertises a broad trading skill covering DEX swaps plus Hyperliquid limit orders and perpetual futures operations, including long/short, leverage, close position, position lookup, funding rate, stop-loss/take-profit, and enhanced risk-control features. The supplied code only implements EVM swap-related tooling using 0x and 1inch Fusion: swap quotes, HTML swap/signing page generation, token listing, gas estimation, and smart-swap order lifecycle queries/cancellation guidance. These are related to part of the declared purpose, but major advertised capabilities—especially Hyperliquid/perpetual trading and the stated v2/v2.0.1 features—are absent from this code chunk. Therefore the declared description materially overstates the implemented behavior.
The declared description centers on blockchain trading functionality: DEX swaps, limit orders, perpetuals, wallet integrations, agent-wallet signing, and risk-control flows. The supplied code does not implement any trading, wallet, blockchain, order-management, or risk-control behavior. Instead, it exposes an HTTP GET endpoint that validates a file ID, resolves a file path, reads an HTML file from disk, and returns it to the browser with cache/CSP headers. This is a materially different primary purpose from the declared trading skill, so it is a clear description-behavior mismatch.
The declared description presents a full trading skill capable of executing swaps and Hyperliquid trading actions, including limit orders, perpetuals, leverage, risk controls, and wallet-based signing. However, the supplied code chunk is only a read-only test suite for market/account data retrieval. While some tested endpoints overlap conceptually with the description (e.g., funding rates, open orders, positions/account state), the actual code does not perform the primary advertised behaviors such as trading, signing, wallet interaction, or risk-confirmation workflows. This is a material description-behavior mismatch.
The version history says automatic execution was removed, but the technical details still describe a 2-second countdown that auto-triggers eth_sendTransaction in wallet browsers. In a crypto-trading context, that inconsistency is dangerous because it normalizes surprise signing prompts and can cause unintended transaction approval.
The markdown authorizes automatic execution of low-value trades without a clear upfront warning or strong opt-in. In a financial context, even 'small' autonomous trades can cause real loss, and normalizing auto-execution materially raises the risk of accidental or manipulated trading actions.
The script advertises installation via 'curl ... | bash', which encourages users to fetch and immediately execute remote code without inspection, signature verification, or integrity checks. If the distribution channel, hosting, or network path is compromised, arbitrary code can run in the user's environment, and this skill's wallet/trading context makes compromise especially sensitive because it may expose configs, tamper with trading logic, or install malware targeting crypto activity.
#!/bin/bash
# Web3 Trader Skill Installer
# Usage: curl -fsSL install.sh | bash
set -e
The '| bash' pattern is a direct command-chaining anti-pattern that removes any opportunity for user review and amplifies the risk of remote script execution. In a web3 trading skill, this is more dangerous than usual because users may run it on machines with wallets, exchange credentials, API keys, and other high-value assets that an attacker could target immediately.
#!/bin/bash
# Web3 Trader Skill Installer
# Usage: curl -fsSL install.sh | bash
set -e
The authentication section documents server-held signing keys while the manifest advertises zero-custody and agent-wallet safety, creating a materially misleading trust boundary. In a trading skill, users may authorize actions under false assumptions, increasing the risk of unauthorized order placement, account abuse, or loss if the MCP server or its operators are compromised.
The spec directly contradicts the skill's zero-custody claim by stating that write operations use an agent key stored on the MCP server per user. This creates a custodial signing model where compromise, misuse, or insufficient authorization controls on the server could lead to unauthorized trades despite user expectations that private keys never leave their wallet.
The service embeds apiKey directly into generated client-side HTML/JavaScript, making the credential available to any user who loads the page and to any script running in that origin. In a web3 trading context, this is especially dangerous because the page also submits signed order data to a backend, so exposed credentials can be reused to spam, impersonate the application, exhaust quotas, or access protected submission APIs.
The examples show leveraged market orders, position viewing, and one-click closing in a way that reads as routine CLI usage, without an explicit warning that these commands can affect live funds irreversibly and that leverage can amplify losses or trigger liquidation. For a trading skill, omission of those warnings is security-relevant because users may treat examples as safe defaults and execute dangerous actions in production accounts.
The README states that a user can sign approveAgent once and then allow the AI agent to trade autonomously, but it does not pair that capability with a clear, prominent warning about ongoing authority, loss of funds, liquidation risk, or the difficulty of noticing unwanted future trades. In a real-money trading skill, especially one supporting perpetuals and leverage, minimizing the warning surface materially increases the chance that users grant durable trading authority without understanding the consequences.
The documented risk-control policy explicitly permits trades under $100 to auto-execute, which is autonomous decision making over real financial assets. Even if the per-trade amount is limited, repeated small trades can accumulate meaningful losses, and in the context of perpetuals and agent authorization, this lowers the barrier to unintended or manipulated execution.
| Trade Value | Confirmation Required |
|-------------|----------------------|
| < $100 | Auto-execute |
| $100 – $999 | Single confirmation |
| ≥ $1000 or ≥ 10x leverage | Double confirmation |