PREC EDGE is a structured matching layer for prediction-market arbitrage.

What PREC EDGE Does

Prediction-market arbitrage starts with a simple idea: two venues may list contracts that resolve to the same outcome, but price those contracts differently. In practice, that idea is hard to execute because venues use different event containers, different market wording, different outcome labels, and different settlement language. PREC EDGE gives the problem a consistent structure. It stores venue facts, builds candidate event pairs, compares market terms inside mapped events, and turns matched records into dashboard rows and opportunity cards.

The current public portal is a demonstration surface. The Dashboard summarizes a bounded set of mapped event groups. The Live Arbitrage page lets a user load current opportunities only after an explicit click, then filter by ROI threshold. The Arena page lets a user combine selected markets into a structured bet and inspect the outcome logic. Together those pages show the workflow without exposing the entire internal working universe.

Core Concepts

The Matching Problem

A reliable cross-venue match requires more than a high text score. Two records can mention the same team but refer to different matches. Two markets can use the same source but ask different questions. One side may ask whether an event happens by a specific date, while the other asks which date bucket the event falls into. One venue may ask whether a metric rises, while another asks for the exact metric level. Those cases are related, but they are not automatically equivalent contracts.

PREC EDGE therefore separates event-level identity from contract-level equivalence. Event matching answers: do these containers refer to the same real-world subject? Contract matching answers: would these tradable sides resolve the same way under the same material conditions? This distinction keeps the discovery layer broad while keeping the opportunity layer stricter.

The sports scope makes this distinction especially important. A soccer match event can have moneyline, draw, spread, total goals, first-half, correct score, and player prop markets. These all share a real-world event, but only a subset has a direct cross-venue counterpart. Tournament winner markets add another challenge: one event may contain many country or team outcomes, and the comparable record must match the specific outcome, not just the tournament.

Data Model

PREC EDGE uses separate tables or export files for venue events, venue markets, event pairs, market pairs, prices, and opportunity snapshots. Keeping those entities separate is useful because venue records change at different rates. Event metadata may remain stable for days, market prices change constantly, and pair decisions should remain traceable even when a venue later closes or settles a contract.

venue_events
  id, venue, venue_event_id, title, subtitle, category, starts_at, expires_at, status

venue_markets
  id, venue_event_id, venue_market_id, title, outcome, side, rules_text, close_time, status

event_pairs
  id, polymarket_event_id, kalshi_event_id, match_status, score, created_at, updated_at

market_pairs
  id, event_pair_id, polymarket_market_id, kalshi_market_id, match_status, score

price_snapshots
  market_id, bid, ask, last, liquidity, captured_at

opportunity_snapshots
  market_pair_id, buy_venue, sell_venue, gross_roi, net_roi, captured_at

In a cloud deployment, raw payloads should also be preserved. Normalized columns make searching and dashboard rendering fast, while raw JSON protects against data loss when a venue changes its schema or exposes a useful field that was not modeled on day one.

Ingestion

The ingestion layer pulls active venue records using pagination, then stores both raw and normalized representations. For the current product focus, the first slice is sports. On Polymarket, category information can appear through nested tag and event metadata. On Kalshi, category and product metadata are exposed closer to the event and series fields. The pipeline should not rely on a single label without retaining the raw payload, because venue taxonomy can shift over time.

A daily run should be incremental. New events and markets receive embeddings and candidate scores. Unchanged records reuse existing embeddings. Records that disappear from the active venue feed are not deleted immediately; they are marked inactive or expired so historical opportunity records remain explainable. Price snapshots can run more frequently than full event ingestion because price movement is the signal users watch in the Live Arbitrage page.

Polymarket APIs and Orderbooks

Polymarket exposes several public data surfaces. PREC EDGE uses the Gamma API for event and market discovery and the CLOB market-data endpoints for orderbook and pricing reads. The Polymarket docs describe Gamma and Data APIs as public, while CLOB read endpoints such as orderbooks, prices, and spreads can be read without authentication. Trading endpoints remain separate because they require signed order flow.

For event discovery, the key operational endpoint is the keyset-paginated event list. It is designed for stable paging through large result sets and returns event containers with related series, tags, and markets. For market discovery, the keyset market list provides the market layer and includes event relationships. PREC EDGE keeps both because event-level matching and market-level matching are different tasks.

