Security audit
Security checks for vulnerabilities and agentic risk
This treasury skill is mostly coherent and disclosed, but it can sign high-impact crypto transactions from hot-wallet keys while relying too much on third-party transaction payloads.
Install only if you are comfortable running a hot-wallet treasury tool. Use a low-balance dedicated wallet, strict allowlists, small limits, dry runs, reviewed provider URLs, and preferably a vault/KMS/HSM or delegated signer. Do not use this with a primary treasury key until transaction decoding, exact allowances, endpoint allowlists, and explicit operator approval are added.
src/services/swapService.ts:80Provider-Controlled Transaction Payloads Are Signed Without Intent Validation
src/config.ts:142Custom Provider Endpoints Can Receive API Keys and Return Malicious Transaction Data
The code broadly aligns with the stated treasury/trading purpose: it supports balance checks, guarded transfer/safety flows, bridging, Hyperliquid deposit and trading/account actions, and quoting. However, the implementation clearly includes Solana-specific services (SolanaWalletService, SolanaTokenService, SolanaBalanceService) and passes them into balance, bridge, and quote flows, which exceeds the declared EVM + Hyperliquid framing. Additionally, there is an explicit swap_token action backed by SwapService that is not mentioned in the description. The description also mentions destination gas top-ups, but that capability is not evident in this chunk; that omission alone is less significant than the undeclared Solana and swap functionality. Therefore this is a description/behavior mismatch.
The code’s primary purpose is cross-chain bridging: obtaining quotes, executing bridge transactions, polling bridge status, and suggesting destination gas amounts. It uses LI.FI for EVM-source bridging and Mayan for Solana-source bridging. While the declared description mentions cross-chain USDC bridging and gas top-ups, it also prominently claims broader treasury management and Hyperliquid trading/deposit functionality that are absent from this code chunk. Additionally, this implementation supports Solana bridging, which is broader/different than a description centered on EVM treasury ops and Hyperliquid trading. Therefore the description does not accurately represent what this supplied code actually does.
This code chunk is materially outside the declared purpose. The description focuses on EVM treasury operations and Hyperliquid trading workflows, but the implementation is exclusively a Solana read-only balance checker. It uses @solana/web3.js, Solana RPC URLs, SOL native balances, and SPL token account parsing. There is no evidence of EVM treasury management, token transfers, bridging, Hyperliquid deposits, trading, or quoting. While 'wallet balance checks' are mentioned generally in the description, the chain-specific implementation here is Solana, which is inconsistent with the declared EVM/Hyperliquid scope and therefore represents a description-behavior mismatch.
The declared description centers on EVM treasury operations and Hyperliquid trading functionality. The actual code is specifically a Solana balance-query helper: it resolves supported Solana tokens and reads SOL/SPL balances via Solana Web3 RPC. This is a materially different platform/resource focus from the declared EVM/Hyperliquid scope. While wallet balance checks are mentioned in the description, the code accesses Solana resources and implements only Solana token balance functionality, which is not accurately represented by the declared purpose.
The declared description is focused on EVM treasury operations and Hyperliquid trading, but the code is specifically for Solana wallet infrastructure. It accesses Solana-specific resources (@solana/web3.js, Solana RPC URLs, Solana private key material) and provides Solana transaction signing and confirmation capabilities that are not mentioned in the declared purpose. This is not merely a supporting implementation detail for the stated EVM/Hyperliquid functionality; it represents a materially different blockchain scope and capability set.
The code chunk is specifically a token swap executor (swapTokenTool). It performs treasury balance checks and safety/risk review, which are consistent with the general 'guarded' and 'trading safety' aspects of the description. However, the declared purpose lists wallet checks, guarded transfers, USDC bridging, Hyperliquid deposits, gas top-ups, native Hyperliquid trading, and structured quoting—but does not mention EVM token swaps via a swap service/router. This is not just an implementation detail: the tool can quote and execute an on-chain asset swap between two tokens, including liquidity checks and slippage handling, which is a distinct financial capability. Therefore the description does not accurately represent this code chunk's actual behavior.
This code chunk does not perform any of the declared treasury or trading operations. Its primary purpose is local logging infrastructure, using crypto for UUID generation and filesystem/path access to write and read runtime logs. That is materially different from the declared purpose. While logging could be a supporting detail in a larger system, this chunk itself is solely concerned with logging and filesystem I/O, with no evidence of EVM wallet management, token transfers, bridging, Hyperliquid interaction, or trading safeguards.
The skill requires a raw treasury private key in environment configuration and instructs users to place it in a local .env file during setup. In a treasury-management skill with networked transaction capabilities, compromise of that host, process, logs, or development environment could directly expose signing material and lead to irreversible loss of funds.
Recommended workflow:
cp .env.example .env
# fill in the treasury private key and optional RPC overrides
npm install
npm run build
The manifest description says the skill manages EVM treasury operations and Hyperliquid trading, including balance checks, guarded transfers, USDC bridging, Hyperliquid deposits, gas top-ups, trading safety, and structured quoting. However, the README states the skill also supports Solana balance checks, Solana-to-EVM bridging, and guarded ERC-20 swaps via 0x, which are material capabilities beyond the manifest's stated scope.
The skill exposes sensitive capabilities such as environment-secret access and outbound network operations, but it does not declare an explicit permission or allowed-tools scope in the manifest. In an agent environment, that increases the chance that the skill is granted broader capabilities than intended, especially given it handles treasury private keys and can initiate blockchain transactions.
This code file advertises and dispatches actions such as token transfers, swaps, bridging, deposits, and order placement/cancellation, all of which can affect funds or trigger irreversible operations. In this file there is no confirmation prompt and no user-facing warning describing those risks; the only visible output is a list of supported actions.
The EVM bridge execution path will automatically approve token spend and submit the provider-supplied transaction request using treasury funds, with no in-file confirmation, policy gate, or validation that the returned calldata matches an expected bridge action. In an agent setting, this is dangerous because a compromised/misconfigured quote provider or unsafe upstream invocation could trigger irreversible approvals and transfers to arbitrary contracts or routes.
The manifest describes EVM treasury operations and native Hyperliquid trading, with cross-chain USDC bridging as part of that scope. This file additionally implements a dedicated Solana bridge provider using Solana wallet signing and Mayan Solana bridging, which expands behavior beyond an EVM-only treasury/trading skill description.
The Solana path directly signs and submits a live Mayan swap/bridge transaction from the treasury wallet after fetching a quote, again without any explicit confirmation or independent transaction validation in this file. Because cross-chain swaps are irreversible and depend on external routing data, an unsafe caller, SDK compromise, or misrouted destination could result in immediate loss or misdelivery of treasury assets.
The code parses a Solana private key from configuration and instantiates a live signing keypair despite no disclosed Solana purpose in the skill description. Undisclosed key handling is dangerous because it can silently expand custody to an additional blockchain, and if this capability is reachable by the agent or downstream tools, funds on that Solana wallet could be signed away outside expected operator oversight.
This file provides Solana transaction signing and RPC confirmation capabilities even though the skill metadata claims the scope is limited to EVM treasury operations and Hyperliquid trading. Hidden cross-chain signing capability increases the attack surface and can enable unauthorized use of a loaded private key, especially in agent environments where tool scope and manifest claims are relied upon for trust and policy decisions.
The code constructs a request containing chain ID, token addresses, sell amount, taker address, and optional recipient, then transmits it to a third-party HTTP endpoint. This is a network operation involving user/system financial metadata, but the file provides no visible warning, comment, or user-facing notice about that external data transmission.
The execute path can trigger token allowance changes via ensureAllowance and submit a blockchain transaction via sendTransaction, which are safety-critical and potentially irreversible operations. In this file there is no confirmation prompt, logging, print statement, or explanatory comment/docstring warning the user that execution will approve tokens and broadcast a live transaction.
This code performs irreversible asset-affecting operations via sendTransaction and writeContract for token transfers and approvals, including granting maxUint256 allowance. Within this file there is no confirmation prompt, user-facing log/print, or explanatory comment/docstring warning that these actions will move funds or create a standing approval.
The constructor and requireAccount method load and depend on a private key from configuration, which is sensitive credential material. This file contains no comment, docstring, or user-visible disclosure explaining that the skill accesses signing credentials to execute wallet actions.
The sendTransaction method performs a blockchain transaction, which is an irreversible operation that can move funds or invoke contracts. In this file there is no confirmation prompt, user-facing log/print, or explanatory comment/docstring warning that the method will submit a live transaction.
The manifest describes the skill as managing EVM treasury operations and Hyperliquid trading, but this tool imports a Solana balance service and conditionally handles parsed.chain === "solana". Supporting Solana wallet balances is a substantive cross-ecosystem capability not reflected in the stated skill description.
This code fetches account state from an external trading service and logs the returned user identifier, but the file contains no confirmation prompt, user-facing notice, or explanatory comment/docstring about the network access and handling of account-related data. For a code file, network calls that may transmit or retrieve user/system data and access to potentially sensitive account information should have some visible disclosure unless clearly documented elsewhere.
This code logs details from the evaluated operation, including amount and destination, via logEvent. For a code file, network or logging of potentially sensitive transaction data should have some visible disclosure such as a user-facing message, comment, or documented warning, and none appears in this file.
Using caret version ranges for runtime dependencies allows newer package releases to be installed without explicit review, which can introduce breaking changes, vulnerable code, or even supply-chain compromise. In a treasury-operations skill that may handle wallets, transfers, and trading, dependency drift materially increases the risk of fund loss or key-handling compromise.
"node": ">=20.0.0"
},
"dependencies": {
"@mayanfinance/swap-sdk": "^13.2.0",
"@nktkas/hyperliquid": "^0.32.1",
"@solana/web3.js": "^1.98.4",
"bs58": "^6.0.0",
No suspicious patterns detected.