ParlayMarket: a parlay engine and resolver layer on top of on-chain prediction markets

ParlayMarket introduces a dedicated parlay layer for on-chain prediction markets. Most prediction venues expose single-event contracts (e.g. YES/NO on an election, macro print, or sporting match). Users who want to express multi-event views must manually construct and manage baskets of positions: a process that is capital-inefficient, operationally error-prone, and difficult to reason about in terms of joint probabilities and correlated exposure.

The ParlayMarket engine ingests binary markets from supported venues and normalizes their metadata and resolution criteria. On top of this normalized market set, the engine allows users to construct parlays—tickets combining multiple legs, each referencing an underlying market-side pair. For each candidate parlay, the engine computes a fair joint probability, applies a configurable house edge, and surfaces user-facing quantities such as effective probability, implied odds, and max payout. These quantities are what the homepage demo ticket and app UI highlight.

Resolution is handled by a resolver layer that tracks the outcome of each underlying market, applies a deterministic rulebook for edge cases (e.g. voids, ambiguities, partial results), and emits an auditable log of parlay-level settlement. In v0, this resolver runs centrally and writes logs to structured storage; longer-term, the interface is designed so that the same semantics can be implemented as on-chain resolvers and/or oracle adapters.

The reference implementation ships as:

• A static web application (served via GitHub Pages) for constructing parlays and inspecting tickets.
• A Cloudflare Worker (or comparable edge function) that periodically ingests markets from venues and exposes them as a JSON feed consumed by the app.
• A parlay engine module that runs within the app context, reconstructing tickets, computing joint probabilities, and exposing projected payouts in the browser for v0; later iterations can move the pricing into a backend service while preserving the same interface.

2.1 Problem space

Traditional sportsbooks have offered parlays for decades. Crypto-native prediction venues, by contrast, tend to focus on single-market exposures and do not yet expose a rich parlay surface. Users who want to express multi-event narratives are forced to:

• Manually search for relevant markets across venues.
• Individually size and maintain multiple positions.
• Approximate joint probabilities and correlations by hand.
• Track resolution and P&L across multiple venues and wallets.

This creates cognitive overhead for sophisticated users and makes it difficult to build higher-level structured products (such as election sweeps, macro baskets, or narrative clusters) on top of prediction markets.

2.2 Design principles

ParlayMarket is guided by the following principles:

• Parlay-first UX. The user experience is built around parlays as first-class objects, not just as a “multi-select” checkbox on top of single-event markets.
• Separation of layers. Distinct modules exist for the user layer, the parlay engine, and the underlying market layer. This is reflected across the homepage, app, and this whitepaper.
• Transparent math. The multiplicative structure of joint probabilities, edge, and payout is surfaced to users, not hidden behind opaque lines.
• Progressive decentralization. The v0 implementation uses a centralized engine for speed and safety, but the interfaces are designed so that pricing and resolution can migrate on-chain.
• Composable infra. The engine is intended to be integrated into other apps and venues, not just used by a single front-end.

ParlayMarket is logically decomposed into three layers. This mirrors the architectural description on the homepage and the app routing:

In the deployed prototype, the app is served as static assets while the Cloudflare Worker runs at the edge. The Worker periodically queries a venue, normalizes fields (titles, categories, times, odds), and exposes a JSON feed. The app presents this feed in the Step 1 “Select legs” view with sort-by-category, date/time groupings, and search by title or outcome.

4.1 Market ingestion & normalization

The engine relies on a normalized view of binary markets. The Worker (or equivalent ingestion service) transforms venue-specific fields into a canonical schema, for example:

The app’s Step 1 screen (“Select legs”) groups these markets by category and time. The wishlist for the app includes:

• Improved metadata display in App/Index, matching Worker output.
• Category-based filtering and sorting of selectable legs.
• Time-zone toggling and time-bucket highlighting (e.g. “within next 3 days” groups).
• Text search across titles and outcomes, with accurate metadata-backed search.
• Removal of internal Worker URLs from any visible feed.

4.2 Ticket construction

A parlay ticket is defined as a set of legs, each pointing to a specific underlying market and side. A minimal ticket structure is:

On the homepage, a static example is rendered and recomputed locally: the three-leg election parlay uses probabilities 0.61, 0.54, and 0.48, with an adjustable stake (default $100) and a dynamically recomputed max payout. In the app, a similar computation occurs when the user proceeds from Step 1 (leg selection) to Step 2 (review & stake).

4.3 Ticket lifecycle

The engine tracks each ticket through a lifecycle:

• quoted – parameters computed but not yet accepted.
• accepted – ticket locked, stake committed, legs frozen.
• in_play – at least one leg is live or awaiting resolution.
• settled – all legs resolved and payout computed.
• voided – ticket canceled or annulled according to rulebook.

In v0, this lifecycle can be modeled as a state machine within the app and backend logs, with no custody or on-chain settlement. In later stages, the same state transitions can correspond to on-chain events or smart-contract state changes.

The core of ParlayMarket is a set of multiplicative processes that translate a vector of single-leg probabilities into a parlay price, edge, and payout. The homepage demo surfaces these mechanics explicitly; this section formalizes them.

5.1 From prices to probabilities

For each leg i, the venue quotes a price p_i for the YES side. In the simplest binary case, we treat p_i as an implied probability after any venue-specific fees or edge. More generally, we can model:

5.2 Joint probability under independence

The baseline pricing model assumes independence across legs. Let L be the set of selected legs; then the joint probability of all legs winning is:

The homepage demo parlay is built as:

This value is displayed as “Effective parlay probability” in both the demo card and the app.

