BTC Weekend Volatility Trader

Trades high-volatility Bitcoin weekend milestone markets with precise threshold-based resolution using Binance BTCUSDT as primary source.

Security Scan

The skill's code and purpose (paper/default trading via Simmer) are coherent, but there are multiple mismatches in metadata and environment variable naming that make it likely to misconfigure or fail; no direct signs of exfiltration, but fix/verification is required before use (especially with live funds).

Purpose & Capability

The skill's stated purpose (trading Polymarket BTC weekend threshold markets via Simmer) matches the included trader.py which uses a SimmerClient to discover markets and place trades. However, the registry-level metadata summary (the top-level 'Requirements' you provided) claims no required env vars or credentials, while clawhub.json and SKILL.md declare SIMMERAPIKEY (and pip dependency simmer-sdk). This discrepancy between claimed requirements and the actual files is an incoherence the user should resolve before trusting the skill.

Instruction Scope

Runtime instructions (SKILL.md) tell the user to run python trader.py and reference SIMMERAPIKEY and various SIMMER tunables. The code itself implements paper-vs-live behavior and respects a --live flag (good). However, the SKILL.md/clawhub.json names environment variables without underscores (e.g. SIMMERAPIKEY, SIMMERMAXPOSITION) while trader.py expects differently named env vars (SIMMER_API_KEY, SIMMER_MAX_POSITION, SIMMER_MIN_VOLUME, etc.). Those naming mismatches mean the runtime instructions do not align with the code and will likely cause crashes or unexpected defaults. The skill does not read or transmit data to any other external endpoints in the repository; all network I/O goes through SimmerClient.

Install Mechanism

There is no external download URL or installer; the project declares a pip requirement (simmer-sdk) in clawhub.json, which is a moderate-risk, typical dependency for an SDK-based trading skill. There are no arbitrary URL downloads or extracted archives in the bundle. The top-level 'Install specifications' claim none, but the clawhub.json pip requirement contradicts that — another metadata inconsistency to fix. Verify simmer-sdk provenance (PyPI owner, source repo) before installing.

Credentials

The skill legitimately requires a Simmer API key to trade, which is proportionate to its function. However: (1) the required env var name is inconsistently presented across files (SKILL.md/clawhub.json use SIMMERAPIKEY; trader.py requires SIMMER_API_KEY). (2) Tunable names declared in clawhub.json (SIMMERMAXPOSITION, SIMMERMINVOLUME, etc.) do not match code names (SIMMER_MAX_POSITION, SIMMER_MIN_VOLUME, etc.). These mismatches can cause sensitive credentials to be mis-set or default to safe/unsafe values. No unrelated credentials are requested, and there are no config path requests.

Persistence & Privilege

The skill does not request always:true and does not modify other skills or system-wide configuration. It is automaton-managed with an entrypoint trader.py but defaults to paper trading unless --live is given. Autonomous invocation (disable-model-invocation=false) is the platform default; it is not an additional red flag here.

What to consider before installing

This skill appears to implement the trading behavior it claims, but several metadata vs. code inconsistencies make it risky to run unmodified, especially with real money. Before installing or supplying credentials: - Do NOT provide a live SIMMER API key until you confirm the env var the code actually reads. The code expects SIMMER_API_KEY; clawhub.json and SKILL.md use SIMMERAPIKEY. Either set both names in a safe test environment or fix the mismatch in the files. - Fix the tunable env-name mismatches: clawhub.json declares SIMMERMAXPOSITION, SIMMERMINVOLUME, etc., while trader.py reads SIMMER_MAX_POSITION, SIMMER_MIN_VOLUME, etc. Align names or update code to read the declared names. - Run the skill in paper/sim mode only (python trader.py without --live) to validate behavior and ensure no crashes and expected market discovery/trading logic. - Inspect and verify the simmer-sdk package source (PyPI author, GitHub repo) before installing; use a sandbox or isolated environment (no real credentials). - Review apply_skill_config behavior: the code calls client.apply_skill_config(SKILL_SLUG) which may modify env vars — confirm this step is safe and inspect what it writes in a test run. - Only consider enabling live trading after successful paper-mode validation, verifying env names, and ensuring you understand how much USDC could be placed per trade via the tunables. Given these mismatches (registry metadata vs. clawhub.json vs. code), treat the skill as suspicious until those inconsistencies are resolved and you've verified it in a sandbox.

BTC Weekend Volatility Trader This skill targets ultra-high-volatility Bitcoin weekend milestone markets where the resolution hinges on a precise price threshold and a clearly specified primary data source (Binance BTCUSDT). It is designed for markets like: “Will Bitcoin trade above 150,000 USDT at any time between 2026-03-21 00:00 UTC and 2026-03-22 23:59 UTC?”, where resolution depends on whether the Binance BTCUSDT spot pair prints a last traded price strictly above 150,000.00 USDT at any timestamp in the interval.

