Polymarket Candle Volume Spike Trader

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:01 AM UTC
• Version: 0.0.3

Overview

This skill is transparent about being a Polymarket trading bot, but some documented live-trading safeguards are not actually enforced as described.

Review carefully before enabling live mode. Use a scoped or limited SIMMER_API_KEY if available, keep the default paper mode until you understand the strategy, and do not rely on the documented min-volume or max-open-position settings as account-wide risk controls without fixing or independently verifying them.

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)

T09 · Insecure Skill Coding Practices

Warning

• Location: trader.py:347
• Finding: Declared market-volume and portfolio-exposure safeguards are not enforced<![CDATA[ ## Vulnerability Details **File Location**: `trader.py:29-30, 347-415` and `clawhub.json:36-47, 75-86` **Vulnerability Type**: Missing enforcement of configured risk controls **Risk Level**: Medium The project declares `SIMMER_MIN_VOLUME` as a minimum market-volume filter and `SIMMER_MAX_POSITIONS` as a maximum concurrent open-position limit. However, the trading flow never checks market volume, and `MAX_POSITIONS` only limits successful orders placed during the current process invocation. ### Complete Code Snippet Configuration values are loaded in `trader.py`: ```python MIN_VOLUME = float(os.environ.get("SIMMER_MIN_VOLUME", "3000")) MAX_POSITIONS = int(os.environ.get( "SIMMER_MAX_POSITIONS", "8")) ``` The configuration describes these values as market-volume and open-position safeguards: ```json { "env": "SIMMER_MIN_VOLUME", "type": "number", "default": 3000, "range": [ 0, 500000 ], "step": 1000, "label": "Min market volume (USD)" } ``` ```json { "env": "SIMMER_MAX_POSITIONS", "type": "number", "default": 8, "range": [ 1, 20 ], "step": 1, "label": "Max open positions" } ``` The live order loop only counts orders successfully placed during the current run: ```python placed = 0 for date_str, spike_time, spike_dir, spike_count, spike_coins in spikes: if placed >= MAX_POSITIONS: break # Find the next 5-min window (spike_time + 5 minutes) next_time = spike_time + 5 next_key = (date_str, next_time) next_window = by_window.get(next_key, {}) if not next_window: safe_print( f" [{date_str} {spike_time//60}:{spike_time%60:02d}] " f"no next window at +5min" ) continue # Find coins in the next window that haven't caught up for coin, m in next_window.items(): if placed >= MAX_POSITIONS: break p = float(m.current_probability) # Check if this coin is lagging (not ye ...[truncated 4017 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Retrieve authoritative market-volume data before signal evaluation and reject markets whose volume is unavailable or below `MIN_VOLUME`. 2. Query current open positions and pending orders from the trading venue before placing any order. 3. Calculate remaining capacity using account-wide state, for example: `remaining = MAX_POSITIONS - existing_open_positions - pending_open_orders`. 4. Stop trading when `remaining <= 0`, and decrement the remaining capacity only after verifying the resulting account state. 5. Consider enforcing a maximum total USDC exposure in addition to a position-count limit. 6. Fail closed in live mode if volume, portfolio, or pending-order data cannot be retrieved. 7. Prevent overlapping scheduler executions with a process lock or an account-level atomic reservation mechanism. 8. Rename the setting if it is intentionally a per-run order limit; otherwise, update the implementation so that it matches the documented “Max open positions” behavior. 9. Add tests covering pre-existing positions, repeated invocations, pending orders, missing volume data, and below-threshold markets. ]]>

T08 · Insecure Dependencies

Note

• Location: clawhub.json:5
• Finding: Third-party trading SDK is installed without a version or integrity pin<![CDATA[ ## Vulnerability Details **File Location**: `clawhub.json:5-8` **Vulnerability Type**: Unpinned security-sensitive dependency **Risk Level**: Low ### Complete Code Snippet ```json "requires": { "env": [ "SIMMER_API_KEY" ], "pip": [ "simmer-sdk" ] } ``` ### Technical Analysis The package requirement specifies only the distribution name `simmer-sdk`. It does not constrain the package to an audited version and does not provide an integrity hash. Dependency resolution at installation time can therefore select a future release different from the one reviewed during this audit. This dependency is security-sensitive because the Skill passes `SIMMER_API_KEY` to `SimmerClient`, and the SDK is responsible for market communication and live order handling. The audit found no evidence that the currently intended package is malicious. The weakness is the absence of reproducible dependency selection and integrity verification, which increases exposure to upstream compromise, malicious releases, or incompatible behavioral changes. ### Attack Path 1. An attacker compromises the upstream package publication account or otherwise causes a malicious future version of `simmer-sdk` to be distributed. 2. A new installation or environment rebuild resolves the unpinned requirement to that version. 3. The malicious package is imported by `trader.py`. 4. During client initialization, the package receives the `SIMMER_API_KEY`. 5. The compromised dependency can misuse the credential, alter market responses, modify live order parameters, or transmit sensitive trading data using the process's existing permissions. This path depends on a supply-chain compromise or unsafe future release; no direct dependency-confusion condition was confirmed from the reviewed files. ### Impact Assessment A compromised dependency would execute with the same privileges as the Skill process. Its potential scope includes: - Access to `SIMMER_API_KEY` and other environment variab ...[truncated 474 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `simmer-sdk` to an exact version that has been reviewed, such as `simmer-sdk==X.Y.Z`. 2. Use a lock file that records transitive dependency versions. 3. Require package hashes during installation, such as a hash-locked requirements file used with `pip --require-hashes`. 4. Obtain dependencies only from an explicitly configured, trusted package index. 5. Review release notes and source changes before updating the pinned version. 6. Run dependency vulnerability and provenance checks in CI. 7. Restrict the runtime account and environment so the SDK receives only the credentials and filesystem permissions required for trading. 8. Scope and rotate `SIMMER_API_KEY` where supported, particularly after any suspected dependency compromise. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill references a high-value credential (`SIMMER_API_KEY`) and describes live trading capability, but it does not declare any explicit tool scope such as `permissions` or `allowed-tools`. That creates an authorization ambiguity: an agent/runtime may grant broader environment or tool access than the skill actually needs, increasing the chance of credential exposure or unintended trading actions if the skill is executed in a permissive environment.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The manifest declares a required API key and configures a managed trading automaton, but provides no user-facing disclosure that credentials will be used to automate market actions. In a trading context, this increases the risk of users enabling the skill without understanding it can place trades with their account, which can lead to financial loss or unintended credential exposure if the platform’s permission model is misunderstood.

Static analysis

No suspicious patterns detected.