Polymarket orderbooks are token-based. The CLOB orderbook endpoint accepts a token or asset identifier and returns the current book summary, including bids, asks, market identifiers, timestamp, and last-trade context. For batch refresh, the multi-book endpoint can retrieve summaries for several token IDs in one request. PREC EDGE normalizes this into one orderbook shape with best bid, best ask, depth levels, capture time, and venue-specific raw fields.

Kalshi APIs and Orderbooks

Kalshi exposes event, market, and orderbook data through its trade API. Events include fields such as event ticker, title, subtitle, series ticker, category, settlement sources, timing fields, and nested markets. Markets can also be queried directly with filters for status, event ticker, series ticker, pagination cursor, and multivariate-event handling.

For PREC EDGE, Kalshi's event endpoint is useful because the event payload can carry both event metadata and market context. The markets endpoint is still required for exhaustive market refreshes, lifecycle checks, and incremental updates. The pipeline uses status filters to focus on active markets and uses multivariate filters where the product scope needs to exclude combo-like structures.

Kalshi orderbooks are binary-market books. The current orderbook endpoint returns active bid levels for both Yes and No sides. It does not need to return asks as a separate concept: a Yes bid at price X is equivalent to a No ask at 100-X, and vice versa. PREC EDGE converts that representation into a comparable bid/ask view so the opportunity engine can compare Kalshi books with Polymarket books without losing the original venue format.

Matching Workflow

1. Normalize Venue Text

Each event and market is converted into a comparison string built from venue-provided facts: event title, subtitle, category, series metadata, market title, outcome label, rules text, close time, expiration time, and settlement source. Generated summaries can help readability, but the matching basis should remain tied to venue facts.

2. Retrieve Event Candidates

Embeddings are used to find likely event counterparts. This is a retrieval step, not a final decision. Candidate lists should be broad enough to catch wording differences, but narrow enough to avoid comparing every Polymarket event against every Kalshi event on every run. For daily increments, new or changed records can be embedded and compared against the existing active sports universe.

3. Match Markets Inside Event Scope

Once an event pair is mapped, market matching happens inside that event scope. This reduces false matches because the market comparison no longer has to search across unrelated sports, leagues, teams, or dates. The market matcher compares outcome side, threshold, timing basis, settlement source, close behavior, and cancellation edge cases.

4. Validate Before Display

Candidate pairs should enter the public set only after the system has enough evidence that the two sides represent the same tradable proposition. Validation can combine machine scores, deterministic checks, and a manual decision surface. The public portal only needs the final mapped result, not the full internal candidate trail.

Scoring Signals

Embedding score is useful because venue language is inconsistent. It catches cases where two events use different phrasing for the same subject. It also helps find candidates when one venue includes league or tournament names in the title and the other puts those fields in metadata. However, embeddings can overvalue topic similarity. Two markets about the same team can be different if one asks about the winner, another asks about spread, and another asks about total points.

PREC EDGE treats text embedding as one signal among several. Strong candidates should also align on event date, participant names, competition, outcome direction, source, and settlement window. For threshold markets, the threshold value must match. For bracket markets, the bucket definition must match. For winner markets, the exact team, country, player, or candidate must match. For date markets, the boundary date and timezone must be compatible.

Embedding and Agent Reconciliation

PREC EDGE uses text embeddings as the retrieval layer. The input text is built from venue-provided fields: event title, subtitle, category, series metadata, market title, outcome label, settlement source, rules text, close time, and expiration time. Embeddings produce a ranked candidate list, which keeps the search space small enough to process while still catching different wording across venues.

The agent layer sits after retrieval. Its role is not to invent facts. It compares the venue-provided fields and writes a structured explanation: same event or not, same market or not, which fields match, which fields conflict, and whether the pair is event-level only or market-level usable. That distinction is central because a shared event does not imply a shared tradable contract.

The reconciliation pipeline is staged. First, embeddings retrieve event candidates. Second, an agent compares event identity using title, participants, category, date, series, and settlement source. Third, market candidates are scored only inside mapped event pairs. Fourth, an agent compares outcome side, threshold, timing, and rule text. The resulting structured record is stored with scores, source IDs, raw venue snippets, and lifecycle timestamps so later price calculations can reference the exact match basis.

