Prediction Market Platform Architecture Map: Exchanges, Wrappers, Routers, Perps Rails, and Intelligence Layers
“Prediction market platform” now describes several different products. This map separates the rail that writes rules, the app that displays markets, the router that may choose execution paths, and the intelligence layer that explains what the market means.
Six layers people flatten into one phrase
Start by asking which layer controls the thing you care about.
Direct exchange / regulated rail
The venue lists contracts and controls exchange mechanics directly.
Who writes the contract rules and resolves the market?
Wrapper / distribution app
A familiar consumer app surfaces contracts from an underlying exchange rail.
Why does this app show fewer markets or different support language than the exchange itself?
Smart-order-routing aggregator
A product tries to find or split execution across venues instead of only showing odds.
Is this just a comparison table, or is it routing execution?
User-generated marketplace
Users can create or seed markets rather than relying only on centrally curated listings.
Who decides what markets exist?
Perps / margin-style rail
A rail packages prediction-like outcomes or adjacent derivatives inside a margin/perpetuals product surface.
Is this a binary event contract, a perpetual, or something else?
Media / intelligence layer
A product explains markets, sources, rules, and context without executing trades.
Where do I go to understand what the market means and whether the signal is trustworthy?
Controls matrix
Rows are architecture lanes. Columns are the decisions users often assume one brand controls.
| Lane | Who controls contract listing? | Who controls execution? | Who controls support/account display? | Who controls settlement/oracle? | Who controls market creation? | Who captures fees or economic upside? | What does the user actually do here? |
|---|---|---|---|---|---|---|---|
| Direct exchange / regulated rail | Exchange / rail | Exchange orderbook | Exchange or member-facing app | Rulebook + settlement process | Central listing process | Exchange / rail economics | Trade directly on the venue |
| Wrapper / distribution app | Underlying rail, filtered by app | Underlying exchange rail | Wrapper app | Underlying rulebook | Underlying rail, not the wrapper alone | Wrapper + underlying rail, depending on terms | Use a familiar app surface |
| Smart-order-routing aggregator | Matched venues / supported rails | Router logic + destination venue | Router product | Destination venue | Usually not the router | Router and/or routed venue | Route or compare execution paths |
| User-generated marketplace | Users plus moderation policy | Marketplace rules | Marketplace product | Platform-specific resolution model | User creation flow | Marketplace and market creators/liquidity providers | Create, seed, or trade user-listed markets |
| Perps / margin-style rail | Rail / protocol / platform | Margin or perpetuals engine | Perps surface | Funding, margin, and oracle logic | Rail governance or platform listing | Rail economics, funding, and fee model | Trade an adjacent derivative, not always a binary event contract |
| Media / intelligence layer | No listing control | No execution control | No account surface | Explains source and rule differences only | No market-creation control | No brokerage, clearing, routing, or custody | Understand markets, sources, rules, and platform differences |
Operating-model matrix
The same consumer brand can combine curation, execution, fees, settlement, and regulatory roles in different ways. Read the stack before assuming who controls what.
| Lane | Curation | Execution | Value accrual | Fee model | Settlement / oracle | Regulated stack role | Token / exposure model | Economic caution |
|---|---|---|---|---|---|---|---|---|
| Direct exchange / regulated rail | Listings and rulebook controlled by the exchange or regulated rail. | Venue orderbook and matching mechanics control whether an order actually trades. | Exchange and, where applicable, clearing economics accrue to the regulated rail. | Contract, trading, and clearing fees follow the venue's official schedule. | The rulebook and designated settlement source or oracle control the outcome. | May include a DCM and, where vertically integrated, a DCO or clearing stack. | May use cash, collateral tokens, clearing margin, or no public token at all depending on the rail. Token mechanics do not define exchange status. | Do not infer exchange economics, clearing economics, or user upside from a token ticker unless official filings or platform docs say so. |
| Wrapper / distribution app | The app exposes a selected catalog from one or more underlying rails. | Orders route to or through an underlying exchange, clearing, or partner relationship. | Distribution, account-surface, or partner economics accrue around the consumer app layer. | App and partner economics may differ from the underlying rail's public fee schedule. | The underlying rail's rulebook controls the contract outcome, not the wrapper screen alone. | Often an FCM, IB, member, or support surface rather than the DCM/DCO itself. | Usually exposes the underlying rail through an app account; any app equity, public-company stock, loyalty program, or token surface is separate from the contract itself. | Do not treat buying the wrapper company's stock or token as equivalent to trading the routed prediction-market contract. |
| Smart-order-routing aggregator | The product matches equivalent or near-equivalent markets across supported venues. | Route selection or order splitting may choose the destination venue when supported. | Router software, spread, fee, or subscription economics may accrue at the routing layer. | Users need to inspect both router costs and destination-venue trading costs. | The destination venue still controls the outcome and settlement source. | Terms and registrations must be checked before assuming broker, FCM, or exchange status. | May charge software, routing, subscription, spread, or protocol fees; token exposure is unverified unless the router's own docs specify it. | A router can capture value without controlling settlement, and a token or fee switch does not prove the router owns the destination venue's economics. |
| User-generated marketplace | Users create or seed markets subject to platform moderation and listing policy. | Platform-specific marketplace mechanics control trading and liquidity. | Economics may accrue to the platform and, where allowed, creators or liquidity providers. | Marketplace fee and revenue rules are platform-specific and should be read directly. | Resolution depends on the platform's resolver, oracle, moderation, or community process. | Do not treat it as equivalent to a CFTC-regulated DCM unless official filings say so. | May use platform credits, points, creator incentives, liquidity incentives, or tokens depending on the marketplace design. | User-created-market incentives are not the same as regulated exchange economics or guaranteed creator revenue. |
| Perps / margin-style rail | A protocol or platform lists contracts, markets, or prediction-like instruments on the rail. | A perps, margin, liquidation, or funding engine controls execution behavior. | Fees, funding, liquidations, or protocol economics may capture value at the rail. | Trading, funding, collateral, and liquidation rules matter more than a simple contract fee. | Oracle, funding, margin, and collateral rules control payoff mechanics. | Varies by product; verify separately from event-contract DCM status. | Often has the clearest token/protocol-fee surface: collateral, funding, liquidations, governance, or fee capture can sit inside the rail. | Do not translate protocol-fee capture or governance-token narratives into event-contract user returns without primary-source support. |
| Media / intelligence layer | Editorial selection chooses which explainers, trackers, and source-linked pages to maintain. | No order execution, routing, matching, custody, clearing, or brokerage occurs here. | Audience, research, and editorial product value accrues without routing trades. | No brokerage, clearing, custody, or execution fee is charged by the intelligence layer. | The layer explains rule and source differences; it does not resolve markets. | No DCM, DCO, FCM, or IB role. | No token, collateral, custody, staking, clearing, or execution exposure is created by reading an intelligence page. | Audience or subscription value is not trade execution, brokerage, clearing, custody, or token exposure. |
Rail taxonomy: what kind of market surface are you looking at?
The same prediction-market headline can involve an exchange venue, clearing stack, crypto-native rail, app wrapper, sport-specific consent lane, or editorial intelligence layer. This section separates those roles before readers assume who controls the contract.
Do not collapse the stack
PredictionMarkets.US is not a broker, router, exchange, custodian, clearinghouse, or execution venue.
Official Hyperliquid docs now verify HIP-4 as an outcome-market primitive. Market breadth, live volume, and competitive impact still require primary or owned data before being rendered as facts.
App brand, exchange rail, clearing stack, consent framework, and editorial layer are separate questions.
CFTC exchange / regulated event-contract venue rail
A venue or exchange rail controls contract listing, rulebook mechanics, orderbook access, and the official settlement path for regulated event contracts.
Is the place I am using the actual exchange rail, or just an app showing that rail?
- • contract listing
- • rulebook mechanics
- • orderbook access
- • settlement path
- • third-party wrapper UX
- • every app support workflow
- • unverified clearing or broker status
A reader may treat a wrapper or media summary as if it controls the contract, then miss the actual rulebook and settlement source.
Clearing / FCM / institutional access stack
A clearing, FCM, or institutional access layer can sit beside an exchange rail without being the same thing as the consumer-facing app.
Who clears, intermediates, or gives institutional access — and is that status actually verified?
- • clearing relationship where verified
- • intermediation where verified
- • institutional access terms where verified
- • market title wording
- • app catalog curation
- • event-resolution source unless the rulebook says so
A reader may overstate a partner, clearing, or broker role and turn a stack component into a false platform-status claim.
Crypto-native event rail
A crypto-native rail may use collateral tokens, smart contracts, protocol governance, or on-chain settlement instead of a traditional regulated venue stack.
Is this an event-contract venue, a crypto execution rail adding outcome contracts, or just a reported future feature?
- • protocol or platform execution mechanics where documented
- • collateral or token rail where documented
- • on-chain or oracle process where documented
- • CFTC venue status without official records
- • U.S. app availability
- • off-chain support or wrapper behavior
Official docs can verify a primitive without proving live breadth, durable liquidity, user adoption, market share, or competitive impact.
App / wrapper / distribution rail
A consumer app can distribute, filter, or explain markets from an underlying exchange rail while leaving the contract language and settlement path elsewhere.
Does the app brand control the market, or is it distributing another rail?
- • front-end UX
- • catalog presentation
- • support path
- • account display where applicable
- • underlying contract wording unless officially stated
- • settlement source
- • clearing role without official records
A reader may blame the app for a rule or settlement mechanic controlled by the underlying exchange rail.
Consent-constrained / sport-specific lane
Some categories, especially horse racing/IHA-style contexts, require a separate permission or consent lens rather than a generic sports-market label.
Is this market constrained by a sport-specific consent framework instead of ordinary event-contract taxonomy?
- • category eligibility lens
- • consent or permission requirement where verified
- • source discipline for sport-specific rules
- • all sports markets
- • state gambling-law outcomes by itself
- • platform legality outside the specific framework
A reader may flatten horse-racing consent constraints into generic sports-betting law and miss the specific source needed.
Media / intelligence layer
An intelligence layer explains rules, rails, sources, and risks without routing trades or controlling settlement.
Am I looking at an explanation layer or a place that can actually take or settle an order?
- • source curation
- • rule explanation
- • cross-platform literacy
- • internal linking
- • trade execution
- • order routing
- • brokerage
- • custody
- • clearing
- • market settlement
A reader may confuse analysis with execution capability; the page explicitly separates those roles.
Rail and clearing stack are separate questions
A CFTC venue, a clearing organization, a crypto execution rail, a wrapper app, and an intelligence surface can all appear in the same prediction-market conversation. This section separates verified stack pieces from pending rail watch items.
Gemini Titan + Gemini Olympus
Gemini has venue + clearing pieces for regulated derivatives/prediction markets; do not describe it as a broker/FCM unless that status is verified.
FCM status is not rendered as verified. Do not describe this as a complete customer-facing broker stack without official records.
- • https://www.globenewswire.com/news-release/2026/04/30/3284943/0/en/Gemini-Receives-DCO-License-Approval-From-CFTC.html
- • https://www.cftc.gov/IndustryOversight/IndustryFilings/TradingOrganizations?search=Gemini
- • https://www.cftc.gov/IndustryOversight/IndustryFilings/TradingOrganizations/44472
- • https://www.cftc.gov/IndustryOversight/IndustryFilings/ClearingOrganizations?search=Gemini
- • https://www.cftc.gov/IndustryOversight/IndustryFilings/ClearingOrganizations/59189
Hyperliquid HIP-4 outcome rail
Official Hyperliquid docs verify the HIP-4 primitive; this card still withholds market breadth, live volume, user adoption, and competitive-impact claims until primary or owned data supports them.
Official Hyperliquid docs now verify HIP-4 outcome markets as fully collateralized fixed-range contracts useful for prediction markets and bounded options-like instruments. Market breadth, live volume, user adoption, and competitive impact still require primary or owned data before being rendered as facts.
Is this a regulated event-contract venue or a crypto execution rail adding outcome contracts?
- • Official Hyperliquid HIP-4 docs verify the outcome-market primitive
- • Primary or owned data required for market breadth, live volume, user adoption, market-share, or competitive-impact claims
- • CFTC or U.S. official record required before any regulated-venue claim
Toolchain / Workbench Memo
The stack is not one thing; ask what the tool controls.
Am I looking at a venue, wrapper, client library, router, dashboard, or intelligence layer?
Official venue API / client
The venue's official API or client surface is documented by the exchange or rail operator.
- • Access documentation
- • Supported order and market data interfaces
- • Venue-specific integration requirements
- • Third-party dashboard claims
- • External app support flows
- • Another venue's settlement source
Third-party bot client / SDK wrapper
A developer tool can make a venue API easier to use without controlling the market's rulebook or settlement path.
- • Developer ergonomics
- • Client-side helper functions
- • Integration workflow around a venue API
- • Contract wording
- • Order matching at the destination venue
- • Market resolution or settlement
Analytics dashboard / terminal
A dashboard or terminal observes markets and packages data; observation is not execution or settlement control.
- • Charts and screens
- • Filtering and watchlists
- • Data presentation and alerts
- • Venue rulebooks
- • Clearing or custody
- • Resolution-source selection
Smart router / execution layer
A routing layer may choose where an order goes, but the destination venue still controls the contract and settlement rules.
- • Route choice when officially documented
- • Execution-path comparison
- • Order-splitting or destination selection UX
- • Destination venue settlement
- • Destination venue rulebook
- • Clearing, custody, or brokerage status unless official records say so
Wrapper app
A consumer app can provide account UX, support language, and catalog curation over an underlying rail.
- • Account and support surface
- • Catalog visibility
- • User-facing product flow
- • Underlying exchange rulebook by itself
- • Settlement source by itself
- • Every market listed on the rail
Media / intelligence layer
An intelligence layer explains rules, source differences, operational risks, and context without taking orders.
- • Explanation and context
- • Source discipline
- • Cross-platform literacy
- • Trade execution
- • Routing or brokerage
- • Clearing, custody, or market settlement
Positioning rules
- • PredictionMarkets.US does not route trades.
- • PredictionMarkets.US does not custody funds.
- • PredictionMarkets.US explains source/rule risk and operational context.
- • Tool names require primary docs or official launch pages before rendering.
No-go claims
- • Do not imply a client library, SDK, bot, or analytics dashboard controls settlement.
- • Do not imply PredictionMarkets.US competes as a broker, router, exchange, or execution venue.
- • Do not turn the architecture map into a current-state tool directory; directories rot.
- • Do not name third-party tools unless official docs or launch pages were re-fetched same-session.
If your problem is… inspect this layer first
Market missing
The app may only expose a subset of markets, or the rail may not list that contract.
Order fills weird
Separate the visible button click from orderbook depth, routing, and destination venue mechanics.
Balance display weird
A wrapper can show balances, collateral, or support language differently from the underlying rail.
Outcome disputed
Resolution depends on the rulebook, source hierarchy, and oracle process — not just the app screen.
What does this mean?
Use sourced context before treating a market price, launch, or platform announcement as a trade signal.
PredictionMarkets.US role
PredictionMarkets.US is the intelligence and source-linking layer. We explain markets, sources, rules, platform differences, settlement context, and user-facing mechanics.
PredictionMarkets.US does not route trades, execute orders, broker, clear, or custody funds.
Source discipline
Platform-capability claims should come from official documentation, rulebooks, filings, help-center materials, or platform-maintained source pages. Crypto press, trade press, social posts, and forum threads are not treated as primary citations for what a platform controls.
Where primary-source detail is not enough yet, the map says so instead of treating a launch rumor or secondary article as verified infrastructure.
DCM, DCO, FCM, and IB labels should come from CFTC, NFA, or official platform records before they are treated as platform-specific facts.
Regulated stack roles are not the same as brand names
A trading app, exchange, clearinghouse, broker, and research layer can be separate entities. These labels explain the stack without turning them into recommendations.
DCM — Designated Contract Market
A CFTC-registered trading venue for listed derivatives contracts.
Market rules, listing standards, trading access, and venue operations under its rulebook.
It does not automatically mean the consumer brand is the clearinghouse, broker, or support app.
DCO — Derivatives Clearing Organization
A CFTC-registered clearing organization that manages clearing and settlement obligations.
Clearing, margin or collateral rules, risk management, and settlement performance for cleared contracts.
It is not the same thing as the trading app a user sees.
FCM — Futures Commission Merchant
A registered intermediary that can handle customer futures activity and account relationships.
Customer-facing account, order, margin, and support functions depending on the arrangement.
It does not by itself list contracts or operate the exchange rulebook.
IB — Introducing Broker
An intermediary that introduces customer business to an FCM or regulated rail.
Customer introduction, distribution, and routing relationship details stated in official records.
It does not clear trades or replace the underlying exchange and clearing stack.
Intelligence layer
A source-linked editorial and analytical layer that helps readers understand markets.
Explanation, context, source discipline, trackers, and cross-platform literacy.
It is not a broker, router, DCM, DCO, FCM, IB, custodian, or clearing service.
What the map does not do
Related guides
Rule/source comparison is the intelligence layer before any spread is treated as comparable.
Where APIs, data feeds, and app-facing tooling sit relative to market rails.
Why automation still has to account for order books, fills, and contract wording.
Separate frontend, auth, geoblock, and API diagnostics from venue rules.
Why a consumer app and its underlying exchange rail can differ.
Where perps and event-token rails sit next to event-contract products.
A comparison of two major prediction-market venues.
How market data, media, and intelligence channels distribute prediction-market signals.
The broader platform entry point for comparing venue and app surfaces.