YichengYang-Ethan/oracle3-prediction-market-agent

The constraint and statistical strategies in oracle3/strategy/contrib/ subtract a flat 0.005 per side per contract. At mid prices that is below both venues' taker fees (a Kalshi leg bought at 0.50 pays 1.75¢). oracle3.fees implements the published Kalshi and Polymarket schedules, and oracle3.arbitrage already prices baskets with them. Task Replace the flat constant with the leg's venue schedule in each constraint strategy. Keep a constructor option to override the schedule for tests and backtests. Add tests showing that a violation below the fee hurdle no longer produces a signal.

Oracle3 includes LLM-driven strategies, and prediction-market prices are themselves probability forecasts. It is an open question when an LLM's probability should move a price estimate at all. Question. On resolved Kalshi and Polymarket contracts, how does an LLM's stated probability compare with the market price in calibration and sharpness, and does combining them help? Suggested approach Use contracts that resolved after the model's training cut-off to avoid leakage. Record the market price at fixed horizons before resolution and the LLM's probability given the same information. Compare Brier score, log score and reliability curves; test simple combinations. Useful output: the evaluation dataset (market ids, horizons, prices, forecasts, outcomes) and a short note.

A same_event check assumes two contracts on different venues resolve identically. In practice resolution sources, cut-off times and edge-case rules can differ, and a pair that looks like an arbitrage can then pay differently. Question. Can resolution-rule differences between a Kalshi market and a Polymarket market be flagged automatically before a pair is treated as the same event? Suggested approach get_market returns rules_primary/rules_secondary (Kalshi) and rules/resolution_source (Polymarket). Start with a checklist of fields that must agree (source, time zone and cut-off, treatment of ties, cancellations, revisions) and test it on a hand-labeled set. An LLM-based comparator is welcome if it is evaluated against the same labels. Useful output: a function that returns the fields that disagree, with tests.

Oracle3 bundles Coinjure's relation-matching pipeline (coinjure/matching/), which proposes relations such as implication, exclusivity and complement between markets. The constraint checks are only as good as those relations: a wrong relation turns an "arbitrage" into a directional bet. Question. How precise and complete is automatic relation discovery, by relation type? Suggested approach Build a labeled set of market pairs from Kalshi and Polymarket, including hard negatives (similar wording, different resolution). Measure precision and recall of the pipeline per relation type. Analyze the errors: wording, date ranges, resolution sources, threshold direction. Useful output: the labeled set (with sources), an evaluation script, and a short results note.

The fee note gives the break-even violation for each relation and venue pair under the published fee schedules (for example 3.5¢ per contract for a two-leg Kalshi taker basket at mid prices). It does not say how often live prices cross those thresholds, for how long, or at what depth. Question. For a fixed set of related markets, what is the distribution of gross and net edge over time, by relation type and venue pair? Suggested approach Pick relations whose logic is unambiguous (event sums within one Kalshi event; complements; clear implications such as nested thresholds). Poll check_constraint_live (MCP) or oracle3.arbitrage.check_constraint on recorded books at a fixed interval. Record gross edge, fees, net edge, and the displayed size at the best level for every leg. Report the share of snapshots with positive net edge, spell durations, and capturable size. Useful output: a reproducible script plus a short note in docs/research/.