Prediction Market Aggregator Overview

The Prediction Market Aggregator brings eight third-party prediction-market platforms into a single MAGMA surface — the /markets page in magma-web. MAGMA does not run these markets; it reads them through a backend proxy, normalizes each platform's market shape, and lets the user trade them from their own wallet. Market and quote data flow through the MAGMA backend; order construction is platform-specific (built on the backend or in the browser depending on the platform), and the signature always comes from the user's connected wallet — MAGMA is non-custodial and never holds a private key for these venues.

Distinct from MAGMA-native binary markets

This aggregator is not MAGMA's own Binary Markets. Those are native YES/NO markets settled on Solana by the magma_binary_vault program and served at /v1/markets. The aggregator wraps external venues at /v1/<platform> (e.g. /v1/polymarket/markets). Keep the two surfaces separate: /v1/markets = native binary; /v1/<platform> = aggregated third-party. See API Reference.

The eight platforms

Platform	Chain	Venue type	Backend service	Web lib
Kalshi (via DFlow)	Solana	Outcome-token swap (SPL / Token-2022)	services/dflow/markets.ts	lib/dflowTrade.ts
Polymarket	Polygon	CLOB (Gamma + CLOB API)	services/polymarket/markets.ts	lib/polymarketTrade.ts
Limitless	Base	CLOB (partner HMAC)	services/limitless/markets.ts	lib/limitlessTrade.ts
Predict.fun	BNB Chain	CLOB (EIP-712, referral fee)	services/predict/markets.ts	lib/predictTrade.ts
Rain	Cross-chain	AMM (unsigned tx returned)	services/rain/markets.ts	lib/rainTrade.ts
Opinion	BNB Chain	CLOB (macro / economics)	services/opinion/markets.ts	lib/opinionTrade.ts
Overtime V2	Optimism	Sports AMM (SportsAMMV2.trade())	services/overtime/markets.ts	lib/overtimeTrade.ts
DFlow	Solana	Execution engine (gasless / sponsored)	services/dflow/*	lib/dflowTrade.ts

Kalshi and DFlow are the same integration

Kalshi markets are powered by DFlow (Pond) — DFlow is the Solana execution engine that exposes Kalshi outcome tokens as SPL/Token-2022 mints. There is one backend service (services/dflow/*), one web lib (lib/dflowTrade.ts), and one route group (/v1/dflow/*). On the UI the tab is labelled Kalshi (KalshiTradeModal); under the hood it is the DFlow build → sign → submit → poll flow, with optional sponsored (gasless) execution. They are listed as two "platforms" because they are two product surfaces, not two backends.

The unified /markets surface

The /markets page in magma-web is the client-side unifier. It:

• fetches each platform's normalized market list from /v1/<platform>/markets (and search / :id / positions as needed);
• renders them in one categorized, searchable grid alongside MAGMA's native binary markets;
• opens a per-platform trade modal (KalshiTradeModal, PolymarketTradeModal, LimitlessTradeModal, PredictTradeModal, RainTradeModal, OpinionTradeModal, OvertimeBetModal) that drives the platform's specific signing flow via its web lib; and
• switches the user's wallet to the market's chain before signing (via useChainController / VENUE_CHAIN_KEY for the EVM venues, and solana:mainnet for Kalshi/DFlow).

There is no single shared market type. Each platform defines its own <Platform>Market interface on the backend, and the client composes those heterogeneous shapes per-tab — see Market Normalization.

Why this shape

• Compliance. Order placement for several venues is geoblocked by IP. By signing in the browser, the geoblock applies to the user's own IP, not MAGMA's servers — the compliant arrangement. MAGMA never relays an order it constructed under its own IP.
• Non-custodial. The user's key never leaves their wallet. MAGMA's backend only ever returns unsigned payloads (an order to sign, or an unsigned transaction); the user signs and the order/tx is then submitted (directly, via the platform, or relayed under MAGMA's partner credentials).
• Read-proxy for data. Market lists, quotes, and orderbooks are fetched and cached by the backend so the client gets one consistent, normalized, rate-limit-friendly feed per platform.

See Architecture for the full request flow.

Where to next

• Architecture — the backend read-proxy + client-signing pattern and why.
• Platform Integrations — per-platform reference for all eight.
• Market Normalization — the <Platform>Market interfaces and verbs.
• Trading & Settlement — order lifecycle, approvals, redemption, fees, gasless.
• API Reference — the real /v1/<platform> REST endpoints.