Uniswap Agent Otc Trade

• Outcome: Review
• Latest audit: Sep 10, 2026 · 4:46 PM UTC
• Version: 0.1.0

Overview

The skill is not clearly malicious, but it handles real crypto trades while overstating settlement guarantees and leaving important safety and audit behavior under-specified.

Review carefully before installing. Treat this as a tool for user-confirmed Uniswap swaps, not guaranteed bilateral OTC settlement. Do not rely on the counterparty being forced to execute, require a fresh safety check and wallet confirmation before any transaction, verify token addresses and chains manually, and prefer pinned installation sources over the documented mutable commands.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: README.md:8
• Finding: Installation Commands Execute Unpinned Third-Party Dependencies<![CDATA[ ## Vulnerability Details **File Location**: `README.md:8-18` **Vulnerability Type**: Unpinned and mutable third-party installation sources **Risk Level**: Medium ### Vulnerable Code ```bash npx skills add https://github.com/wpank/Agentic-Uniswap/tree/main/.ai/skills/agent-otc-trade ``` ```bash npx clawhub@latest install agent-otc-trade ``` ### Technical Analysis The documented installation process uses `npx` to execute third-party tooling without pinning it to an audited version. The second command explicitly selects `clawhub@latest`, whose effective code may change at any time. The first command installs from a GitHub branch path rather than an immutable commit. Neither command provides a commit hash, package version lock, checksum, signature, or other integrity verification. Consequently, the code executed by future users can differ from the code that was reviewed during this audit. This creates a software supply-chain risk. Compromise of the npm publisher account, package registry, GitHub account, repository branch, or upstream release process could turn the documented installation commands into a remote code-execution channel. ### Attack Path 1. An attacker compromises an upstream npm publisher, registry package, GitHub account, or repository. 2. The attacker publishes a malicious `latest` package version or modifies the referenced repository branch. 3. A user follows the installation instructions in `README.md`. 4. `npx` retrieves and executes the mutable third-party installer. 5. Malicious code runs under the operating-system account that invoked the command. ### Impact Assessment Successful exploitation could execute arbitrary code with the privileges of the installing user. Depending on that account's permissions, the attacker could access project files, environment variables, API credentials, wallet-related configuration, SSH credentials, and other user-accessible data. The commands do not directly establish administrative privi ...[truncated 185 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace `@latest` with an explicitly audited package version. 2. Pin the GitHub installation source to a full immutable commit SHA rather than a branch. 3. Publish and verify cryptographic integrity hashes or signed release artifacts. 4. Document the expected package name, version, commit, and checksum together. 5. Recommend installation from a lockfile-controlled environment. 6. Review package lifecycle scripts and disable unnecessary installation scripts where supported. 7. Advise users not to run the installer with administrative or otherwise elevated privileges. For example, use an immutable source in the following conceptual form: ```bash npx clawhub@<AUDITED_VERSION> install agent-otc-trade npx skills add https://github.com/wpank/Agentic-Uniswap/tree/<FULL_COMMIT_SHA>/.ai/skills/agent-otc-trade ``` The placeholders should be replaced with versions and commits that have been independently reviewed. ]]>

other

Warning

• Location: SKILL.md:23
• Finding: Pool Swaps Are Misrepresented as Atomic Bilateral OTC Settlement<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:23-39` and `SKILL.md:303-311` **Vulnerability Type**: Misleading financial transaction semantics **Risk Level**: Medium ### Vulnerable Documentation The overview claims: ```text 3. Atomic settlement: Trades settle through Uniswap pools in a single transaction. No escrow risk, no counterparty default risk, no partial fills. The pool provides guaranteed liquidity at the agreed price. ``` The important notes later clarify: ```text - **Settlement happens through Uniswap pools, not peer-to-peer.** Both agents interact with the Uniswap pool independently. This means the trade is atomic and trustless -- neither party can default. - **The counterparty does not need to be online simultaneously.** Since settlement is through a pool, your agent executes its side of the trade independently. The "OTC" aspect is the agreed-upon terms and counterparty verification, not a literal peer-to-peer atomic swap. ``` The specification finally states: ```text - **This skill settles YOUR side of the trade.** The counterparty agent is responsible for their own execution. In practice, both agents use this skill independently to settle their respective sides through the same Uniswap pool. ``` ### Technical Analysis A normal Uniswap pool swap atomically exchanges the initiating user's assets with pool liquidity. It does not atomically bind the named counterparty to a corresponding transaction. According to the specification itself, each agent independently executes its own side. There is no described smart contract, escrow, signed order pair, transaction bundle, or cross-transaction condition that requires both agents to execute the negotiated terms. Counterparty identity verification also does not create this missing settlement linkage. The statements that neither party can default and that the transaction constitutes atomic OTC settlement therefore conflict with the actual workflow. At most, each individual pool ...[truncated 1322 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove claims that the overall bilateral trade is atomic or immune to counterparty default. 2. Clearly distinguish between: - Atomic execution of one user's swap against a liquidity pool; and - Atomic settlement of obligations between two identified counterparties. 3. Rename the workflow as an independently executed, counterparty-referenced market swap unless genuine bilateral settlement is implemented. 4. Before confirmation, display an explicit warning that: - The named counterparty is not a party to the user's Uniswap transaction. - Identity verification does not guarantee counterparty execution. - The counterparty may execute later, on different terms, or not at all. 5. If atomic OTC settlement is required, implement an appropriate on-chain mechanism that binds both parties, assets, amounts, deadlines, and minimum outputs into one conditional settlement. 6. Ensure cross-chain documentation also explains latency, solver, finality, and failure assumptions rather than implying same-transaction atomicity across chains. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:220
• Finding: Declared Safety-Status Check Is Not Enforced Before Asset Execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:8-17`, `SKILL.md:220-241`, and `SKILL.md:327-333` **Vulnerability Type**: Missing mandatory pre-execution safety gate **Risk Level**: Medium ### Vulnerable Configuration and Workflow The skill declares a safety-status tool: ```yaml allowed-tools: - Task(subagent_type:trade-executor) - Task(subagent_type:identity-verifier) - mcp__uniswap__get_quote - mcp__uniswap__get_token_price - mcp__uniswap__get_pool_info - mcp__uniswap__get_agent_balance - mcp__uniswap__execute_swap - mcp__uniswap__submit_cross_chain_intent - mcp__uniswap__check_safety_status ``` However, the settlement instructions delegate execution without requiring that safety tool: ```text ### Step 4: Settlement Delegate to `Task(subagent_type:trade-executor)`: **For direct-swap settlement:** Execute this OTC trade settlement: - Sell: {amount} {tokenSell} - Buy: {tokenBuy} - Chain: {chain} - Slippage tolerance: based on OTC terms - Context: This is an OTC trade with counterparty {counterpartyAgent} (ERC-8004 verified, reputation {score}/100). Settle through the {fee}% pool. ``` The error table anticipates a safety failure: ```text | Safety check failed | "Trade exceeds safety limits." | Check spending limits with check-safety | ``` ### Technical Analysis The configuration makes `mcp__uniswap__check_safety_status` available, and the error table describes a safety-check failure, but the normative settlement workflow never requires the tool to be called before `execute_swap` or `submit_cross_chain_intent`. As written, an implementation can fully comply with Step 4 while proceeding directly from user confirmation to delegated execution. User confirmation is important but does not replace automated enforcement of configured spending limits or transaction-safety policies. Because the safety check is optional rather than a fail-closed gate, failure to ca ...[truncated 1119 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Add a mandatory `mcp__uniswap__check_safety_status` call immediately before every direct swap and cross-chain intent submission. 2. Make the check fail closed: - Do not execute if the check fails. - Do not execute if the safety service is unavailable. - Do not silently treat an unknown result as safe. 3. Pass the final resolved chain, token addresses, amounts, recipient or destination, slippage, route, approvals, and estimated fees to the safety check. 4. Compare the checked parameters with the parameters actually submitted for execution. 5. Require fresh user confirmation if any material parameter changes after the safety check, including output amount, slippage, route, chain, fees, or token address. 6. Apply explicit spending and notional-value limits independently of counterparty reputation. 7. Record the safety decision and checked transaction parameters in the audit trail. 8. State whether `trade-executor` performs additional validation; do not rely on undocumented subagent behavior. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (8)

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The README promotes OTC token trading, identity verification, and cross-chain settlement but does not warn users about irreversible on-chain transactions, smart contract risk, slippage, bridge/intents risk, or the possibility of financial loss. In a crypto trading skill, omission of these warnings can mislead users into treating the workflow as routine automation and increases the chance of unsafe or uninformed execution.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 94% confidence
• Finding: The README instructs users to run `npx skills add` without pinning a version or commit, which allows whatever package/version is current at execution time to be fetched and run. Because this is an installation path for an agent skill that can influence subsequent behavior, a compromised or malicious upstream package or changed repository state could lead to supply-chain execution of unreviewed code.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 95% confidence
• Finding: The command `npx clawhub@latest install agent-otc-trade` explicitly tracks the latest published version, which can change over time and execute newly published code without user review. In a security-sensitive crypto/agent workflow, this increases supply-chain risk because an attacker who compromises the package or publishing pipeline could deliver arbitrary code at install time.

External Model or Provider Selection

Medium

• Category: Excessive Agency

Content

agent, settle an agent-to-agent trade through Uniswap, or execute an OTC
  swap with a specific counterparty agent. Verifies counterparty identity via
  ERC-8004, negotiates terms, and settles through Uniswap pools.
model: opus
allowed-tools:
  - Task(subagent_type:trade-executor)
  - Task(subagent_type:identity-verifier)

• Confidence: 90% confidence
• Finding: Skill selects an external model or provider that may use a different account or billing plan than the operator expects. Undisclosed model switches can cause unexpected cost or quota consumption.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The skill markets itself as facilitating agent-to-agent OTC trading with negotiated terms, identity-based trust, and an audit trail, but the described implementation only performs the user's own Uniswap swap. This mismatch can mislead users into believing there is coordinated bilateral settlement or recorded evidence of an agreed trade when neither is actually enforced, creating operational and financial risk.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The skill promises that every OTC trade is recorded and logged, but no allowed tool or workflow step can actually persist trade history. Users may rely on nonexistent records for dispute resolution, compliance, or reputation, leading to false assurances and failed forensic/audit expectations.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill states that it records counterparty identity, agreed terms, settlement transaction, and fees, but does not clearly warn users or provide consent and opt-out controls. In a financial context, this can expose sensitive transactional metadata and counterpart relationships without adequate privacy notice.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: Presenting universal trade logging as a feature rather than a warning normalizes data collection without informing users of privacy implications. Because OTC trading involves financial counterparties and transaction details, undisclosed or non-consensual logging increases confidentiality and compliance risk.

Static analysis

No suspicious patterns detected.