Polymarket Quant Trader

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:32 AM UTC
• Version: 1.0.0

Overview

This skill is a coherent Polymarket trading guide, but it directs users toward unaudited external bot code, raw wallet-key handling, and automated trading workflows that need careful review before use.

Install only if you are prepared to audit the separate bot repository and dependencies before running npm install or adding any secrets. Use a dedicated low-balance wallet, keep DRY_RUN enabled until verified, avoid storing raw private keys in the repo, restrict any exchange API keys, and manually review every live trade or strategy change.

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

Error

• Location: README.md:16
• Finding: Unauditable External Repository and Unsafe Dependency Installation Workflow<![CDATA[ ## Vulnerability Details **File Location**: `README.md:16-20` **Vulnerability Type**: Supply-chain exposure through an unspecified external repository and npm installation **Risk Level**: High ### Vulnerable Code ```bash git clone <repo-url-provided-after-purchase> cd polymarket-bot npm install cp .env.example .env ``` ### Technical Analysis The audited package does not include the advertised trading bot, its `package.json`, a dependency lockfile, or its TypeScript source. Instead, users are directed to clone an unspecified repository supplied after purchase and execute `npm install`. The repository URL, owner, revision, release digest, and dependency versions are not pinned in the reviewed material. Consequently, the code ultimately installed and executed can differ from the content reviewed during this audit. In addition, `npm install` can execute package lifecycle scripts such as `preinstall`, `install`, and `postinstall`, giving dependencies an opportunity to run arbitrary commands with the invoking user's privileges. This is a supply-chain risk rather than proof that the external repository is malicious. The absence of the repository and dependency metadata prevents verification of the executable component advertised by the Skill. ### Attack Path 1. A user installs the documentation-only Skill and receives a mutable external repository URL after purchase. 2. The repository, one of its dependencies, or a dependency release is compromised or replaced. 3. The user runs `npm install` as instructed. 4. A malicious npm lifecycle script executes under the user's local account. 5. The script can read files accessible to that account, alter the bot, access subsequently configured environment secrets, or establish unauthorized network communication. 6. When the user runs the trading bot, modified code may submit unauthorized transactions or disclose credentials. ### Impact Assessment Successful exploitation would obtain the privileges of the user ...[truncated 545 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Include the complete executable source, `package.json`, and lockfile in the auditable package. 2. Publish the official repository URL and pin installation instructions to a reviewed commit hash or signed release tag. 3. Pin exact dependency versions and enforce lockfile integrity with `npm ci`. 4. Review all direct and transitive dependency lifecycle scripts before permitting their execution. 5. Perform an initial installation with lifecycle scripts disabled, such as `npm ci --ignore-scripts`, and explicitly enable only scripts demonstrated to be necessary. 6. Generate and verify release checksums or signatures. 7. Add automated dependency, provenance, and secret scanning to the release process. 8. Do not ask users to configure wallet or exchange credentials until the installed source and dependencies have been verified. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:449
• Finding: Plaintext Wallet Private Key and Exchange Credential Configuration<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:449-468` **Vulnerability Type**: Plaintext storage of transaction-signing and exchange credentials **Risk Level**: High ### Vulnerable Code ```bash Copy `.env.example` to `.env` and fill in: ```bash # Required for live trading POLYGON_WALLET_PRIVATE_KEY=your_polygon_private_key POLYMARKET_FUNDER_ADDRESS=your_funder_address POLYMARKET_API_URL=https://gamma-api.polymarket.com POLYMARKET_CLOB_URL=https://clob.polymarket.com # Risk management STARTING_CAPITAL=1000 MAX_POSITION_SIZE=500 MAX_TOTAL_EXPOSURE=2000 MIN_EDGE_THRESHOLD=0.10 STOP_LOSS_PERCENT=5 TAKE_PROFIT_PERCENT=5 # Optional: CEX for hedging BINANCE_API_KEY= BINANCE_API_SECRET= ``` The corresponding setup workflow in `README.md:19-23` is: ```bash npm install cp .env.example .env ``` ```text Configure your `.env` with wallet keys and risk parameters ``` ### Technical Analysis The setup guide directs users to place a Polygon wallet private key and optional Binance credentials in a plaintext `.env` file inside the project directory. A raw wallet private key grants transaction-signing authority and is materially more sensitive than a conventional revocable API token. The documentation does not specify: - Restrictive filesystem permissions for `.env`. - A required `.gitignore` rule. - Log and diagnostic redaction. - Use of a secret manager or external signing service. - Use of a dedicated, low-value trading wallet. - Withdrawal-disabled and scope-restricted exchange credentials. - Credential rotation and incident-response procedures. This is particularly risky because the code intended to consume these credentials is located in an external repository that was not included in the audit. The documented network access to Polymarket and 1WIN is relevant to market scanning, but no supplied executable code proves that secrets are transmitted. The vulnerability is therefore the insecure secret-handling workflow, not confirmed exfiltration. # ...[truncated 1123 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Avoid raw private keys where possible; use a hardware wallet, external signer, managed key vault, or narrowly scoped signing service. 2. Use a dedicated trading wallet containing only the minimum capital required for the strategy. 3. Store secrets outside the repository and retrieve them at runtime from an operating-system keychain or secret manager. 4. If `.env` remains supported: - Add `.env` and all variants containing secrets to `.gitignore`. - Set owner-only permissions, such as mode `0600`. - Fail safely if permissions are too broad. - Never print environment values in logs, errors, or diagnostics. 5. Require exchange API keys to have only necessary trading permissions and explicitly disable withdrawals. 6. Document credential rotation, wallet migration, and incident-response procedures. 7. Separate market-data access from transaction signing so scanners do not receive private keys. 8. Require explicit confirmation and transaction previews before live execution. 9. Audit the complete external bot and all dependencies before loading any wallet credential. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/brier-score-explained.md:38
• Finding: Invalid Brier-Score Calculation Can Corrupt Automated Trading Optimization<![CDATA[ ## Vulnerability Details **File Location**: `references/brier-score-explained.md:38-42` **Vulnerability Type**: Financial model integrity and input-validation defect **Risk Level**: Medium ### Vulnerable Code ```typescript // From research/evaluate.ts const brierScore = predictions.reduce((sum, p) => { const outcome = p.resolvedYes ? 1 : 0; return sum + Math.pow(p.ourProbability - outcome, 0.2); }, 0) / predictions.length; ``` ### Technical Analysis The same document correctly defines the Brier score as: ```text Brier = mean((predicted_probability - actual_outcome)^2) ``` However, the purported implementation raises the prediction error to `0.2` rather than `2`. This has two serious correctness consequences: 1. Positive errors are transformed using a fifth-root-like operation rather than squared error, so the result is not a Brier score. 2. For a negative base, JavaScript's `Math.pow(base, 0.2)` generally returns `NaN` because the exponent is fractional. Predictions for resolved-YES outcomes commonly produce negative values for `ourProbability - 1`. The Skill states that this score controls an automated hill-climbing optimizer that retains or reverts strategy mutations and may deploy the resulting strategy. A non-finite or mathematically invalid objective can therefore corrupt model selection and invalidate reported performance claims. The executable `research/evaluate.ts` file was not supplied, so the audit cannot determine whether the external implementation contains the same defect or whether this is limited to documentation. ### Attack Path 1. The evaluation set contains a resolved-YES market with `ourProbability` below `1`. 2. The expression `p.ourProbability - outcome` becomes negative. 3. `Math.pow(negativeValue, 0.2)` produces `NaN`. 4. The aggregate Brier score becomes `NaN`, or otherwise fails to represent squared prediction error. 5. Optimizer comparisons no longer reliably determine whether a mutation improved the strategy. ...[truncated 736 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Correct the exponent: ```typescript const brierScore = predictions.reduce((sum, p) => { const outcome = p.resolvedYes ? 1 : 0; const error = p.ourProbability - outcome; return sum + Math.pow(error, 2); }, 0) / predictions.length; ``` 2. Validate that every probability is finite and within `[0, 1]`. 3. Reject empty prediction arrays to avoid division by zero. 4. Reject optimizer results when the score is `NaN`, infinite, or outside the valid Brier range `[0, 1]`. 5. Add unit tests using known examples for both YES and NO resolutions. 6. Compare the implementation against an independently calculated reference score. 7. Prevent automatic checkpointing or live deployment unless all metric-validation tests pass. 8. Recompute all historical performance claims and optimizer checkpoints after applying the correction. 9. Keep live trading disabled until corrected results have passed out-of-sample and paper-trading validation. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (3)

Credential Access

High

• Category: Privilege Escalation

Content

git clone <repo-url-provided-after-purchase>
cd polymarket-bot
npm install
cp .env.example .env
```

4. Configure your `.env` with wallet keys and risk parameters (see SKILL.md Setup Guide)

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The trigger list is broad enough to activate on many generic finance or betting-related requests, which can cause the skill to run outside the user's precise intent. In this skill's context, unintended activation is more concerning because the skill is oriented toward trading, wallet usage, and automated decision support, so accidental invocation could lead users toward risky financial actions or disclosure of sensitive configuration details.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The file defines Brier score correctly as mean squared error, but the example implementation raises the error term to 0.2 instead of 2. This silently changes the optimization objective used by the trading/research system, making model evaluation and parameter tuning inconsistent with the documented metric and likely distorting calibration judgments and position sizing decisions.

Static analysis

No suspicious patterns detected.