venue facts
  -> comparison text
  -> embedding vectors
  -> top event candidates
  -> agent event reconciliation
  -> event-scoped market candidates
  -> agent market reconciliation
  -> mapped event and market pairs
  -> orderbook + opportunity calculations

Opportunity Math

An opportunity exists when the combined cost of equivalent positions is below the payout under a compatible settlement structure. For a simple binary cross-venue pair, the core calculation compares the cost of buying one side on one venue with the cost of buying the opposite side or synthetic hedge on the other. The resulting gross ROI is the surplus divided by capital committed. Production calculations should also account for fees, tick size, liquidity, order-book depth, execution delay, withdrawal constraints, and position limits.

gross_edge = payout - total_cost
gross_roi = gross_edge / total_cost

display_opportunity when:
  market_pair_status == "mapped"
  both_markets_active == true
  settlement_terms_compatible == true
  gross_roi >= selected_threshold

The Live Arbitrage page currently starts with no opportunity cards visible. The user clicks Load Opportunities, the page waits briefly, and then the filtered set appears. This creates a demo flow closer to a live monitor, where data is intentionally loaded rather than shown as a static table at first paint.

API Endpoints

PREC EDGE will expose a small developer API that joins the two venue views into one response. The first endpoint is under development and is designed to return a mapped event pair with the Polymarket event, Kalshi event, related markets, current orderbooks, and opportunity calculations in one call. The public site can use this endpoint later instead of loading static JSON exports.

GET /api/v1/cross-venue/events/{event_pair_id}/markets?include_orderbooks=true

The response shape keeps raw venue fields under each venue while also exposing normalized fields for UI rendering. This gives developers one simple call without hiding the source payloads needed for validation and debugging.

Examples

These examples show how PREC EDGE separates event identity, market equivalence, and price execution. The examples are simplified, but they mirror the checks the pipeline needs before a pair appears in a public dashboard or API response.

// simplified opportunity check
const totalCost = polymarket.bestAsk + kalshi.noAsk;
const grossEdge = 1 - totalCost;
const grossRoi = grossEdge / totalCost;

if (sameMarket && freshBooks && grossRoi >= 0.01) {
  showOpportunity();
}

Arena

Arena is a structured-bet workspace. It lets a user select mapped markets, choose Yes or No sides, and combine them with logical conditions such as ALL, ANY, AT LEAST, or EXACTLY. The canvas is not an execution engine. It is a reasoning surface for understanding how a basket of market positions behaves under different outcome states.

This matters because many interesting prediction-market strategies are not single-pair trades. A user may want to compare multiple tournament outcomes, build a hedge around mutually exclusive teams, or test how a group of related contracts behaves if one event settles earlier than another. Arena gives that logic a visible structure before any trade sizing or execution workflow is considered.

Operations

A production deployment should separate four workloads. First, venue ingestion fetches raw events, markets, and price data. Second, normalization converts raw payloads into stable columns and searchable text. Third, candidate scoring runs embeddings and deterministic comparisons. Fourth, public export produces the smaller data bundle used by the website. Separating those workloads keeps the public page fast and keeps expensive compute away from page-load time.

Cloud storage should keep daily raw snapshots, normalized current tables, and historical price snapshots. The relational database should store active events, active markets, mapped pairs, lifecycle state, and opportunity snapshots. A scheduled daily job can add new sports records, update changed records, mark missing records inactive, and queue only changed candidate groups for additional scoring. If the schedule is disabled, the system should retain enough local scripts and infrastructure configuration to redeploy the pipeline later.

Limits and Assumptions

PREC EDGE is a data and research interface, not financial advice and not an execution guarantee. Venue APIs can lag. Markets can halt, close, or settle unexpectedly. Rules text can change. Liquidity shown in a snapshot may not be available by the time a user acts. Some apparent spreads disappear after fees, slippage, or order-book depth are considered.

The safest interpretation of the portal is that it demonstrates a matching architecture. It shows how to turn messy venue data into a smaller set of comparable records, how to preserve event and market boundaries, and how to explain why a visible opportunity exists. Any production system built from this pattern should keep raw venue payloads, versioned matching output, price history, and lifecycle transitions so each displayed opportunity can be traced back to its source facts.