CONTEXT
This document defines the requirements for Version 0 (MVP) of a quantitative trading system. The strategy is based on identifying and exploiting discrepancies between risk-neutral probabilities, calculated theoretically with the Black-Scholes model, and the implied probabilities observed in Polymarket prediction markets.
OBJECTIVES AND KEY RESULT INDICATORS (OKRs)
Objective 1: Build a robust MVP system for identifying and executing probability arbitrage
- •KR 1.1: Develop a calculation engine that derives risk-neutral probabilities from the Black-Scholes model.
- •KR 1.2: Implement a functional API connector with Polymarket that captures market sentiments of the selected markets in real-time.
- •KR 1.3: Successfully execute the first fully automated operation on the production network before December 1, 2025, based on a probability discrepancy above the defined threshold (e.g., 5%).
Objective 2: Validate the thesis that there are exploitable inefficiencies between theoretical models and prediction markets
- •KR 2.1: Achieve a win rate greater than 60% in the first 100 operations executed.
- •KR 2.2: Obtain a positive return on capital (ROC) after the first 60 days of active trading.
- •KR 2.3: Generate a P&L report that demonstrates a low correlation (beta < 0.2) with the general cryptocurrency market (e.g., BTC/ETH).
LIMITATIONS
1. Theoretical Model (v0)
The strategy will strictly rely on the standard Black-Scholes model. More complex models (e.g., Merton jumps, stochastic volatility) will not be implemented in this initial version.
2. Market Scope
Operations will focus exclusively on Polymarket markets related to digital asset price events (e.g., "Will ETH exceed $5,000 by December 31?"), where Black-Scholes parameters are directly applicable.
3. Volatility Management
Implied volatility, a key input, will be obtained from traditional options markets. The system will not calculate its own implied volatility in v0.
4. Platform Dependency
The strategy is 100% dependent on Polymarket's API, liquidity, and continuous operation of its smart contracts on the Polygon network.
ASSUMPTIONS
- •Validity of the Model: We assume that the Black-Scholes model, despite its simplifications, provides a reasonable approximation of risk-neutral probability for defined price events.
- •Market Inefficiency: We assume that prices in Polymarket are influenced by cognitive biases, asymmetric information flows, and sentiment, creating exploitable deviations relative to theoretical probability.
- •Data Availability: We assume constant and reliable access to data feeds for the model inputs: spot price, implied volatility, and risk-free interest rates.
- •Adequate Liquidity: We assume that the selected markets in Polymarket will have sufficient liquidity to execute economically viable operations without significant adverse price impact.
DEPENDENCIES
- •Financial Data API: The system critically depends on an external data provider (e.g., Deribit API, Chainlink) to obtain real-time implied volatility and spot prices.
- •Polymarket API: All functionality for reading market sentiments and executing orders depends on the stability and documentation of Polymarket's API.
- •On-Chain Infrastructure: Transaction execution requires a reliable RPC provider for the Polygon network to minimize front-running risk and transaction failures.
TASKS / HIGH-LEVEL EPICS
Epic 1: Theoretical Valuation Engine (Off-Chain)
- •Task 1.1: Develop the central Black-Scholes module to calculate option prices and "greeks" (Delta, Vega, etc.).
- •Task 1.2: Create a function to convert the option Delta into a risk-neutral probability.
- •Task 1.3: Integrate real-time data feeds (spot price, volatility, interest rate) as inputs for the engine.
Epic 2: Polymarket Connector and Executor (Off-Chain with On-Chain Interaction)
- •Task 2.1: Develop the API client to query active markets and their sentiments in Polymarket.
- •Task 2.2: Implement logic to convert Polymarket sentiments into implied probabilities.
- •Task 2.3: Build the execution module that interacts with Polymarket's smart contracts to buy and sell shares.
Epic 3: Strategy Logic and Risk Management
- •Task 3.1: Create the "Manager" that continuously compares theoretical probability with market-observed probability.
- •Task 3.2: Define and implement the discrepancy thresholds that trigger an entry order.
- •Task 3.3: Develop risk management rules, including position sizing based on conviction (magnitude of discrepancy) and available capital.
Epic 4: Monitoring and Reporting Dashboard
- •Task 4.1: Build a real-time visualization interface that shows probability discrepancies, open positions, and current P&L.
- •Task 4.2: Implement an alert system to notify the team about each executed trade and any anomalies in the system.
REPLICATING PORTFOLIO CONFIGURATION FOR ARBITRAGE
The proposed arbitrage strategy is based on the construction of replicating portfolios that allow exploiting discrepancies between theoretical probabilities and implied probabilities in prediction markets.
1. Fundamental Principle of Arbitrage
Arbitrage is executed when we identify a significant difference between:
- •The risk-neutral probability derived from the Black-Scholes model (P_BS)
- •The implied probability in Polymarket prices (P_PM)
2. Replicating Portfolio Construction
When P_BS > P_PM (theoretical probability greater than market probability):
- •Main Position: Buy "YES" shares in Polymarket (betting on the event occurring)
- •Complementary Hedge: Establish a short position in the underlying asset proportional to the calculated Delta
When P_BS < P_PM (theoretical probability less than market probability):
- •Main Position: Buy "NO" shares in Polymarket (betting on the event not occurring)
- •Complementary Hedge: Establish a long position in the underlying asset proportional to the calculated Delta
3. Determination of Position Size
The optimal replicating portfolio size is calculated using the following factors:
- •Magnitude of Discrepancy: Greater discrepancy = Larger capital allocation
- •Modified Kelly Criterion: Determines the optimal percentage of capital to risk based on the probability of success and expected gain/loss ratio
- •Available Liquidity: Adjusts size to avoid significant market impact
4. Dynamic Portfolio Management
The replicating portfolio requires continuous rebalancing to maintain risk neutrality:
- •Rebalancing Frequency: Depends on the underlying asset's volatility and the time until the event resolution
- •Gamma Management: Adjust positions when significant changes in the underlying asset's price affect the Delta
- •Trigger Points: Rebalance when the discrepancy between P_BS and P_PM changes by more than X percentage points
5. Technical Implementation of the Portfolio
To implement replicating portfolios, the system needs:
- •Segregated Accounts: Maintain separate accounts on perpetuals/futures exchanges for the hedge component
- •Dedicated Wallet: For operations in Polymarket connected to the automated system
- •Gas Reserve: Maintain a dedicated fund for on-chain transactions to ensure quick execution
- •Reconciliation Module: System that verifies and reconciles positions between Polymarket and derivatives exchanges
6. Specific Risk Management
Specific risks that require mitigation in this strategy:
- •Correlation Risk: Monitor and adjust when the correlation between the underlying asset and the prediction market deviates
- •Liquidity Risk: Establish position size limits proportional to available liquidity in Polymarket
- •Execution Risk: Implement execution algorithms that minimize slippage and detect adverse conditions
- •Model Risk: Periodically compare model predictions against real results to calibrate parameters
PROJECT STATUS
This strategy is in active development. The MVP is scheduled for launch before December 1, 2025, with the capability to execute the first fully automated operation based on probability discrepancies. The system initially focuses on Polymarket's digital asset price markets where the Black-Scholes model is directly applicable.