T09 · Insecure Skill Coding Practices
- Location
index.mjs:140- Finding
Live order fills are not tracked, rendering the stop-loss ineffective
- Content
View full analysis
= MAKER_SPREAD) upFilled = true if (!dnFilled && curDn.bid >= MAKER_SPREAD) dnFilled = true } if (timedOut && !expired) { if (!upFilled && LIVE_TRADING) await clob.cancelOrder(upOrderId).catch(() => {}) if (!dnFilled && LIVE_TRADING) await clob.cancelOrder(dnOrderId).catch(() => {}) if (!upFilled && !dnFilled) { return { status: "SKIPPED", asset: assetKey, pnl: 0 } } } ``` The resulting PnL is only applied when a cycle reports success: ```js let cyclePnL = 0 for (const result of results) { if (result.status === "SUCCESS") { cyclePnL += result.pnl totalTrades++ } } currentBalance += cyclePnL ``` ### Technical Analysis Order-fill simulation is performed only when `LIVE_TRADING` is false. In live mode, neither `upFilled` nor `dnFilled` is updated through an authenticated order-status, trade, or fill query. After the timeout, the code attempts to cancel both orders and suppresses cancellation errors. It then returns `SKIPPED` with zero PnL because both fill flags remain false. This can happen even if one or both orders were fully or partially executed before cancellation. As a result, live executions, partial fills, cancellation races, and cancellation failures are not reflected in the local PnL calculation. The drawdown calculation therefore cannot reliably trigger the advertised 8% stop-loss. ### Attack Path 1. A user enables `LIVE_TRADING=true` and supplies a funded wallet private key. 2. The process submits sell orders to Polymarket. 3. One or both orders are fully or partially filled within the cancellation window. 4. The impl ...[truncated 1165 chars]- Remediation
View remediation
