Polymarket Space Trader

• Outcome: Review
• Latest audit: Sep 12, 2026 · 12:59 AM UTC
• Version: 0.0.3

Overview

This skill is mostly transparent and defaults to paper trading, but its live trading path has enough financial-risk concerns to require review before installation.

Install only if you are comfortable reviewing the trading code and dependency yourself. Use paper mode first, avoid live-capable keys in automated environments, restrict the API key and account funds, and treat the advertised minimum-volume filter as not currently enforced.

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 (2)

T08 · Insecure Dependencies

Warning

• Location: clawhub.json:5
• Finding: Unpinned Privileged Third-Party Dependency## Vulnerability Details **File Location**: `clawhub.json:5-9` **Vulnerability Type**: Supply-chain exposure through an unpinned dependency **Risk Level**: Medium ### Vulnerable Code ```json "requires": { "env": [ "SIMMER_API_KEY" ], "pip": [ "simmer-sdk" ] } ``` The dependency is also described in `SKILL.md:136-140`: ```markdown ## Dependency `simmer-sdk` is published on PyPI by Simmer Markets. - PyPI: https://pypi.org/project/simmer-sdk/ - GitHub: https://github.com/SpartanLabsXyz/simmer-sdk - Publisher: [e-mail] Review the source before providing live credentials if you require full auditability. ``` ### Technical Analysis The project installs `simmer-sdk` without an exact version constraint or integrity hash. Consequently, separate installations can resolve to different package releases, including releases published after this project was audited. This dependency is security-sensitive because `trader.py` imports `SimmerClient` from it, supplies it with `SIMMER_API_KEY`, and uses it to submit simulated or live financial trades. Code in the dependency executes in the same Python process and therefore inherits access to the API credential, environment variables, network connectivity, and the trading workflow. The audit found no evidence that the current dependency is malicious. The vulnerability is the absence of controls that guarantee installation of the reviewed dependency version. ### Attack Path 1. An attacker compromises the dependency publisher account, package repository, release pipeline, or an otherwise trusted future release. 2. The attacker publishes a modified `simmer-sdk` version containing malicious initialization or client behavior. 3. A user installs or reinstalls the skill after that release becomes available. 4. Because no version or hash is pinned, the package installer resolves and installs the modified release. 5. `trader.py` imports t ...[truncated 780 chars]
• Remediation: ## Remediation Suggestions 1. Pin `simmer-sdk` to an exact, reviewed version rather than accepting the latest available release. 2. Use a lock file or hash-checked requirements file so installation fails when package contents do not match approved artifacts. 3. Review release changes before updating the pinned version. 4. Install dependencies from a controlled package index or approved artifact repository where possible. 5. Run the trader under a dedicated, least-privileged account with only the required environment variables. 6. Use a restricted API key with minimal trading authority and rotate it if dependency compromise is suspected. 7. Apply transaction limits and server-side controls that cannot be overridden by dependency code.

T09 · Insecure Skill Coding Practices

Warning

• Location: trader.py:215
• Finding: Declared Minimum Market Volume Safeguard Is Not Enforced## Vulnerability Details **File Location**: `trader.py:215-246` **Vulnerability Type**: Missing enforcement of a documented financial risk control **Risk Level**: Medium ### Vulnerable Code `MIN_VOLUME` is configured at `trader.py:26`: ```python MIN_VOLUME = float(os.environ.get("SIMMER_MIN_VOLUME", "2500")) ``` However, the trading loop at `trader.py:215-246` never checks a market's volume against that value: ```python def run(live: bool = False) -> None: mode = "LIVE" if live else "PAPER (sim)" print(f"[polymarket-space-trader] mode={mode} max_pos=${MAX_POSITION} min_vol=${MIN_VOLUME} max_spread={MAX_SPREAD:.0%} min_days={MIN_DAYS}") client = get_client(live=live) markets = find_markets(client) print(f"[polymarket-space-trader] {len(markets)} candidate markets") placed = 0 for m in markets: if placed >= MAX_POSITIONS: break side, size, reasoning = compute_signal(m) if not side: print(f" [skip] {reasoning}") continue ok, why = context_ok(client, m.id) if not ok: print(f" [skip] {why}") continue try: r = client.trade( market_id=m.id, side=side, amount=size, source=TRADE_SOURCE, skill_slug=SKILL_SLUG, reasoning=reasoning, ) tag = "(sim)" if r.simulated else "(live)" status = "OK" if r.success else f"FAIL:{r.error}" print(f" [trade] {side.upper()} ${size} {tag} {status} — {reasoning[:70]}") if r.success: placed += 1 except Exception as e: print(f" [error] {m.id}: {e}") print(f"[polymarket-space-trader] done. {placed} orders placed.") ``` ### Technical Analysis The project documentation identifies minimum market vol ...[truncated 2318 chars]
• Remediation: ## Remediation Suggestions 1. Add an explicit volume check before signal calculation or trade submission: ```python volume = getattr(m, "volume", None) if volume is None: print(f" [skip] Missing market volume for {m.id}") continue if float(volume) < MIN_VOLUME: print(f" [skip] Volume ${float(volume):,.2f} below ${MIN_VOLUME:,.2f}") continue ``` 2. Confirm the authoritative field name and unit from the audited `simmer-sdk` API rather than assuming a property name. 3. Fail closed when volume is missing, malformed, stale, or expressed in an unexpected currency. 4. Validate executable order-book depth in addition to aggregate market volume. 5. Recalculate expected slippage for the proposed order amount immediately before submission. 6. Add tests proving that markets below the threshold and markets with unavailable volume cannot reach `client.trade()`. 7. Add an integration test confirming that changes made through `SIMMER_MIN_VOLUME` alter actual eligibility rather than only log output. 8. Consider enforcing account-level exposure and open-position limits independently of the count of successful orders in the current run.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 82% confidence
• Finding: The skill references environment-based credentials (`SIMMER_API_KEY`) and trading-related execution modes but does not declare any explicit tool scope or permissions boundary. In an agent ecosystem, this can lead to overbroad runtime access where the skill may inherit environment access implicitly, increasing the chance of credential exposure or unintended use of live trading authority.

Vague Triggers

Medium

• Confidence: 86% confidence
• Finding: The manifest enables a managed automaton with an entrypoint, but it does not declare any trigger scope, invocation policy, or operational constraints. In a trading skill, that ambiguity increases the risk of unintended autonomous execution, which could place trades or consume API-backed resources without sufficiently explicit guardrails.

Natural-Language Policy Violations

Low

• Confidence: 72% confidence
• Finding: Several user-facing labels hard-code USD, such as position size and market volume, which may impose a specific locale/currency assumption. There is no visible indication that users can choose another currency or that the USD constraint is intentionally documented as region-specific.

Static analysis

No suspicious patterns detected.