Strategy Overview The core signal is a threshold-focused weekend volatility play: the skill looks for Polymarket markets whose questions encode a concrete BTCUSDT price level and a narrow time window that includes a weekend. It prefers markets where the resolution criteria reference a specific primary data source such as Binance BTCUSDT trade history, with fallback sources like archived Binance data or CoinGecko only if clearly consistent. The strategy then compares Polymarket’s implied probability to a volatility-informed prior for whether BTC will cross the specified level intra-window and trades when the market price is materially out of line with that prior.

Edge Thesis These markets systematically misprice the path-dependent nature of high-volatility BTC moves around weekends and hard thresholds. Traders tend to anchor on spot levels and underestimate both intraday spikes and the importance of “any time between” versus “close above” wording. There is additional edge in markets that explicitly name a primary resolution source (e.g., Binance BTCUSDT last traded price strictly above a level): arbitrage and market-making algos must track a single, well-defined feed, which reduces ambiguity risk but is often underappreciated in pricing. By focusing on markets with: (1) a clearly defined threshold (such as 150,000.00 USDT), (2) a strict inequality (“strictly above”), (3) a bounded weekend window (e.g., 2026-03-21 00:00 UTC to 2026-03-22 23:59 UTC), and (4) a specific resolution source (Binance BTCUSDT, with narrowly scoped backups), this skill can systematically exploit mispricings between realized/expected BTC volatility and market odds.

Remix Signal Ideas

• Wire in Binance or on-chain derived realized volatility metrics over recent weekends to calibrate crossing probabilities for similar distance-to-strike thresholds.
• Use funding rate and perp basis data to detect crowded positioning around psychological levels (e.g., 150k, 200k) and trade against overconfident market odds.
• Combine intraday BTC high/low range statistics with the exact resolution window length to estimate the chance of at least one price print above the threshold.
• Add a filter that prefers markets where resolution rules specify Binance BTCUSDT as primary source and clearly defined secondary sources (archived Binance data, CoinGecko) only if “clearly consistent”, reducing oracle and interpretation risk.
• Extend the logic to cluster related milestone markets (e.g., 140k, 150k, 160k in the same window) and ensure internal pricing consistency across the set before placing trades.

Safety This skill is SAFE by default and runs in paper trading mode unless explicitly invoked with the --live flag. It does not attempt to override Simmer’s built-in safeguards for flip-flop or slippage and respects minimum volume, maximum spread, and minimum days-to-resolution filters configured via tunables.

Execution Mode

• Scenario: Paper simulation
  • Command: python trader.py
  • Venue: sim (paper trades only, zero financial risk)
• Scenario: Live trading on Polymarket
  • Command: python trader.py --live
  • Venue: polymarket (real USDC, use with caution)

Environment and Credentials

• SIMMERAPIKEY (required): API key for Simmer, used for both paper and live trading. Treat this as a high-value credential; do not hardcode it.
• Network access to Polymarket via Simmer and to external BTC data APIs (where configured) is required for full edge; if external feeds are unavailable, the strategy gracefully falls back to simpler probability-extreme logic.

Tunables and Risk Parameters All risk parameters are declared as tunables in clawhub.json and are adjustable from the Simmer UI. They are read via environment variables and reloaded after applyskillconfig:

• SIMMERMAXPOSITION: Maximum USDC per trade. Controls position size per market; higher values increase risk and potential PnL.
• SIMMERMINVOLUME: Minimum Polymarket market volume in USDC. Filters out illiquid BTC weekend markets where spread/impact costs dominate.
• SIMMERMAXSPREAD: Maximum allowed bid-ask spread (fractional). Ensures orders are only placed when price discovery is reasonably tight.
• SIMMERMINDAYS: Minimum days until resolution. Prevents entering markets that are too close to resolution to safely adjust or exit.
• SIMMERMAXPOSITIONS: Maximum number of concurrent open positions. Caps overall exposure across multiple BTC threshold markets.

Dependency

• simmer-sdk by Simmer Markets (SpartanLabsXyz) – required for market discovery, context checks, and trade execution via the Simmer automaton.

Notes This documentation explicitly mentions SIMMERAPIKEY, tunable SIMMER variables, the --live flag, and paper trading to satisfy Simmer registry security checks. Users should validate the skill with the provided validation script and agentskills validate before publishing, and should initially run only in paper mode to observe behavior in live BTC weekend markets.