One consumer-facing brand can hide multiple control layers underneath it. This map splits listing, execution, settlement, clearing, app surface, and editorial intelligence into separate roles.
Architecture Lanes
6
Stack Roles
5
Matrix Columns
7
Taxonomy Items
6
Separate the rail, wrapper, router, clearing stack, and intelligence layer before comparing brands.
“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.
Use the map to answer control questions first: who lists contracts, who executes, who settles, who handles the account surface, and who is only explaining the market to readers.
Start by asking which layer controls the thing you care about.
The venue lists contracts and controls exchange mechanics directly.
Who writes the contract rules and resolves the market?
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?
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?
Users can create or seed markets rather than relying only on centrally curated listings.
Who decides what markets exist?
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?
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?
Rows are architecture lanes. Each card answers the decisions users often assume one brand controls.
Exchange / rail
Exchange orderbook
Exchange or member-facing app
Rulebook + settlement process
Central listing process
Exchange / rail economics
Trade directly on the venue
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
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
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
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
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
The same consumer brand can combine curation, execution, fees, settlement, and regulatory roles in different ways.
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.
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.
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.
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.
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.
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.
Separate exchange venue, clearing stack, crypto-native rail, app wrapper, consent lane, and editorial intelligence layer before assuming control.
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.
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?
A reader may treat a wrapper or media summary as if it controls the contract, then miss the actual rulebook and settlement source.
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?
A reader may overstate a partner, clearing, or broker role and turn a stack component into a false platform-status claim.
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?
Official docs can verify a primitive without proving live breadth, durable liquidity, user adoption, market share, or competitive impact.
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?
A reader may blame the app for a rule or settlement mechanic controlled by the underlying exchange rail.
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?
A reader may flatten horse-racing consent constraints into generic sports-betting law and miss the specific source needed.
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?
A reader may confuse analysis with execution capability; the page explicitly separates those roles.
Separate verified stack pieces from pending rail watch items before turning a product headline into an infrastructure claim.
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.
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?
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?
The venue's official API or client surface is documented by the exchange or rail operator.
A developer tool can make a venue API easier to use without controlling the market's rulebook or settlement path.
A dashboard or terminal observes markets and packages data; observation is not execution or settlement control.
A routing layer may choose where an order goes, but the destination venue still controls the contract and settlement rules.
A consumer app can provide account UX, support language, and catalog curation over an underlying rail.
An intelligence layer explains rules, source differences, operational risks, and context without taking orders.
A fast routing guide for figuring out which architecture layer actually explains the issue.
The app may only expose a subset of markets, or the rail may not list that contract.
Separate the visible button click from orderbook depth, routing, and destination venue mechanics.
A wrapper can show balances, collateral, or support language differently from the underlying rail.
Resolution depends on the rulebook, source hierarchy, and oracle process — not just the app screen.
Use sourced context before treating a market price, launch, or platform announcement as a trade signal.
Where the editorial layer stops and where trading, routing, or custody would begin.
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.
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.
A trading app, exchange, clearinghouse, broker, and research layer can be separate entities.
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.
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.
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.
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.
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.
Restraints that keep the taxonomy descriptive instead of promotional.
A quick read on update timing, scope, and the kind of page this is.
2026-05-04
Product architecture taxonomy for consumer education, not a live trading feature.
Map, not execution
Continue exploring