5.3 Fair odds and projected payout

Given a stake S and joint probability P_win:

The engine then applies a configurable house edge, expressed as basis points (bps) on the fair odds or directly on the payout. For example, with an edge e = 1.2%:

In the homepage demo, this is summarized as:

• Stake: user-adjustable (default $100).
• Effective parlay probability: P_win.
• Max payout: Payout_quote, prominently displayed.
• House edge: shown as a small label (e.g. 1.2%).

5.4 Composite odds & implied probability in the app

In App/Index, Step 2 (“Review & stake”) is designed to highlight:

• The computed joint probability and effective decimal odds.
• A composite odds field that summarizes the bundle in the user’s preferred format (decimal, American, fractional).
• A projected payout figure large enough to anchor user intuition about how edge and leg count interact.

The wishlist explicitly calls for making projected payout and implied probability more prominent, with potential room for a “composite odds” visual that explains how the multiplicative structure amplifies or dampens the payout as legs are added or removed.

5.5 Time and category structure

On the selection side, markets are grouped by:

• Category: politics, macro, sports, crypto, etc.
• Time buckets: for example “within 24 hours”, “2–3 days”, “> 3 days”.
• Time zone: with a button to toggle between UTC and user-local time.

These groupings do not directly affect the math but are crucial for making multi-leg selection tractable. In future versions, cross-leg correlations can be modeled explicitly by adjusting the joint probability away from pure independence while preserving the same UX.

6.1 Resolution sources

For each underlying market, the venue defines a resolution rule (e.g. official election results, an oracle feed, or event organizers). ParlayMarket does not redefine these rules; instead, it tracks them and exposes additional structure:

• A pointer to the venue’s resolution criteria and any hashes of canonical text.
• A log of resolution timestamps and state transitions (e.g. open → resolved).
• A mapping from venue-specific states to parlay leg states.

6.2 Leg states

Each parlay leg is mapped into one of a small set of states:

• win – underlying market resolved in favor of the selected side.
• loss – resolved against the selected side.
• void – market canceled or voided per venue rules.
• ambiguous – resolution unclear; human intervention or additional data required.
• pending – no final outcome yet.

The resolver module converts venue events into these leg states and then applies a deterministic ticket-level rulebook, for example:

• If any leg is loss, the ticket is a loss, regardless of remaining pending legs.
• If all legs are win, the ticket pays out according to quoted payout.
• If some legs are void and none are loss, the ticket is recalculated as a parlay over the remaining non-void legs (or converted to a single-leg ticket if appropriate).

6.3 Logs and auditability

A key design objective is that every ticket and leg have an associated log. Even in v0, where the engine is centralized, this log can be:

• Stored as structured JSON with timestamps and event types.
• Exportable to users for independent verification.
• Mapped into an on-chain event stream if/when the resolver is deployed as a contract.

The homepage and app reference this explicitly: a “resolver layer with structured rules and logs” is part of the story, not an implementation detail.

ParlayMarket is intended to be integrated into a variety of products, not only used via the reference front-end.

7.1 Web app integration

The existing application (App/Index) is tailored for:

• builders and traders who want a direct UI for constructing parlays;
• fast iteration around metadata presentation, search, and leg-selection workflows;
• a clean separation between front-end display and Worker-based ingestion.

The wishlist specifically calls for:

• Improved metadata display. Rendering more fields from the Worker output, including venue, category, times, and tags.
• Category sorting and filtering. Allowing users to focus on specific narrative clusters.
• Date/time grouping and color-coding. Highlighting legs that share similar resolution windows (e.g. events resolving within three days).
• Time-zone switching. A button in Step 1 to switch between UTC and local time.
• Search by title or outcome. Accurate and responsive search across leg metadata.

7.2 Cloudflare Worker and feeds

The Worker acts as the edge ingestion and transformation layer. It:

• Fetches raw market data from supported venues at configured intervals.
• Normalizes this data into the canonical schema described earlier and emits a JSON feed consumed by the app.
• Avoids exposing internal URLs or unnecessary implementation details in user-facing feeds, per the wishlist to “remove feed that shows full Cloudflare Worker URL”.

7.3 Future protocol & on-chain interfaces

The roadmap includes moving the parlay abstractions themselves on-chain. This could involve:

• Smart contracts representing parlay tickets as composable primitives, referencing external prediction markets as underlying assets.
• Resolver contracts that enforce the deterministic rulebook described in this whitepaper.
• A shared specification for how venues expose markets to parlay engines, enabling a broader ecosystem of builders.

The homepage includes a three-phase roadmap; this section aligns the technical plan with that view.

8.1 Phase 0 — Alpha

• Static web app with multi-step parlay builder (GitHub Pages).
• Cloudflare Worker ingestion of a single venue.
• Paper trading and simulation; no custody, no live wagering.
• Structured logs and clear math for every demo ticket.

8.2 Phase 1 — Live engine

• Production-grade backend for ticket lifecycle and risk limits.
• Configurable edges and risk parameters per category and user segment.
• Resolver stack with multiple data sources and dispute windows.

8.3 Phase 2+ — Protocol

• On-chain parlay abstractions anchored to prediction venues.
• Standardized schema for cross-venue market ingestion.
• White-label integration pathways for other apps and desks.

As a parlay engine on top of prediction markets, ParlayMarket is exposed to a combination of: model risk, market risk, correlation risk, venue/oracle risk, and implementation risk. The v0 alpha deliberately limits scope to a non-custodial, paper-trading environment while these risks are characterized and mitigated.

This whitepaper is a technical description, not a statement of regulatory status or an offer to accept wagers or provide financial services.